2 年面试 900 多位工程师后，我总结了这些经验

（给 伯乐在线 加星标，看经典文章 ）

编译：伯乐在线/dimple11

我们在 Triplebyte上进行过很多场面试，实际上，我在过去两年内面试的工程师已经达到 900 余人，这到底算不算卓有成效还真是不好说！（有时我会冒着一身冷汗从梦中惊醒，对这一点充满质疑）。但是不管怎样，我们目标是改进应聘工程师的方式。为此，我们面试时不看求职者的背景，不在乎他们的文凭或简历，只关注他们的编程能力。一个工程师通过了我们这一关后，能直接到我们的合作方公司（包括 Apple、Facebook、Dropbox 和 Stripe）进行终面。我们面试时不知道应聘者的背景，这种情况下看他们是如何在众多顶尖科技公司前大展身手的，我觉得可以给我们的面试提供一些最佳的可用资料。

伯乐在线补注：Triplebyte 是国外一家专注工程师招聘的网站。

在这篇博客中，我要讲讲迄今为止我从这些资料中所学到的东西。技术面试在很多方面都是漏洞百出的，这一点口头说说很简单（而且许多博客都只是这样说说而已！），难的是想出实际的解决方法。我写这篇博客就是为了迎接这个挑战，并为招聘经理和 CTO 提供一些具体的建议。面试这件事有难度，但我想只要遵循一套缜密的流程，那么许多问题都会迎刃而解。

现状

大多数的面试过程主要包括两步：

1. 简历筛选

2. 面试

对求职者的筛选就是为了提前淘汰一些求职申请者，节省面试工作的时间。通常筛选过程包括：招聘官大体浏览求职申请者的简历（大概用时 10 秒以内），然后进行 30~60 分钟的电话面试。我们的合作方公司中有 18% 的公司为了考验求职者，也会出编程题让他们回家完成（要么代替电话面试，要么作为电话面试以外的附加题）。有意思的是，绝大多数的求职申请者都是在筛选这一关被拒的。真是这样，我们合作的所有公司中，单纯因为简历就被筛掉的求职申请者已超过了 50%，另外有 30% 因为电话面试/带回家的项目完成不佳而被刷掉。筛选也是聘用过程最变化无常捉摸不定的环节，应聘者太多，导致招聘人员应接不暇，只能做出仓促的决定，因此这时候求职者的文凭资历和专业匹配度就派上了用场。

终面几乎普遍都是由一系列 45 分钟到 1 小时的会谈组成，每次会谈的面试官都不一样，会谈主要考技术题（每个公司外加一两个针对文化适应和软技能的问题）。招聘经理和每个面试官会在求职申请者离开后，在决策会议上做出他们最终录用/淘汰的决定。在至少有一人力挺，且没人强烈反对的情况下，一个求职申请者才可能被录用。

终面除了常见的形式之外，还有各种千变万化的类型。

• 我们合作的公司中，39% 会使用白板面试。

• 有 52% 允许求职者使用他们自己的电脑作答（剩下的 9% 视情况而定）。

• 有 55% 让面试官随意提问（剩下的 45% 采用一套标准面试题）。

• 有 40% 要考察求职者的 CS 学术技能后，才能确定去或留。

• 有 15% 不喜欢 CS 学术技能（而且觉得探讨计算机科学只能暴露该求职者生产力低）。

• 有 80% 允许求职申请者在面试时使用任何编程语言（剩下的20%要求他们使用特定编程语言）。

• 有 5% 会在面试过程中直白地评价求职者编程语言的细节。

放眼所有与我们合作的公司，终面后决定录用的占 22%。（这个数据是通过询问公司内部招聘渠道获得的。Triplebyte 上的求职者通过公司面试被录用的成功率为 53%。）其中大概 65% 会接受 offer（达成雇佣关系）。一年后，公司对录用了 30%、开除率 5% 的情况非常满意。

漏招 VS 误招

所以，现在的面试存在什么问题呢？毕竟开除员工的频率并非是不可控的。为了更清楚地看待这个问题，我们需要考虑导致面试失败的两种情况：

1. 面试了一个不合格的工程师，却将其聘用，过后只好开除（误招）；

2. 面试了一个工作能力很强的工程师，却认为他不合格，选择不予聘用（漏招）。

误招一眼就能看出来，公司会（在薪水、管理成本和全团队的精神面貌上）付出很大代价，会把一个团队搞得萎靡不振。而与之对比，漏招的损失却看不出来。虽然以上任意一种情况都很有问题，但由于这误招和漏招引发的后果乍一看很不平衡，所以公司的面试很大程度上倾向于不予聘用。

面试中存在的干扰会使公司不予聘用的倾向更加严重。在一小时内评估一个人的编程能力本来就是很难的，各种条件经历的匹配、某些直觉感受和以上谈到的公司的复杂喜好等因素掺杂进来，使得你在面试别人时被各种干扰团团围困。

为了在受干扰环境下把误招率控制在一个较低的水平，公司在招聘时越来越偏向于不予聘用。这样会错过优秀的工程师，会使文凭的重要程度高过实力，也会由于反复无常，使参与其中的人（面试官和求职者等）感到失望。 假使你公司中的每个员工为了争取他们当前的职位都得重新参加面试，那么通过率能有多大呢？ 这个问题很骇人，几乎可以确定他们不可能都被录取。求职申请人会因为本有能力为公司好好效力却没被录用而神伤，公司也会因为找不到可用之才而遭受损失。

要澄清一点，我不是说公司应该降低面试的门槛，相反，面试招人正因为会有拒绝才存在的意义！我更不是说公司对误招的担忧远大过漏招是不对的，招错人要付出高昂代价， 我想说的是：各种干扰信号的影响外加之对于 误招 的防范，会导致 面试的漏招率大大攀升，导致人才流失。为解决这一问题，就需要 改善面试环境 。

减少面试中干扰因素的具体方法

1.决定你想要招聘哪方面的技术人才

一个程序员不可能因为具备了哪一套技能就能被定义为优秀的程序员了，相反，世上的编程技能多得犹如汪洋大海，没有工程师能在所有的领域都游刃有余。实际上，我们在 Triplebyte上碰到过一些杰出、成功的软件工程师，他们在几个毫不相关的领域都颇有建树。面试成功的第一步就是决定你想要招聘哪方面的技术人才。我建议你问自己以下几个问题：

• 你想要的程序员是效率高，但写的代码不完善需反复修改的，还是一丝不苟、思维严密的？

• 你想要的程序员是热衷于解决技术难题的还是构建产品的？

• 你想要已经具备某种特定技能的人才还是在工作中有很强的学习能力的？

• 计算机科学学术/数学/算法方面的能力是至关重要的还是无关紧要的？

• 了解并发/ C内存模型/ HTTP 很重要吗？

这些问题没有正确答案，我们合作的成功企业对以上每个问题选任一方的都有。 但关键是要根据自己的需求 有针对性地做出选择 ，应该避免 随便向求职者抛个 面试 问题了事（或者让 每个 面试官决定）。 这样的话，公司的工程文化就会有一定倾向：淘汰掉越来越多虽然有一技之长但是对公司并没太大用处的、以及不具备公司所需技能（却具备其他重要技能）的工程师。

2.问尽可能和实际工作相贴切的问题

专业程序员的任务是花数周数月的时间解决大型的、错杂延展的问题，但是面试官并没有数周数月的时间去评估求职申请者的能力，通常每个面试官只有一个小时去考核，所以他们会转而去考察求职申请者在强压下迅速解决小问题的能力。这是两种不同的能力测试。二者有一定的相关性（面试并不完全随机），但并不是完全相关。制定面试问题的一大目标就是减少面试考察和实际工作的差异。

方法是在面试时向申请某一职位的求职者（或者为了衡量某一技能）问尽可能相似的问题。比如说，如果你关心后端编程，那就让求职申请者建一个简单的 API 端点，再添加特性，几乎可以肯定，这比让他们解决一个 BFS 词链问题有意义得多；如果你关心算法能力，那让求职者在问题中运用算法（比方说，建一个简单的搜索索引，可能使用 BST 和 hashmap，实现提升删除操作的性能），几乎可以肯定，这比让他们确定一点是否包含在一个凹多边形中有意义得多；让求职者在实际编程过程中去尝试调试程序，几乎可以肯定，这比让他们去解决一个白板上的小问题有意义得多。

即便如此，面试中要不要让程序员在白板上作答还是有争议的。作为面试官，我不在乎工程师是否记住了 Python 中的 itertools 模块，我在乎的是他们是否想通了如何用 itertools 模块去解决问题。通过让他们在白板上答题，他们便可以不用遵循严格的编程语法，而完全专注于逻辑问题。但最终白板答题的提议还是行不通，因为白板上答案的形式五花八门，没有那么多的评判标准可以对它们一一进行对错评判。所以让求职申请者们回归到电脑上编程，同时告诉他们不必真正去运行代码（或者采用更好的方法，进行开卷面试，让他们在 Google 上查询任何所需的信息），那么考察他们的目的就已经达到了。

面试问题应该对日后工作有所反应，对此要特别警告，面试不依赖于外部因素是至关重要的。比如说，让一个求职者用 Ruby 编写一个简单的爬虫看似是个很好的实际问题，但是，如果求职者为此需要先安装 Nokogiri （一个安装起来非常费劲的 Ruby 解析库），结果花了 30 分钟绞尽脑汁应对本地扩展，那么这次面试就糟透了，不仅浪费了时间，而且也让求职者一下子压力爆棚。

3.问不会提前泄露的多面性问题

另一个针对面试提问的经验之谈是避免提问有可能会“泄露”出去的问题。比如说，有些问题的某些信息可能求职申请者提前能从 Glassdoor 上读到，所以他们回答起来就会轻而易举，因此这类问题就要避免提问，否则求职者明显就不用动脑筋了，也抹杀了需要考验他们直觉洞察力的地方。而且除此之外，也意味着面试的问题应该由一系列相互承载的部分组成，而不是一个单一的中心。换种有用的方式去想，问问你自己，能不能在面试时帮助一个陷于困境的求职者，并让他在面试结束还能给大家留下一个不错的印象。对答案唯一的问题，如果你给求职申请者提供了明显的帮助，那么他就直接面临淘汰；而对于多面性的问题，你帮了求职申请者一步，那么他还有机会在其余部分大展身手，完美表现。

伯乐在线补注：Glassdoor 是国外一家做企业点评和职位搜索网站。

这一点很重要，不仅因为你的问题会在  Glassdoor 上泄露出来，而且（更重要的）是因为多面性的问题可以减少干扰。优秀的求职者会背负压力，陷于困境，面试时很重要的一点就是对他们提供帮助，从而让其好好发挥。考查他们解决任意小编程逻辑问题的能力时，他们最近一段时间是不是看到过、或可能只是恰巧碰到过类似的问题，会对考查造成明显干扰，而多面性的问题则可以消除一些干扰，也让求职者们有机会看到他们的努力像滚雪球一样越积越大。给他们提供一步的帮助，往往能帮他们解决紧接着的下一步，这给实际工作提供了重要动力，在面试时把握这一点就可以减少干扰。

举例来说，让一个求职者在终端实现“四子连珠”游戏（一系列多个步骤），可能要比让他去旋转矩阵（一个单独步骤，外加之一些小操作）要好得多；让求职者实现 k 均值聚类（建立在彼此之上的多个操作）可能要比找到直方图中的最大矩形（leetcode 的一道算法题）要好得多。

4.避免问很难的问题

如果求职者很好地解决了一个很难的问题，那能极大地证明他的能力，但也正因为这个问题很难，所以大多数求职者都无力招架。你想要获得的信息量就很大程度上依赖于问题的难度，我们发现面试问题最合适的难度要明显比大多数面试官所想的简单得多。

这一点影响更大，因为面试求职者时，获得的信息有两种来源：他们是否对一个问题给出了“正确的”答案、他们得出答案的过程/得出答案的容易程度。我们在 Triplebyte上收集了这方面的数据（同时给他们是否得出了正确答案和他们花费了多大努力这两项打分，然后衡量对公司而言哪个分数能更准确地对求职者能力进行预测）。我们发现这是一种权衡，对于更难的问题，求职者是否给出了正确的答案更能说明问题，相比之下，对于更简单的问题，求职者的答题过程和他们花费的努力程度则更有参考价值。考量了这两种信息来源后，面试问题最适宜的难度会往更加简单的方向偏移。

我们现在遵循的经验法则是，面试官解决问题所用的时间应该是他们希望求职申请者们解决问题所花时间的25%。所以如果我在为时1小时的面试中提出了一个新的问题，我希望我的同事（没有提醒的情况下）能在15分钟内解答。外加之我们应问实际环境下的多面性问题，这意味着最佳的面试问题真的是相当直白和简单的。

要澄清一点，我不是说要降低通过率的门槛。我支持问简单的问题，然后将他们回答的情况纳入考评范围；我支持问简单的问题，然后给予相当严苛的评判。这就是我们所找到的对面试环境进行优化的方式，这种方式额外产生的好处就是可以降低大部分求职者的面试压力。