内幕 | 我面试了900多名工程师，得出了这样的结论........
Triplebyte是一家协助其他公司招聘工程师的企业。在他的招聘流程中不关注应聘者的背景，并通过多种方法来减少对应聘者的偏见，致力于创建更好的招聘流程。
我们在Triplebyte公司做过很多次面试。事实上，在过去的两年里，我曾面试了900多名工程师。
对于应聘者，我们不关注他们的背景，不看他们的证书或者简历，而是直接考核他们的编程技能。在工程师通过我们的招聘流程之后，他们会直接进入我们合作的公司进行最后的面试（包括苹果、Facebook、Dropbox和Stripe）。
我们不看应聘者的背景，直接对他们进行面试，然后再看看他们在这些顶尖的科技公司表现的怎么样。这为我们提供了一些面试方面非常有用的数据。
技术面试现在出现了很多种不同的方式。我们的目标是为招聘经理和首席技术官提供具体的建议。
大多数的面试过程都包括这两个主要步骤：
申请人筛选
亲身面试
对申请人进行筛选，目的是尽早过滤掉一部分应聘者，以节省面试时间。筛选的过程通常包括：招聘人员浏览应聘者的简历（约10秒钟），然后是30分钟到1小时的电话沟通。我们共有18％的公司使用了家庭式的编程考核（无论是取代手机筛选，还是额外增加的考核）。 有趣的是，经过这些筛选步骤，绝大多数应聘者都会被拒绝掉。事实上，在所有与我们合作的公司中，超过50％的应聘者在简历浏览的过程中就被拒绝了，另外30％的应聘者在电话筛选或者编程考核中被拒绝。筛选也是招聘中最为随意的一步。招聘人员面对如此多的应聘者，需要快速地作出决定。这时，证书和模式匹配就发挥作用了。
亲身面试通常由45分钟到1小时的谈话组成，每次谈话都有不同的面试官。这些谈话主要是技术方面的（每个公司一般都会有一两个专注于文化素养和软技能方面的谈话）。聘用或者不聘用的决定最终会在应聘者离开后的相关会议中确定下来，招聘经理和每个面试官都会参加这个会议。基本上来说，应聘者至少需要有一个强有力的支持者，并且没有强力的反对者才能最终得以录用。
然而，除了常见的形式之外，最终面试的形式也千差万别：
39％的公司在面试过程中会在白板上做标记 52％允许应聘者使用自己的电脑（有9％不一定）
55％让应聘者自己挑选问题（剩下的45％使用标准题库）
40％需要视应聘者的理论计算机科学水平来决定是否录用
15％不喜欢理论计算机科学（并认为，谈论理论计算机科学代表了这个应聘者并不具有创造性）
80％让应聘者在面试中可以使用任何编程语言（其余的20％需要使用特定的语言）
5％在面试中会明确地评估编程中的细节问题
在所有合作的公司中，最终22%的人能得到录用通知。约65％的录用通知会被接受（最终产生雇佣关系）。一年以后，这些公司会对其中大约30％的员工感到非常满意，同时，5％左右的员工被解雇。
错误的否定 vs. 错误的肯定
那么，目前的这种状况有什么问题吗？要看清楚存在的问题，首先要思考一下面试失败的两种情形。面试可能会让一名坏的工程师被雇用，后来再被解雇（错误的肯定）。而面试也可能会使那些本来能够胜任这份工作的人失去资格（错误的否定）。错误的录用所产生的后果是显而易见的，对公司而言代价也是很昂贵的（体现在薪酬、管理成本和整个团队的士气等方面）。错误的录用会消耗团队的精力。相比之下，可以胜任工作但却没有得到机会的候选者是看不见的。这两种情况中的任何一种都存在争议。由于这种不对等性，公司在面试中更倾向于拒绝应聘者。
招聘过程中的杂音会增加这些问题出现的概率。在一小时内判断应聘者的编程水平从根本上来说是很困难的。再加上一系列的模式匹配和依赖直觉的电话沟通，以及上面提到的不同公司的不同偏好，这些都会给你留下非常大的杂音。
在这些杂音下，为了保证低概率的“错误的决定”，公司的决策必须偏向于拒绝应聘者。最终产生的结果就是错失优秀的工程师、相对于实际的技能更看重其拥有的证书，以及对相关的人员举棋不定甚至失望。如果对公司的每个人都要针对其从事的工作重新进行面试，那么通过的百分比有多少呢？这是一个可怕的问题。答案几乎可以肯定在100％以下。应聘者在被公司拒绝后可能会受到伤害，而公司在找不到所需的人才时也会受到伤害。
需要澄清的是，我不是说公司在面试中应该降低要求。拒绝是面试的重点！我更加没有说，公司害怕“错误的肯定”甚于“错误的否定”是错误的。错误的录用一个应聘者所带来的代价是昂贵的。我认为，招聘过程中的杂音和避免招错人的想法，导致了“错误的否定”的概率很高，这伤害了那些应聘者。而解决的办法就是改善信号。
减少面试中的杂音的具体方法
1. 确定你要找的员工需要具备哪些技能
并没有一套技能标准来定义一个好的程序员。相反，这世上有很多种各不相同的技能集。没有哪个工程师能够擅长这所有领域的技能。事实上，在Triplebyte公司，我们经常会看到优秀而又成功的软件工程师拥有完全不相关的技能。那么，进行一个好的面试的第一步就是要确定应聘者需要具备哪些技能。我建议你问一下你自己下面几个问题。
你需要一个能够快速迭代的程序员，还是细心严谨的程序员？ 你想要有人来解决技术问题，还是构建产品？ 你是否需要一个拥有某个特定技术技能的程序员，还是一个聪明的、能够在工作中学习的程序员？ 理论计算机科学、数学、算法能力是重要的还是无关紧要的？ 理解并发、C内存模型、HTTP是否重要？
这些问题没有正确的答案。我们所在的那些成功的公司对这些问题都会有正反两个不同的答案。但是，最关键的是你应该根据自己的需要来做出有目的性的选择。因此，我们要避免的就是简单地随机性地挑选面试问题（或让每个面试官自己决定）。当这种情况发生时，公司的工程师文化可能会发生偏离，具有某个特定技能的工程师会越来越多，公司会向着不重要的方向发展，而那些不具备这种技能的工程师（但是具备其他重要的技能）会被拒绝。
2. 让问的问题尽可能地接近真实的工作
聘请的专业程序员为了解决一些复杂的大问题可能需要耗费数周甚至数月，但面试官并没有几个星期或几个月的时间来评估一个应聘者。每个面试官通常只有一个小时的时间。面试官看的是应聘者在压力下快速解决小问题的能力。这是一项与众不同的技能。它与应聘者本身所具备的技术技能是相关的，但又不完全相关。在制定面试问题时，应尽可能地让他们之间的差异最小化。
面试中问的问题应尽可能地接近应聘者应聘的那个职位（或者你想要衡量的技能）。例如，如果你关心的是后端编程，可以让应聘者构建一个简单的API并添加功能，而不是要求他们解决BFS字链问题。如果你关心算法方面的能力，可以让应聘者通过使用算法来解决问题（比如，用BST和hashmap来构建一个简单的搜索索引，以提高删除操作的性能），而不是要求他们确定一个点是否包含在一个凹多边形中。你可以让应聘者在白板上解决一个小问题，也可以让他们用真实代码来调试程序，但是，后者相对来说效果更好一些。
也就是说，在白板上进行面试是有争议的。作为一个面试官，我不在乎工程师是否能够熟记Python itertools模块。我关心的是他们如何使用迭代器来解决问题。通过让应聘者在白板上工作，我可以让他们不必关注语法正确与否，而是专注于逻辑。但是，最终我认为这个论点是错误的，因为对于不同的面试形式并没有给出足够的理由。你可以让应聘者在计算机上操作来获得上面提到的所有的好处，只要告诉他们这个代码不需要运行就行了（甚至可以成为一个开放的书面面试，并允许他们用谷歌搜索任何他们想要的东西）。
重点说明一下，面试过程中问的问题应该要能反映实际的工作。这些问题不应该受外部的依赖，这很重要。例如，要求应聘者用Ruby编写一个简单的网络爬虫看起来就是一个不错的实际问题。然而，如果应聘者需要安装Nokogiri（一个Ruby解析库，安装起来可能会很痛苦），并且最终用了30分钟的时间来配置本地扩展，那么这将成为一个可怕的面试。不仅浪费了时间，而且对应聘者的压力也已经过去了。
3. 问那种不能放弃的并且包含多个部分的问题
对于面试中要问的问题，有另外一个很好的经验法则，那就是要避免可以“放弃”的问题，例如，避免出现应聘者可以提前在Glassdoor（译者注：Glassdoor是美国的一家做企业点评与职位搜索的职场社区网站）上搜索到相关信息的问题，以防止他们不用动脑子就可以回答出来。这样就排除了脑筋急转弯或者任何需要顿悟的问题。同时也意味着所提的问题需要有一系列相互依存的步骤，而不是一个单一的核心问题。另一个有用的方法是问问你自己，你是否能帮助一个陷入难题的应聘者，并且在结束面试的时候，他仍然能够给你一个积极的印象。对于一个只有一个步骤的问题，如果你不得不给应聘者以大量的帮助，那么表明他们失败了。而对于一个包含多个步骤的问题，你可以仅仅帮助他其中的一个步骤，让应聘者可以回答好剩下的步骤。
这么做很重要，不仅仅是因为你的问题可能会泄漏到Glassdoor上，而且（并且更重要）因为包含多个部分的问题的杂音更小。好的应聘者会变得紧张而又不知所措。帮助他们并且看着他们恢复情绪是很重要的。应聘者在解决任何一个编程逻辑问题时，都可能会产生一个很大的杂音，因为他们最近可能看到过类似的问题，或者是他们的运气实在太好了。包含多个部分的问题可以消除一些杂音。它让应聘者有机会看到他们自己努力的成果像滚雪球一样越滚越大。在其中的某一个步骤上的努力往往会有助于他们解决后面的步骤。这在实际工作中是一个很重要的动力，而如果在面试中捕捉到这一点就能减少杂音。
举个例子，让应聘者在终端上实现Connect Four游戏（有一系列的步骤）可能比要求应聘者旋转一个矩阵（单单一个步骤）来得更好。而实现k均值聚类（互相依赖的多个操作）可能比确定直方图中最大的矩形来得更好。
4. 避免太难的问题
如果一个应聘者顺利解答了一个非常困难的问题，那么这相当于告诉了你很多有关他的技能方面的事情。但是，由于问题很难，大多数应聘者都不能很好的解答。那么期望从这个问题获得的信息的多少，就会受到这个问题的难度大小的影响。我们发现，最优的难度要比大多数面试官估计的难度要小得多。
我们现在遵循的经验法则是，面试官解答出问题的时间应该是他们希望应聘者解答问题所花时间的25％。所以，如果我正在针对一个小时的面试开发新的问题，则我就会要求我的同事（没有任何警告）能够在15分钟内回答出这些问题。同时，上文提到，问题要包含多个部分，并与实际工作相接近，所有这些要求结合在一起，使得最佳的面试问题真的是很直接很简单。
需要澄清的是，我并没有要求为了通过率而降低评判标准。我坚决主张对候选者问一些简单的问题，然后在评估中要查看应聘者是如何轻松地回答问题的。我主张问一些简单的问题，但是对评判的标准严格一点。对于大多数应聘者来说，这样带来的压力更小，这算是额外的好处吧。
举个例子，要求应聘者创建一个简单的命令行界面，其命令用于存储和检索键值对（如果他们完成的很好的话，可以添加一些功能）可能比要求应聘者实现算术表达式的解析器更好。而涉及到最常见的数据结构（列表、散列、树）的问题可能比有关跳转表、树堆或其他更模糊的数据结构的问题更好。
5. 对每个应聘者问同样的问题
面试就是对应聘者进行比较。目标是将应聘者分为能或者不能为公司做出贡献的两类人员（如果只是为单个职位雇用人员，则选择最适合的人）。正因为这样，向不同的应聘者提不同的问题是没有道理的。如果你以不同的方式评估应聘同一工作的不同应聘者，就会引入杂音。
我认为，人们之所以继续以一种随意的方式选择问题，是因为面试官喜欢这样。技术公司的工程师通常不喜欢面试。他们只是偶尔做这种事情，同时，这也让他们脱离了自己的主业。为了规范对每个应聘者所问的问题，面试官需要花更多的时间来学习这些问题，并讨论得分和答案。每当问题改变时，他们都需要重新再来一遍。另外，总是问同样的问题的确有那么一点点乏味。
不幸的是，这里唯一的答案就是要面试官付出自己的努力。一致性是进行有效面试的关键，这意味着要求对每个应聘者提出相同的问题，并标准化答案。别无选择。
6. 考虑使用多套面试题
你应该考虑提供多份完全不同的面试题，这与我之前的观点是冲突的。在设计面试题时，第一步要考虑的是有关技能方面的事情。然而，某些答案可能会互相之间冲突！例如，你可能需要招聘几个遵守规则的工程师，但同时又要招几个非常有创造性的工程师（甚至可能是相同的角色），这都是非常正常的。在这种情况下，应当考虑准备多套面试题。并且，关键问题是，你应该准备足够多的题目来标准化每套试题。这就是我们在Triplebyte公司所做的事情。你可以简单地询问每个应聘者他们喜欢哪种类型的面试。
7. 不要让自己因为证书而产生偏见
证书并不是毫无意义。从麻省理工学院或斯坦福大学毕业、或者在Google和苹果工作过的工程师，从整体上来说比其他那些没有这些经历的工程师表现的要更好一些。但问题是，绝大多数的工程师（包括我自己）都没有这些经历。所以如果一家公司太依赖于这些，那么他们会错失绝大多数的技术人员。在筛选步骤中给予证书一定的重视程度并不是完全不合理。我们在Triplebyte不会这么做（我们做的所有的评估100％都是不看他们的背景的）。但是，在筛选时给证书一定的重视程度可能是有意义的。
然而，让证书来左右最终面试的决定没有任何意义，而且我们有数据可以证明这种情况。拥有顶尖大学学位的应聘者的面试通过率比没有名牌大学学位的候选者高出30%。如果面试官知道应聘者拥有麻省理工学院学位的话，他们更愿意在面试中宽恕应聘者的错误。
这是一种杂音，你应该要避免。最简单的方法就是在把简历提交给面试官之前将学校和公司名称去掉。有些应聘者可能会提到他们的学校或公司，但我们在面试时并不知道应聘者的背景，而应聘者在技术评估时很少会提及这些。
8. 避免欺负应聘者
面试不仅仅是评估一个应聘者的技能，也是一个团队在接纳一个成员。对于后半句话来说，面试可以认为是一个通过仪式。是的，面试的压力很大，也让人讨厌，但是我们都经历了，应聘者也一样。当应聘者做得不好时，这种情况会更加突出。作为一名面试官，当看到应聘者因为一道简单的题目而卡住的时候，心里是沮丧的。你会变得脾气暴躁。当然，这只会增加应聘者的压力。
这就是你应该极力避免的东西。解决的办法就是对这个问题进行讨论并对面试官进行培训。我们使用的一个窍门是，当应聘者表现得实在很差时，你可以把评估模式转变为教学模式，评估模式的目标是评估应聘者的技能，而教学模式的目标是让应聘者理解问题的答案。在心理上做出改变会有很大帮助作用。当你处在教学模式时，就没有任何理由去隐瞒信息或是做除了友好以外的其他事情。
9. 根据应聘者具备的最强技能做决策，而不是平均或最小技能
到目前为止，我只讨论了个别问题，而没有讨论最后的面试决策。我的建议是尝试根据应聘者展示出来的最强技能水平，而不是平均水平或最低水平来做出决策。
这个可能你已经有意或者无意地在做了！做出是否录用决定的方式是这样的，每个面试应聘者的人坐在一起开会，如果至少有一个人强烈要求录用，而且没有其他人强烈反对，那么最终就会录用。而要让一位面试官强烈的支持他，就是应聘者在面试过程中需要做的事情了。我们的数据显示，最强技能是与面试最相关的属性。然而，要被录用，不能有任何一个面试官发出强烈的反对意见。当应聘者在一个问题上看起来真的很愚蠢的时候，强者的反对意见就会出现。
在这里我们发现了很多杂音。要成为一名熟练的工程师有很多种不同的方式，但几乎没有哪个应聘者可以全部掌握他们。这意味着如果你提出正确（或错误）的问题，任何工程师都可能会看起来很愚蠢。应聘者收到录用通知，那么说明他至少在某一个领域很牛逼（最强技能），而且在其他领域也不会太差。问题是，这就是杂音。同样的一个工程师，因为在网络问题上看起来很蠢而没有通过某一次面试，但他出色地通过了其他的面试，就因为这方面的问题没有出现。
我认为最好的解决办法是让公司专注于最强技能，并且对那些在面试中表现得不太好的人提供更多的帮助。这就是要寻找强有力的理由来肯定应聘者，而不是担心应聘者薄弱的方面。我不认为这是绝对的。当然，技术领域对于公司而言是至关重要的。但更多地关注最强技能可以降低面试的杂音。
为什么要进行面试？
我回答的最后一个问题是为什么要进行面试？我相信一些读者已经在咬牙切齿地说：“为什么要为这个破面试考虑那么多东西？完全可以采用家庭式项目，或者试用就业就可以了！” 毕竟，一些非常成功的公司使用的就是试用就业（让应聘者加入团队一个星期），或完全用家庭式项目取代现场面试。试用就业具有很大的意义。在工程师旁边工作一个星期（或者看着他们如何完成一个实质性的项目）肯定比观察他们在一个小时内如何解决面试问题能更好地衡量他们的能力。然而，有两个问题使得试用就业无法完全取代标准的面试：
对于公司来说，试用就业的代价很高。没有哪个公司会为每个应聘者花一个星期的时间。为了决定谁来试用就业，公司必须采用一些其他的面试过程。 对于试用就业（和大型的家庭式项目），应聘者要付出的代价很高。即使付他们薪水，也不是所有的应聘者都有时间。例如，从事全职工作的工程师可能根本没有时间来做这个。即使可以，许多人也不会这么做。如果工程师手里已经有了其他的录用通知，那么他们就不太愿意承担试用就业的不确定性。在Triplebyte的应聘者中，我们很清楚地看到了这一点。许多非常优秀的应聘者（手里还有其他公司的录用通知）不会做大型项目或试用就业。
试用就业是提供应聘者的绝佳选择。我认为如果你有足够的规模来支持多种招聘方式，那么添加试用就业这种方式是一个好主意。然而，作为面试的完全替代品是不可行的。
与应聘者谈论过去的经验有时会被用来替代技术面试。看看应聘者是否能在未来做好工作，从逻辑上来讲，可以看看他们在过去做了什么。我们已经在Triplebyte测试了这一点，不幸的是我们并没有总结出很好的结果。沟通能力（销售自己的能力）最终成为比技术能力更强的信号。我们经常会发现口才好的人喜欢夸大他们的作用，而谦虚的人则会淡化他们所做的事情。如果有足够的时间并问他们足够的问题，也许就能分清这两种人。然而，我们发现，在常规面试的时间内，谈论过去的经验并不是面试的一般替代方法。这是打破冷场并理解应聘者的兴趣好爱的不错的方法（并判断他们的沟通能力）。但这并不是一个切实可行的面试替代方案。
有关编程面试的好的方面
面试就是直接对技能进行评估。我有一些朋友，他们是老师，他们告诉我说，对老师的面试基本上就是衡量他们的沟通能力（销售自己的能力）和一张证书。这对于很多专业来说似乎都是如此。硅谷不是一个完美的精英聚集地。但我们至少要尝试直接考核那些重要的技能，并始终相信，任何有这些技能的人，不管他们的背景如何，都可以成为一名伟大的工程师。证书偏见往往阻碍了这一点。但是，我们在Triplebyte已经能够克服这个问题，并帮助很多具有非正规背景的人获得了很好的技术性工作。但是，在其他一些领域，例如，在法律领域，对证书的依赖度就很高。
程序员还可以对面试的方式进行选择。这是一个非常有争议的话题，我们做了一个实验，提供了多种不同类型的评估方式，我们发现大多数程序员仍然选择常规的面试。并且我们发现，只有少数程序员对采用试用就业或家庭式项目的公司感兴趣。无论是好是坏，编程面试是大家普遍接受的面试方式。其他类型的评估方式都是伟大的补充，但他们似乎不太可能取代面试作为评估工程师的主要方式。错误地引用丘吉尔的话，“除了所有其他尝试过的方法，面试是评估工程师最糟糕的方法。”
结论
面试很难。人类相当的复杂。从某种程度上来说，在四个小时的面试中判断一个人的能力是一个愚蠢的行为。我认为保持谦虚很重要。任何面试的过程注定要失败很多次。人太复杂了。
但这并不是说要放弃面试。尝试采用任人唯才的面试流程总比不尝试要好。在Triplebyte，我们的面试流程就是我们的产品。我们集思广益，然后进行测试，并随着时间的推移逐步改进。我认为，这就是改进工程师招聘方式的方法。在这篇文章中，我分享了过去两年里我们学到的一些大的事情。我很乐意收到反馈意见，并被告知这些想法对其他人有帮助。