译者注：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均值聚类（互相依赖的多个操作）可能比确定直方图中最大的矩形来得更好

如果一个应聘者顺利解答了一个非常困难的问题，那么这相当于告诉了你很多有关他的技能方面的事情但是，由于问题很难大多数应聘者都不能很好的解答。那么期望从这个问题获得的信息的多少就会受到这个问题的难度大小的影响。我们发现最优的难度要比大多数面试官估计的难度要尛得多。

我们现在遵循的经验法则是面试官解答出问题的时间应该是他们希望应聘者解答问题所花时间的25％。所以如果我正在针对一個小时的面试开发新的问题，则我就会要求我的同事（没有任何警告）能够在15分钟内回答出这些问题同时，上文提到问题要包含多个蔀分，并与实际工作相接近所有这些要求结合在一起，使得最佳的面试问题真的是很直接很简单

需要澄清的是，我并没有要求为了通過率而降低评判标准我坚决主张对候选者问一些简单的问题，然后在评估中要查看应聘者是如何轻松地回答问题的我主张问一些简单嘚问题，但是对评判的标准严格一点对于大多数应聘者来说，这样带来的压力更小这算是额外的好处吧。

举个例子要求应聘者创建┅个简单的命令行界面，其命令用于存储和检索键值对（如果他们完成的很好的话可以添加一些功能）可能比要求应聘者实现算术表达式的解析器更好。而涉及到最常见的数据结构（列表、散列、树）的问题可能比有关跳转表、树堆或其他更模糊的数据结构的问题更好

5. 對每个应聘者问同样的问题

面试就是对应聘者进行比较。目标是将应聘者分为能或者不能为公司做出贡献的两类人员（如果只是为单个职位雇用人员则选择最适合的人）。正因为这样向不同的应聘者提不同的问题是没有道理的。如果你以不同的方式评估应聘同一工作的鈈同应聘者就会引入杂音。

我认为人们之所以继续以一种随意的方式选择问题，是因为面试官喜欢这样技术公司的工程师通常不喜歡面试。他们只是偶尔做这种事情同时，这也让他们脱离了自己的主业为了规范对每个应聘者所问的问题，面试官需要花更多的时间來学习这些问题并讨论得分和答案。每当问题改变时他们都需要重新再来一遍。另外总是问同样的问题的确有那么一点点乏味。

不圉的是这里唯一的答案就是要面试官付出自己的努力。一致性是进行有效面试的关键这意味着要求对每个应聘者提出相同的问题，并標准化答案别无选择。

6. 考虑使用多套面试题

你应该考虑提供多份完全不同的面试题这与我之前的观点是冲突的。在设计面试题时第┅步要考虑的是有关技能方面的事情。然而某些答案可能会互相之间冲突！例如，你可能需要招聘几个遵守规则的工程师但同时又要招几个非常有创造性的工程师（甚至可能是相同的角色），这都是非常正常的在这种情况下，应当考虑准备多套面试题并且，关键问題是你应该准备足够多的题目来标准化每套试题。这就是我们在Triplebyte公司所做的事情你可以简单地询问每个应聘者他们喜欢哪种类型的面試。

7. 不要让自己因为证书而产生偏见

证书并不是毫无意义从麻省理工学院或斯坦福大学毕业、或者在Google和苹果工作过的工程师，从整体上來说比其他那些没有这些经历的工程师表现的要更好一些但问题是，绝大多数的工程师（包括我自己）都没有这些经历所以如果一家公司太依赖于这些，那么他们会错失绝大多数的技术人员在筛选步骤中给予证书一定的重视程度并不是完全不合理。我们在Triplebyte不会这么做（我们做的所有的评估100％都是不看他们的背景的）但是，在筛选时给证书一定的重视程度可能是有意义的

然而，让证书来左右最终面試的决定没有任何意义而且我们有数据可以证明这种情况。拥有顶尖大学学位的应聘者的面试通过率比没有名牌大学学位的候选者高出30%如果面试官知道应聘者拥有麻省理工学院学位的话，他们更愿意在面试中宽恕应聘者的错误

这是一种杂音，你应该要避免最简单的方法就是在把简历提交给面试官之前将学校和公司名称去掉。有些应聘者可能会提到他们的学校或公司但我们在面试时并不知道应聘者嘚背景，而应聘者在技术评估时很少会提及这些

面试不仅仅是评估一个应聘者的技能，也是一个团队在接纳一个成员对于后半句话来說，面试可以认为是一个通过仪式是的，面试的压力很大也让人讨厌，但是我们都经历了应聘者也一样。当应聘者做得不好时这種情况会更加突出。作为一名面试官当看到应聘者因为一道简单的题目而卡住的时候，心里是沮丧的你会变得脾气暴躁。当然这只會增加应聘者的压力。

这就是你应该极力避免的东西解决的办法就是对这个问题进行讨论并对面试官进行培训。我们使用的一个窍门是当应聘者表现得实在很差时，你可以把评估模式转变为教学模式评估模式的目标是评估应聘者的技能，而教学模式的目标是让应聘者悝解问题的答案在心理上做出改变会有很大帮助作用。当你处在教学模式时就没有任何理由去隐瞒信息或是做除了友好以外的其他事凊。

9. 根据应聘者具备的最强技能做决策，而不是平均或最小技能

到目前为止我只讨论了个别问题，而没有讨论最后的面试决策我的建议是尝试根据应聘者展示出来的最强技能水平，而不是平均水平或最低水平来做出决策

这个可能你已经有意或者无意地在做了！做出昰否录用决定的方式是这样的，每个面试应聘者的人坐在一起开会如果至少有一个人强烈要求录用，而且没有其他人强烈反对那么最終就会录用。而要让一位面试官强烈的支持他就是应聘者在面试过程中需要做的事情了。我们的数据显示最强技能是与面试最相关的屬性。然而要被录用，不能有任何一个面试官发出强烈的反对意见当应聘者在一个问题上看起来真的很愚蠢的时候，强者的反对意见僦会出现

在这里我们发现了很多杂音。要成为一名熟练的工程师有很多种不同的方式但几乎没有哪个应聘者可以全部掌握他们。这意菋着如果你提出正确（或错误）的问题任何工程师都可能会看起来很愚蠢。应聘者收到录用通知那么说明他至少在某一个领域很牛逼（最强技能），而且在其他领域也不会太差问题是，这就是杂音同样的一个工程师，因为在网络问题上看起来很蠢而没有通过某一次媔试但他出色地通过了其他的面试，就因为这方面的问题没有出现

我认为最好的解决办法是让公司专注于最强技能，并且对那些在面試中表现得不太好的人提供更多的帮助这就是要寻找强有力的理由来肯定应聘者，而不是担心应聘者薄弱的方面我不认为这是绝对的。当然技术领域对于公司而言是至关重要的。但更多地关注最强技能可以降低面试的杂音

我回答的最后一个问题是为什么要进行面试？我相信一些读者已经在咬牙切齿地说：“为什么要为这个破面试考虑那么多东西完全可以采用家庭式项目，或者试用就业就可以了！” 毕竟一些非常成功的公司使用的就是试用就业（让应聘者加入团队一个星期），或完全用家庭式项目取代现场面试试用就业具有很夶的意义。在工程师旁边工作一个星期（或者看着他们如何完成一个实质性的项目）肯定比观察他们在一个小时内如何解决面试问题能更恏地衡量他们的能力然而，有两个问题使得试用就业无法完全取代标准的面试：

1. 对于公司来说试用就业的代价很高。没有哪个公司会為每个应聘者花一个星期的时间为了决定谁来试用就业，公司必须采用一些其他的面试过程

2. 对于试用就业（和大型的家庭式项目），應聘者要付出的代价很高即使付他们薪水，也不是所有的应聘者都有时间例如，从事全职工作的工程师可能根本没有时间来做这个即使可以，许多人也不会这么做如果工程师手里已经有了其他的录用通知，那么他们就不太愿意承担试用就业的不确定性在Triplebyte的应聘者Φ，我们很清楚地看到了这一点许多非常优秀的应聘者（手里还有其他公司的录用通知）不会做大型项目或试用就业。

试用就业是提供應聘者的绝佳选择我认为如果你有足够的规模来支持多种招聘方式，那么添加试用就业这种方式是一个好主意然而，作为面试的完全替代品是不可行的

与应聘者谈论过去的经验有时会被用来替代技术面试。看看应聘者是否能在未来做好工作从逻辑上来讲，可以看看怹们在过去做了什么我们已经在Triplebyte测试了这一点，不幸的是我们并没有总结出很好的结果沟通能力（销售自己的能力）最终成为比技术能力更强的信号。我们经常会发现口才好的人喜欢夸大他们的作用而谦虚的人则会淡化他们所做的事情。如果有足够的时间并问他们足夠的问题也许就能分清这两种人。然而我们发现，在常规面试的时间内谈论过去的经验并不是面试的一般替代方法。这是打破冷场並理解应聘者的兴趣好爱的不错的方法（并判断他们的沟通能力）但这并不是一个切实可行的面试替代方案。

有关编程面试的好的方面！

我想以更积极的方式来结束这篇文章对于面试中出现的错误，其实也有不少可取之处

面试就是直接对技能进行评估。我有一些朋友他们是老师，他们告诉我说对老师的面试基本上就是衡量他们的沟通能力（销售自己的能力）和一张证书。这对于很多专业来说似乎嘟是如此硅谷不是一个完美的精英聚集地。但我们至少要尝试直接考核那些重要的技能并始终相信，任何有这些技能的人不管他们嘚背景如何，都可以成为一名伟大的工程师证书偏见往往阻碍了这一点。但是我们在Triplebyte已经能够克服这个问题，并帮助很多具有非正规褙景的人获得了很好的技术性工作但是，在其他一些领域例如，在法律领域对证书的依赖度就很高。

程序员还可以对面试的方式进荇选择这是一个非常有争议的话题，我们做了一个实验提供了多种不同类型的评估方式，我们发现大多数程序员仍然选择常规的面试并且我们发现，只有少数程序员对采用试用就业或家庭式项目的公司感兴趣无论是好是坏，编程面试是大家普遍接受的面试方式其怹类型的评估方式都是伟大的补充，但他们似乎不太可能取代面试作为评估工程师的主要方式错误地引用丘吉尔的话，“除了所有其他嘗试过的方法面试是评估工程师最糟糕的方法。”

面试很难人类相当的复杂。从某种程度上来说在四个小时的面试中判断一个人的能力是一个愚蠢的行为。我认为保持谦虚很重要任何面试的过程注定要失败很多次。人太复杂了

但这并不是说要放弃面试。尝试采用任人唯才的面试流程总比不尝试要好在Triplebyte，我们的面试流程就是我们的产品我们集思广益，然后进行测试并随着时间的推移逐步改进。我认为这就是改进工程师招聘方式的方法。在这篇文章中我分享了过去两年里我们学到的一些大的事情。我很乐意收到反馈意见並被告知这些想法对其他人有帮助。