都说谷歌的“白板面试”很烂，有什么替代方案吗？

编者按：多年以来，白板面试已经渐渐变成了行业入门的标准。那究竟什么是白板面试呢？这其实指的是在面试时不依赖外部参考，直接在白板上手写程序。Google、Amazon等知名科技公司都在采用白板面试的方法面试应聘者。然而，业界对于白板面试却有诸多吐槽。究竟白板面试存在哪些问题呢？业界在雇用人才时又能采取什么其他的替代方案吗？本文编译自Medium平台上原文名为《Let’s talk about whiteboarding interviews and the possible alternatives》的文章。

白板面试在业界被诟病已久，这已经不是什么新鲜事儿了。

不管是在Twitter、Medium还是LinkedIn上，你都能很容易地找到大家对此的诸多吐槽和抱怨。“招聘流程已然崩溃”的说法被频繁使用，以至于大家觉得这都是套话了。

不幸的是，业界对这种面试方式的不满并未得到应有的重视。

尽管大家异口同声地表示出对白板面试的愤怒，“白板”依旧是软件工程师岗位面试时采用的主要方式。部分原因也许在于，开发者们虽然能迅速表达自己的愤怒，但却不能及时提供更优的替换选择。

那有什么更好的替代方案吗？

最近，这一问题一直盘桓在我的脑海里。四周前，我获得了第一份全职软件工程师的工作。虽然我还没有参与招聘流程，但我最终会去参与的。

一个月之前，我还是求职者的身份，我很清楚面试流程有时候会有多不靠谱。未来轮到我参与招聘的时候，我希望自己能够准确且客观地评价我未来的同事。

这种尴尬的处境让我开始思考如下两个问题：

1. 白板面试是最佳选择吗？

2. 如果不是，那有什么更好的替代方案吗？

在本篇博文中，我将对上述两个问题进行阐述。有一点要说明，这是基于我自己面试经历总结出来的个人观点。

我会采用一种真正意义上的软件工程式解决方案去应对这个问题，达到尽可能得客观：审视所有选择并且权衡利弊。

白板面试是最糟糕的选择吗？

解决此问题的第一步就是要仔细审视白板面试的利弊。

优点：

1. 快速且不用投入太多精力。

2. 不限定特定语言或领域。

3. 你（通常）知道预期结果是什么样的。

4. 社区支持（Glassdoor、LeetCode、Pramp等）。

缺点：

1. 运气是很重要的元素（算法博彩）。

2. 不一定会测试工程能力的高低。

3. 偏向年轻的工程师和应届毕业生。

对于需要工程师熟练掌握CS基本知识、对算法要求不高、不依赖于多Library库工程的公司来说，白板面试是最合适的选择。

SpaceX、MacOS/Windows以及Facebook的React都是由这类工程师开发的。如果你是想在这些公司求职，那么你很有可能会碰到白板面试。

作为求职者，我很喜欢白板面试。我知道面试内容大概是什么。大多数的算法问题都是关于以下这几个内容：

• Arrays/Strings （数组/字符串）

• Binary Trees （二叉树）

• Linked Lists （链组）

• DFS/BFS （深度优先算法/广度优先算法）

• Backtracking （回溯法）

• Dynamic programming （动态规划）

提前知道这些就意味着我可以有针对性地进行学习。还有很多学习工具可供选择。事实上，技术性面试准备已经“自立门户”，形成一个专门的行业了。

可也正因如此，白板面试并非适用于所有公司。面试成功与否很大程度上归结为运气、记忆力以及能否花大量时间进行学习。

并非所有人都能为了掌握算法持续这么长时间的学习。

我很幸运自己能够做到这一点，并在竞争中脱颖而出。但我比其余所有的工程师都优秀吗？可能吧，但我并不确定白板面试是否是揭露谁是优秀工程师最好的方式。

如果我们开始质疑白板面试的效用，又有哪些更好的替代方案呢？

让我们来了解一些替代方案吧。

通过电脑进行编程挑战

优点：

1. 可以使用电脑，获得一个熟悉的开发环境。

2. 可以通过共享屏幕远程完成编程挑战。

3. 拥有白板面试的所有优点。

缺点：

1. 对句法和代码运行能力要求要为严苛。

2. 编程环境以及插件会起到重要影响。

3. 和白板面试一样的缺点。

与白板面试相比，在笔记本电脑上进行编程挑战没什么太大差别，它没有前者那么严苛。

求职者可以使用自己的电脑。他们还可以远程参与编程挑战或结对编程。

我注意到编程挑战通常比白板面试要简单一些。我在面试过程中被提问的大部分问题都涉及到字符串处理或是简单的算法，任何有经验的工程师都不需要专门为此花时间进行学习。

这种方式的缺点在于过多强调实用性。

在我找工作期间，我碰到过两次Coin Change （硬币找零）的试题。一次是在白板面试中，还有一次是在编辑器中。

在白板面试中，我主要是去解释我的解决方案。在我的笔记本电脑上，我需要写出边界情况的测试并且保证我的解决方案是有效的。

我之所以喜欢白板面试，部分原因也是在于它的宽容性。没人会去用编译器运行你写的函数。只要面试官能理解你的思路，编程看上去没太大问题，你就能得到满分。

但是编程挑战就不同了。

有些人也许会说，强调实用性更好，这是因为我们工程师就是拿钱做事。这一论点没问题，但公司支付我们薪资，并非是要求我们在30-45分钟之间内完成任务呀。

还是祈祷你在面试的时候不会紧张吧。一个很小的bug可能会导致测试失败或是需要你花费好几分钟时间修补漏洞，这很可能就决定了你是否能通过面试。

编程挑战和白板面试也面临着相同的问题，它们大多都是基于算法的。

鉴于实用性带来的附加压力，即便你是在熟悉的开发环境下，问题也很有可能会变得很复杂。如果你本身就不喜欢算法问题，编程挑战也不比白板面试更好。

带回家完成的测试

优点：

1. 你可以穿着睡衣干活。

2. 通常会给一周时间完成项目。

3. 可以使用自己的编辑器和开发环境。

4. 这可以成为一个新的代表作品。

5. 通常比白板面试更有趣。

缺点：

1. 难度梯度可能会发生大幅变动。

2. 相比编程挑战，这往往要花费更多时间、投入更多精力。

3. 可能会受限于特定领域语言。

4. 由于竞争，可能会导致功能蔓延。

5. 并不能代表每天的工作情况。

很多工程师都喜欢回家完成测试。任务上交的时间节点通常较为灵活，求职者也可以在真正意义上进行编程。与站在白板前写代码并被别人无声评判相比，程序员会喜欢这种方式也不出为奇。

但是，回家完成测试也有很大的弊端。

首先，这种测试易于控制。

许多公司都是在GitHub举办测试的。在GitHub搜索框中输入“挑战”或“测试”，你能得到很多测试信息。一些精明的求职者就能拥有大量时间去事先进行调查研究，从而抢占先机。

这并非是抱怨，更多算是一种提醒。

真正的问题在于，你很容易找到参与挑战的其他选手的答案并且进行复制。很多工程师都会在GitHub主页上保留自己回家测试的结果。

你甚至可以自己试一试。在GitHub搜索框里输入“<XX公司> Challenge”，看看你能得到什么搜索结果。

我住的地方很靠近Etsy在布鲁克林的总部，我好奇自己能不能找到这家公司测试的一些答案。搜索“Etsy Challenge”，显示出有四个结果。如果你搜索“Etsy Test”，你会得到更多搜索结果。

诚然，公司也会更改自己的测试项目。但由于细节信息的泄露，隔几个月就要更换一次面试流程，这也是挺麻烦的一件事。

其次，完成这些挑战所需花费的时间和挑战难度也存在很大差异。

在我上一次找工作的时候，我需要回家完成四份项目。有三家公司都表示它们给的项目只需要花费3-5个小时即可完成。

但是每一个项目，我都花费了好几天时间。

之所以会这样，主要原因在于这些挑战都是针对特定领域的。这需要你花费数小时时间搜索应用程序接口文档和新技术。

第四家公司的挑战本可以在一周时间内轻松完成，但它只给了我两天时间。我需要开发一个支持斜杠命令（slash command）的聊天应用程序。

这是一个很有意思的项目，但为了完成它，这两天时间内我需要放下其他事情，专心完成测试。

如果一个求职者足够幸运，能够同时面试多家公司的话，那么光是完成这些挑战就可以相当于是一份全职工作了。

此外，职业开发者们还需要处理遗留的代码库并且在截止期限前完成任务。一周长的新项目并不能很好地评判求职者在快节奏的环境中表现情况如何。

总的来说，我喜欢将回家完成测试作为最初检测求职者能力的方式。不过任务内容必须与求职者申请的岗位相关，且任务完成时间不能过长。

基于项目或是合同对租赁

优点：

1. 有机会和求职者/团队共事。

2. 带薪工作。

3. 能够接触到真实的项目。

3. 公司会基于你和团队的合作情况对你进行评定。

缺点：

1. 耗时长。

2. 没有就业担保进行工作。

3. 作为承包人没有医疗保障福利。

4. 在谈判中将求职者置于不利地位。

基于项目的面试很少见，但是有不少公司是选择这种方式的，比如说Basecamp以及Automatic。我能理解它们为什么采取这种方式。

这种面试可以最为准确地评判一个人的技能并且可以由团队成员进行评价。公司会直接和这部分求职者共事，观察他们是如何应对团队中的任务的。

求职者也有机会了解公司并决定这种环境是否是自己喜欢的工作氛围。

双赢。乍看上去似乎是如此。

不过说了这么多，作为求职者，我绝对不会参与基于项目的面试或去任职合同对租赁岗位。这种方式弊远大于利。

任何工作的头几个月都是最艰难的。你要适应一个新的团队、新的文化、新的代码库。现在想象一下你在不知道自己最终能否获得工作的情况下做项目，那是什么感受。

我的一个好朋友最近参与了Automatic的面试并表示压力很大。从你和同事的相处方式到你问的问题，一切都会被别人评判。在这样的环境下，你就会问出一些“愚蠢的问题”。

更糟糕的是，在三个月之后，他就被开了。还好，这事没能影响他的自尊心。他很清楚自己的能力，并且会鼓起勇气继续前行。我不确定自己或是很多其他工程师能否和他一样如此坦然接受这件事。

此外，合同也让求职者在谈判过程中处于一个不利的地位。原先，谈判中的一个筹码就是你可以选择离开。

而在合同对租赁到期时，求职者已经没有什么谈判的筹码了。他们手头上也没有其他公司给的offer。他们已经为了项目投入了数十个甚至于数百个小时的时间（取决于合同周期）。

即便这不是他们理想的选择，其他人也会鼓动他们去争取这个职位。还有一个选择，那就是重新回到求职大军中去。

这一点是沉没成本悖论的最佳诠释（如果人们已为某种商品或劳务支付过成本，那么便会增加该商品或劳务的使用频率，这一定义强调的是金钱及物质成本对后续决策行为的影响）。

也许白板面试不是最理想的选择，但在我选择尝试基于项目的面试之前，我宁愿先参加个一百次白板面试再说。

那么到底哪一种方式是软件工程师岗位面试的最佳选择呢？

答案你也许已经猜到了，那就是：视情况而定。

利弊权衡似乎主要是围绕速度、精力以及准确性。每一种方式都或多或少得舍弃了某个方面。这其实还是取决于各个公司自己对利弊的评判。SpaceX和纽约的小型初创企业相比，面试流程肯定是不一样的。

有一点是毋庸置疑的，那就是SaaS公司如果想要评判工程师的技能，那就只需要让求职者写出动态规划算法即可。它们不必跟风谷歌。

如果我要为DigitalOcean里自己的团队设计招聘流程的话，那我就会结合回家完成测试以及编程挑战/组队练习。我会通过提问环节以及系统设计挑战来评估他们对于可利用性以及分布式系统的理解。

好消息是，我的团队已经开始这样做了。DigitalOcean的面试流程虽然不简单，但还算公平，这也是我选择接受其offer的原因。事实也表明，他们已经完成了自我审视的步骤，找到了公平评估求职者的方法。

如果你有什么喜欢的面试方法，也可以在评论中告诉我。

最后，对于那些期待面试流程发生变动的程序员来说，你们可以试着提出一些新的想法。我见到很多程序员没完没了得抱怨白板面试，但在拿到工作offer之后也不曾想过做出改变——因为需要耗费诸多精力才能改变这一流程。

千万别成为这样的人。

停止抱怨。

找到解决方案。

编译组出品。编辑：郝鹏程