如何面试工程师？

我们在 Triplebyte 进行过很多次面试。事实上，在过去的两年中，我曾经面试过 900 多名工程师。这到底算不算很好地利用了我的时间还有待商榷！（我有时会突然惊醒并对此产生怀疑。）现在暂且不管这个问题，我们的目标是改善雇用工程师的方法。为此，我们采用盲背景面试，只考察编程技能，而不看证书或简历。在工程师通过我们的面试之后，他们会直接进入和我们合作的公司的最终面试（包括苹果、Facebook、Dropbox 和 Stripe）。我们面试工程师时并不看他们的背景条件，而会在后续观察他们在各个顶尖科技公司中表现如何。我认为这种方法为我们提供了一些非常棒的面试数据。

在这篇文章中，我将介绍一下我们从这些数据中学到的东西。技术面试在很多方面都存在问题。说这话实在太容易了。（许多博文也确实是这么说的！）最难的部分是如何解决这些问题。我写这篇文章的目的就是要直面这个挑战，并为招聘经理和首席技术官提出具体的建议。面试确实很难。但是我认为更小心谨慎地进行面试可以解决很多问题 [1]。

大部分面试过程包括两个主要步骤：

1. 申请人筛选

2. 面对面最终面试

申请人筛选的目的是尽早过滤候选人，并节省面试时间。筛选过程通常先是招聘人员浏览候选人的简历（约 10 秒钟），然后是 30 分钟至 1 小时的电话面试。与我们合作的公司中约有 18% 的公司会让候选人进行一项可带回家完成的编程挑战（代替电话面试或者作为电话面试的补充）。有趣的是， 绝大多数候选人在筛选步骤就会被拒绝 。事实上，在所有与我们合作的公司中，超过 50% 的候选人在简历筛选阶段就被拒绝了，另外 30% 的候选人在电话面试或编程挑战中被拒绝。筛选阶段可以说是招聘中最反复无常的。招聘人员不堪重负，因此需要快速做出决定。这一步也是证书和模式匹配发挥作用的地方。

面对面最终面试大部分会包括一系列 45 分钟到 1 小时的谈话，每次谈话对应不同的面试官。这些谈话主要是技术性的（每个公司会有一两次谈话重点考察文化适应度和软技能）。在候选人离开之后，招聘经理和面试过候选人的所有人会聚在一起开会做出最终是否录用的决定。基本上，候选人至少需要得到一个人强有力的肯定，同时没有强烈的反对者才会被录用 [2]。

除了常见的面谈形式之外，最终面试还有各种不同特点。

• 在与我们合作的公司中有 39% 在面试中会让候选人在白板上展示解题过程

• 52% 允许候选人使用自己的电脑（剩下还有 9% 既不用白板也不用电脑）

• 55% 让面试官自己提问题（剩下的 45% 使用标准的问题库）

• 40% 需要考察候选人学术方面的计算机软件技能来决定是否录用

• 15% 不喜欢过于学术的计算机软件技能（并认为谈论学术能力暗示候选人缺乏创造性）

• 80% 允许候选人在面试中使用任何编程语言（其余 20% 要求使用特定编程语言）

• 5% 在面试中会明确评估编程代码的细节

在与我们合作的所有公司中，参加最终面试的候选人有 22% 能得到工作机会。（这个数字是从公司的内部候选人通道询问得来的。通过 Triplebyte 申请的候选人有 53% 在面试之后得到了工作机会。）通过面试的人中约 65% 接受了这个工作机会（即最终被雇用）。1 年以后，公司对大约 30% 的新聘用员工感到满意，同时已经有 5% 左右的新员工被解雇 [3]。

那么现状到底存在什么问题呢？毕竟，解雇比例似乎还在可控范围内。为了搞明白其中的问题，需要考虑面试失败的两种情况。面试可能会雇用一名不合适的工程师， 然后过一段时间又解雇掉（此为误判）。同时面试也可能会错误地低估那些本来可能做得很好的人（此为漏判）。糟糕的雇员是很容易被发现的，而且对公司而言代价昂贵（从薪酬、管理成本和整个团队的士气来看）。一个糟糕的雇员还会损耗团队的精力。相比之下，那些本来能做得很好但没得到机会的候选人带来的损失则难以察觉。每次这种情况的出现总会存在争议。由于这种不对称性，公司进行面试时更多地倾向于拒绝。

这种倾向还会被面试过程中的噪音加强。在 1 小时内判断编程技能水平从根本上来说是非常困难的。在此基础上再加上模式匹配和几次电话考察，以及前面讨论过的按公司各种偏好进行的复杂考察，最终留给面试官的是一个包含了大量噪音的信号。

面对这些噪音，为了保持较低的误判率公司在做决定时必须倾向于拒绝。这样做会导致公司的面试过程可能错过优秀的工程师，常常过于看重证书而非真才实学，且会让参加面试的候选人感到反复无常和备受打击。 如果你所在的公司中每个人都为了得到现在的工作重新进行面试，那通过率会是多少呢 ？这是一个非常可怕的问题。答案肯定远不到 100%。那些本来可以很好地完成工作的候选人在被公司拒绝后会受到伤害，而公司在找不到所需人才时也会受到伤害。

这里需要声明一下，我并不是说公司应该要降低面试的门槛。面试本来就需要拒绝一部分人！我也不认为公司更担心误判而不是漏判是错误的。毕竟糟糕的雇员确实需要付出高昂的代价。 我只是认为当一个充满噪音的信号与避免糟糕的雇员的需求同时出现时，会导致非常高的漏判率，这样做会伤害到候选人。而这个问题的解决办法是改善信号 。

世界上并不存在一套唯一的可以定义一个好程序员的技能。反之，存在着大量各不相同的技能集。没有工程师可以精通所有技能。事实上，我们在 Triplebyte 经常看到很多优秀且成功的软件工程师具备完全不同的技能。那么，进行一次成功的面试的第一步就是决定对于面试的职位来说什么技能是重要的。我建议你问自己以下问题（这些是我们在 Triplebyte 开始为新合作的公司招募人才时会提出的问题）。

• 你需要的是能快速进行开发和迭代的程序员，还是小心仔细、思维严谨的程序员？

• 你想要的是对解决技术问题有兴趣的人，还是对开发产品有兴趣的人？

• 你需要的是已经掌握特定技术的人，还是允许聪明的程序员在工作中学习这一技术？

• 学术方面的计算机软件、数学、算法能力是重要还是无关紧要？

• 理解并发、C 内存模型、HTTP 重要吗？

以上问题并没有正确答案。我们所合作的成功的公司给出的答案两种皆有。最重要的是要依据自身的需求做决定。需要避免随机挑选面试问题（或让每个面试官自己决定）。当这种情况发生时，公司的工程文化可能会出现偏斜，即越来越多的工程师具有特定的技能或方法，但那些技能或方法对公司来说可能并不重要，而没有那些技能的工程师（但是拥有其他重要技能）却被拒绝了。

聘请专业的程序员是为了解决耗时数周甚至数月的庞大而涉及面甚广的问题。但面试官并没有数周或数月的时间来评估候选人。每个面试官通常只有 1 小时。因此，面试官转而考察候选人在一定压力下迅速解决小问题的能力。其实这并不是同一个技能。它是相关的（面试不是完全随机的），但并不完全相关。制定面试问题的目标就是最小化这种差异。

要达到这个目标需要使面试问题尽可能地贴近你想要候选人完成的工作（或你打算评估的技能）。例如，如果你关心的是后端编程，要求候选人开发一个简单的 API 端点然后添加功能会是一个更好的问题，而不应该要求他们解决 BFS 词链问题。如果你关心的是算法能力，要求候选人应用算法来解决问题（比如开发一个简单的搜索索引，可以基于二叉搜索树和哈希表，以提高删除性能）会是一个更好的问题，而不应该要求他们判断一个点是否包含在一个凹多边形中。让候选人在真实代码库中编码并调试通常都优于让候选人在白板上解决一个小问题。

也就是说，采用白板方式进行面试是存在争议的。作为面试官，我不在乎工程师是否记住了 Python 的 itertools 模块。我关心的是他们能不能思考如何使用迭代器来解决问题。通过让候选人在白板上解决问题，可以让他们暂时不用考虑语法是否正确，而是专注于逻辑。但我还是认为这个说法有问题，因为理由仍然不够充分。让候选人在计算机上编写代码同样可以获得所有的好处，只要告诉他们代码不需要运行即可（甚至更好，可以把它变成开卷的面试，并允许他们在谷歌上查找任何他们想要的信息）。

面试问题应该反映实际工作还需要注意一点，即面试问题不应该依赖于外部依赖包。例如，要求候选人使用 Ruby 编写一个简单的 Web 爬虫看上去似乎是一个很好的真实问题。然而，如果候选人需要安装 Nokogiri（一个 Ruby 解析库，安装过程可能会很痛苦），并且在本机扩展中苦苦挣扎了 30 分钟才搞定，这将变成一次可怕的面试。不仅浪费时间，而且会让候选人承受巨大的压力。

面试提问时还有另一个很好的经验法则是避免提出可能“泄露”的问题，即避免提出候选人可以提前在 Glassdoor 上看到答案要点的问题，否则他们回答问题就过于轻松了。这显然能排除脑力衰退者或任何需要极高洞察力的问题。但远不止如此，这还意味着面试问题需要包含一系列相互依存的步骤，而不是单一的核心问题。另一种有用的考虑方式是问问自己应该如何帮助一个被问题卡住的候选人，并且以积极的印象结束面试。对于一个只有一个步骤的问题，如果你必须给予候选人大量的帮助，那么他们就不能通过面试。而在一个分成多个部分的问题上，你可以在其中一步给予帮助，候选人就可以在剩下其他部分完成得很好。

这不仅仅是因为你的面试问题可能会泄漏到 Glassdoor 上，而且（更重要的是），分成多个部分的问题不会包含那么多噪音。好的候选人也会因为太过紧张而被问题困住。面试官应该能够帮助他们并看到他们恢复到良好状态。基于候选人最近是否看到过类似的问题（可能只是无意看到），会给评估候选人解决一个编程逻辑块的能力引入很大的噪音。分成多个部分的问题可以消除部分噪音。同时也为候选人提供了一个机会以展示他们努力的过程。在一个步骤中做出的努力往往有助于他们解决后续步骤。这在实际工作中将成为一个重要的动力，而在面试过程中捕捉到这一点就能减少噪音。

举个例子，要求候选人在终端上实现游戏 Connect Four（包含一系列步骤）可能比要求候选人旋转一个矩阵（只有一个步骤，而有一些简单的窍门）更好。又比如说，实现 k 均值聚类（包含相互依存的多个步骤）可能比确定适配直方图的最大矩形更好。

如果候选人能很好地解决一个非常困难的问题，那么你可以得到和他的技能有关的很多信息。但是，由于问题太难，大多数候选人都无法很好的解决问题。那么问题的难度将严重影响预期能从这个问题获得的信息量。我们发现，面试中问题的最佳难度比大多数面试官认为的要容易得多。

这种影响由于面试候选人时存在的两个信号来源而被放大：即他们是否给出了一个问题的“正确”答案、他们得到答案的过程或容易程度。我们在 Triplebyte 已经收集了很多相关数据（根据候选人是否得到正确答案以及他们花费了多少努力对问题进行评分，然后衡量哪些评分能预测他们在公司中的表现）。我们发现这里有一个权衡问题。对于更难的问题，候选人的答案是否正确携带了大部分信号。相比之下，对于更容易的问题，更多信号来源于候选人解决问题的过程以及他们的努力程度。考虑到信号的两个来源，显然选择比较容易的问题更好。

我们现在遵循的经验法则是，面试官应该能在他们期望候选人花费的时间的 25% 的时间内解决问题。所以，如果我正在制定一个用于 1 小时面试的新问题，我希望我的同事（没有任何提示）能够在 15 分钟内回答这个问题。再配合前面所说的将问题分成多个部分且尽可能贴近实际工作，我们要得到最佳面试问题其实很简单。