更多服务
2 年面试 900 多位工程师后,我总结了这些经验
作者:AMMON BARTRAM 来源:triplebyte.com 日期:2018-11-19 浏览

我们在Triplebyte做了很多面试。实际上,在过去的两年里,我面试了900多名工程师。这是否能很好地利用我的时间可以辩论!(我有时会冷汗醒来并怀疑它。)但无论如何,我们的目标是改善工程师的聘用方式。



为此,我们进行背景盲访,观察编码技巧,而不是凭据或简历。在工程师通过我们的流程后,他们会直接进入我们合作的公司(包括Apple,Facebook,Dropbox和Stripe)的最终面试。我们在不知道背景的情况下面试工程师,然后了解他们如何跨多家顶尖科技公司。我认为,这给了我们一些关于面试的最佳数据。


在这篇博文中,我将展示我们迄今为止从这些数据中学到的东西。技术面试在很多方面被打破。这很容易说。(许多博客文章都有!)困难的部分是如何处理它。我的目标是接受这一挑战,并为招聘经理和首席技术官提出具体建议。面试很难。但我认为许多问题可以通过谨慎的过程来解决。

现状

大多数面试流程包括两个主要步骤:

1. 申请人筛选

2. 面对面的最终面试


申请人筛选的目标是尽早过滤候选人,并在面试中节省工程时间。筛选过程通常包括招聘人员扫描候选人的简历(大约10秒钟),然后是30分钟到1小时的电话。我们合作的公司中有18%也使用带回家编程的挑战(代替电话屏幕或者除了电话屏幕之外)。有趣的是,筛选步骤是绝大多数候选人被拒绝的地方。


实际上,在我们合作的所有公司中,超过50%的候选人仅在简历扫描中被拒绝,另有30%的人在电话屏幕/带回家时被拒绝。筛选也是招聘可能最为反复无常的地方。招聘人员的数量不堪重负,需要做出快速决策。这是凭证和模式匹配发挥作用的地方。


面对面的最终面试几乎普遍包括一系列45分钟到1小时的课程,每个课程都有不同的面试官。会议主要是技术性的(每个公司有一两个专注于文化契合和软技能)。最终雇用/不雇用决定是在候选人离开后的决策会议上与招聘经理和所有面试候选人的人一起做出的。从本质上讲,候选人至少需要一名强有力的支持者,并且没有强烈的批评者可以提出要约。


然而,除了通用格式之外,最终的面试差异很大。

· 我们合作的公司中有39%在白板上使用标记进行面试

· 52%允许候选人使用自己的计算机(其余9%不一致)

· 55%让面试官选择自己的问题(其余45%使用标准的问题库)

· 40%的人需要在候选人中看到学术CS技能才能提出报价

· 15%的人不喜欢学术CS(并认为谈论CS是一个候选人不会有效的标志)

· 80%让考生在面试中使用任何语言(其余20%需要特定语言)

· 5%在面试中明确评估语言细节

 

在我们合作的所有公司中,22%的最终面试会带来工作机会。(这个数字来自向公司询问他们的内部候选人管道。通过Triplebyte申请的候选人在53%的面试后获得了报价。)大约65%的报价被接受(导致招聘)。1年后,公司对约30%的员工非常满意,并且已经解雇了约5%。

假阴性与假阳性

那么,现状有什么不对?毕竟,火灾似乎并没有失控。要查看问题,请考虑面试可能有两种失败方式。面试可能会导致工程师被雇用,后来被解雇(误报)。面试可以取消那些本可以做得好的人(假阴性)。糟糕的雇员是非常明显的,对公司而言是昂贵的(工资,管理成本和整个团队的士气)。糟糕的雇佣会吸引团队的精力。相比之下,能够完成工作但没有机会的候选人是看不见的。任何一个案例总是有争议的。由于这种不对称性,公司严重偏向于面试拒绝。


过程中的噪音会加强这种效果。在1小时内判断编程技巧从根本上说是困难的。再添加一个模式匹配和一些肠道呼叫的剂量以及上面讨论的公司偏好的复杂汤,你留下了非常嘈杂的信号。


为了在面对这种噪音时保持低误报率,公司不得不将决策偏向于拒绝。结果是一个错过优秀工程师的过程,仍然经常偏好真实技能的凭证,并且经常对所涉及的人感到反复无常和沮丧。如果贵公司的每个人都必须为他们目前的工作重新面试,那么会有多少百分比?这是一个可怕的问题。答案几乎肯定低于100%。当候选人被他们本可以做得很好的公司拒绝时,他们会受到伤害,当公司找不到他们需要的人才时会受到伤害。


需要明确的是,我并不是说公司应该在面试中降低标准。拒绝是面试的重点!我甚至没有说公司错误地认为误报远比假阴性更强。坏员工很贵。我认为嘈杂的信号与避免不良雇佣的需要相结合会导致非常高的漏报率,这会伤害到人们。解决方案是改善信号。


面试中减少噪音的具体方法

1.决定你正在寻找什么技能

没有一套技能可以定义一个好的程序员。相反,存在着各种各样技能的海洋。在这些领域,没有工程师可以强大。事实上,在Triplebyte,我们经常看到优秀,成功的软件工程师,他们拥有完全不相交的技能。那么,进行良好面试的第一步是决定哪些技能对于角色至关重要。我建议你问自己以下问题(这些是我们在Triplebyte上新公司时提出的问题)。


· 您需要快速,迭代的程序员,还是需要谨慎严谨的程序员?

· 您是否想要通过解决技术问题或构建产品来激励他人?

· 您是否需要特定技术的技能,或者智能程序员能否在工作中学习它?

· 学术CS /数学/算法能力是重要还是无关紧要?

· 理解并发/ C内存模型/ HTTP重要吗?


这些问题没有正确的答案。我们与成功的公司合作,每家公司都是双方公司。但关键是根据您的需求做出有意的选择。要避免的反模式只是随机选择面试问题(或让每个面试官决定)。


当这种情况发生时,公司工程文化可能会倾向于越来越多的工程师拥有对公司而言可能并不重要的特定技能或方法的方向,而没有这种技能(但其他重要技能)的工程师则被拒绝。


2.尽可能接近实际问题提问

聘请专业程序员来解决数周和数月的庞大而庞大的问题。但是,面试官没有数周或数月的时间来评估候选人。每位面试官通常有1小时。因此,面试官会考虑候选人在胁迫下迅速解决小问题的能力。这是一种不同的技能。它是相关的(访谈不是完全随机的)。但它并不完全相关。最小化这种差异是开发面试问题的目标。


这是通过使面试问题尽可能与您希望候选人做的工作(或您想要测量的技能)相似来实现的。例如,如果你关心的是后端编程,那么要求候选人构建一个简单的API端点然后添加功能几乎肯定比要求他们解决BFS字链问题更好。如果您关心算法能力,请求候选人将算法应用于问题(例如,构建一个简单的搜索索引,可能由BST和哈希映射支持以提高删除性能)几乎肯定比要求他们确定是否更好凹点包含在凹多边形中。和调试挑战,候选人在真正的代码库中工作,


这就是说,有做在白板上进行面试的说法。作为一名面试者,我不在乎工程师是否记住了Python itertools模块。我关心他们是否可以考虑如何使用迭代器来解决问题。通过让候选人在白板上工作,我将他们从正确的语法中解放出来,让他们专注于逻辑。最终我认为这个论点失败了,因为对于不同的格式没有足够的理由。您可以通过允许候选人在计算机上工作来获得所有好处,但告诉他们他们的代码不需要运行(甚至更好,使其成为一个开放的书籍面试并让他们通过Google查找他们想要的任何内容)。


关于面试问题应该反映工作的想法有一个重要的警告。面试问题不受外部依赖的影响是很重要的。例如,要求候选人在Ruby中编写一个简单的Web scraper似乎是一个很好的真实字问题。但是,如果一个候选人需要安装Nokogiri(一个可能很难安装的Ruby解析库)并且他们最终会在本地扩展中挣扎30分钟,这就变成了一个糟糕的面试。不仅浪费了时间,候选人的压力也已经消失了。


3.提出无法提供的多部分问题

面试问题的另一个好的经验法则是避免可以“放弃”的问题,即避免问题,即候选人可以在Glassdoor上提前阅读的一些神奇的信息,以便他们轻松回答。这显然排除了脑筋急转弯或任何需要洞察力的问题。但它超越了这一点,并且意味着问题需要是一系列相互依赖的步骤,而不是单一的核心问题。考虑这个问题的另一个有用的方法是问问自己是否可以帮助陷入困境的候选人,并且仍然以积极的印象结束面试。在一个步骤的问题上,如果你必须给候选人提供重要帮助,他们就会失败。在一个多部分问题上,你可以帮助一步,然后候选人可以获得其他一切并且做得很好。


这很重要,不仅因为您的问题会泄漏到Glassdoor上,而且(更重要的是)因为多部分问题不那么嘈杂。好的候选人会变得紧张并陷入困境。能够帮助他们并让他们恢复是很重要的。根据他们最近是否看到类似的问题,并且可能只是机会,候选人解决任何一个编程逻辑的能力有很大的噪音。多部分问题可以消除一些噪音。他们还让候选人有机会看到他们的努力雪球。应用于一个步骤的努力通常有助于他们解决后续步骤。这是一项重要的动态,在做实际工作时,在面试中捕捉它会降低噪音。


举一个例子,要求候选人在一个终端(一系列多个步骤)中实现游戏连接四可能比要求候选人旋转矩阵(一步,一些简单的赠品)更好的问题。并且实现k-means聚类(彼此构建的多个操作)可能比确定可以适合直方图的最大回转更好。


4.避免难题

如果一个候选人很好地解决了一个非常难的问题,那就会告诉你很多他们的技巧。但是,由于问题很难,大多数候选人都无法很好地解决问题。因此,从问题中获得的预期信息量会受到问题难度的严重影响。我们发现最佳难度级别比大多数面试者猜测的要容易得多。


面试候选人时,有两个信号来源:他们是否对问题给出“正确”答案,以及他们的过程/他们如何轻易地得出答案,这一事实放大了这种效应。我们在Triplebyte上收集了有关这方面的数据(对候选人是否达到正确答案,以及他们花了多少努力,然后衡量哪些分数预测公司的成功进行了评分)。我们发现的是权衡。对于更难的问题,候选人是否正确回答了大部分信号。相比之下,对于更简单的问题,大多数信号都出现在候选人的过程中以及他们挣扎多少。考虑到两种信号源,最佳点是更容易结束。


我们现在遵循的经验法则是,面试官应该能够在他们期望候选人花费的25%的时间内解决问题。所以,如果我正在为1小时的面试开发一个新问题,我希望我的同事(没有任何警告)能够在15分钟内回答这个问题。与我们使用多部分真实世界问题这一事实相结合,这意味着最佳面试问题非常简单明了。


要明确的是,我并不是在争论通过率降低标准。我主张提出简单的问题,然后在评估中包括候选人如何轻松地回答问题。我主张提出简单的问题,但后来判断相当严厉。这就是我们发现的优化信号。对于大多数申请人来说,它具有降低压力的额外好处。


举例来说,要求候选人创建一个简单的命令行界面,其中包含用于存储和检索键值对的命令(如果它们运行良好,则添加功能)可能比要求候选者实现算术表达式的解析器更好。涉及最常见数据结构(列表,散列,可能是树)的问题可能比关于跳过列表,treaps或其他更模糊的数据结构的问题更好。


5.向每位候选人询问相同的问题

访谈是关于比较候选人。我们的目标是将候选人分类为能够为公司做出贡献的人和那些不能做出贡献的人(以及在雇用单一职位时,选择最适合的人)。鉴于此,没有理由向不同的候选人提出不同的问题。如果您以不同的方式评估同一工作的不同候选人,则会引入噪音。

我认为,以特别的方式选择问题仍然是常见的原因是因为这是面试者更喜欢的问题。科技公司的工程师通常不喜欢面试。这是他们偶尔做的事情,它使他们远离他们的主要焦点。为了使每个候选人提出的问题标准化,面试官需要花更多的时间来学习问题,并谈论评分和交付。每当问题发生变化时,他们都需要重新做这件事。此外,总是问同样的问题只是一点点乏味。


不幸的是,这里唯一的答案是让面试者付出努力。一致性是进行良好面试的关键,这意味着要求每位候选人提出相同的问题,并规范交付。根本没有其他选择。


6.考虑运行多个轨道

与我之前的观点相反,请考虑提供几种完全不同的面试版本。设计面试的第一步是考虑哪些技能很重要。但是,有些答案可能会有冲突!例如,想要一些非常狡猾的工程师,以及一些非常高效/迭代的工程师(甚至可能是同一个角色),这是很正常的。在这种情况下,请考虑提供多个版本的访谈。关键点在于,您需要达到足够的比例,以便完全标准化每个轨道。这就是我们在Triplebyte所做的事情。我们发现,您可以简单地询问每位候选人他们更喜欢哪种类型的面试。


7.不要让自己受到凭证的偏见

证书不是没有意义的。从麻省理工学院或斯坦福大学毕业,或者在谷歌和苹果公司工作的工程师,作为一个团队,实际上比没有工作的工程师更好。问题是绝大多数工程师(包括我自己)都没有做过这些事情。因此,如果一家公司过于依赖这些信号,他们将会错过大多数熟练的申请人。在筛选步骤中给予证书一些权重并非完全不合理。我们不会在Triplebyte这样做(我们所有的评估都是100%背景盲人)。但是在筛选时给予一些重量可能是有意义的。


然而,让凭据影响最终面试决定是没有意义的。我们有数据显示这种情况发生了。对于我们背景盲人流程的特定绩效水平,拥有顶尖学校学位的候选人继续以比没有名牌简历的候选人高出30%的速度通过公司面试。如果面试官知道候选人拥有麻省理工学院的学位,他们更愿意在面试中原谅粗糙的地方。


这是噪音,你应该避免它。最明显的方法是在将简历中的学校和公司名称提交给面试官之前。有些候选人可能会提到他们的学校或公司,但是我们在不知道候选人背景的情况下进行所有面试,而且在技术评估期间候选人提出这个问题实际上非常罕见。


8.避免欺侮

面试失败的最丑陋方式之一是他们可以采取欺侮的方面。他们不只是评估候选人的技能,他们也是关于招收成员的团队或团队。在第二种能力中,它们可以成为一种成年礼。是的,面试既压力又可怕,但我们都是这样做的,候选人也应如此。当候选人表现不佳时,这可能会更加突出。作为一名面试者,当答案看起来如此明显时,看到一位候选人对问题嗤之以鼻是令人沮丧的!你可以得到短暂的沮丧和沮丧。当然,这只会增加申请人的压力。


这是你想要离一英里远的地方。解决方案是讨论问题并培训面试者。我们使用的一个技巧是,当一个候选人做得很差时,从目标是判断候选人的评估模式切换到教学模式,其目标是让候选人理解问题的答案。精神上的切换可以帮助很多。当你处于教学模式时,没有理由隐瞒信息或除了友好之外的其他任何东西。


9.根据最高技能做出决定,而不是平均技能或最低技能

到目前为止,我只讨论过个别问题,而不是最终的面试决定。我的建议是尝试根据候选人显示的最高技能水平(跨越您关心的技能领域),而不是平均水平或最低水平。


这可能是你已经在做的,无论是有意还是无意!雇用/不聘用雇员的决定方式是,每个与候选人面谈的人都聚在一起参加会议,并且如果至少有一个人强烈支持招聘,并且没有人强烈反对,则会提出要约。为了让一位面试官大力支持,候选人需要做的就是面试的一部分。在我们的数据中,最高技能是与公司面试的至少一部分最相关的属性。然而,要成为一个提议,候选人也不需要任何人强烈反对他们。当候选人在一个问题上看起来非常愚蠢时,强烈的努力就来了。


在这里我们发现了很多噪音。有很多不同的方法可以成为一名熟练的工程师,几乎没有候选人可以掌握所有这些。这意味着如果您提出正确(或错误)的问题,任何工程师都会看起来很愚蠢。候选人获得报价,然后,当至少一次面试与一个强度区域(最高技能)排队时,没有区域排列显着的弱点。问题是这很吵。同一位工程师因为他们在关于网络的问题上看起来很愚蠢而未能通过一次面试,因为这个话题没有出现,所以他们面试了其中的颜色。


我认为,最好的解决方案是让公司专注于最高技能,并且对面试部分看起来很糟糕的人提供更多的便利。这就是,寻找有理由说出肯定的理由,而不是担心候选人很弱的技术领域。我不想对此绝对。当然,技术领域对公司而言至关重要。并且决定你想拥有一种文化,团队中的每个人都在某个特定领域处于一定水平,这可能是有道理的。但更多地关注最高技能确实会减少面试噪音。


为什么要面试

我应该回答的最后一个问题是为什么要面试?我确信有些读者一直在咬牙切齿,并说“为什么要想一个破碎的系统呢?只需使用带回家的项目!或者只是试用就业!“毕竟,一些非常成功的公司使用试用工作(候选人加入团队一周),或完全取代现场项目的面对面面试。试用就业很有意义。花一个星期在工程师旁边工作(或者看看他们如何完成一个实质性项目)几乎可以肯定地提供一个更好的衡量他们的能力,而不是看他们解决面试问题1小时。


然而,有两个问题使得试用工作不能取代标准面试:


1. 试用期对公司来说是昂贵的。没有公司可以与每个申请人一起度过整整一周。要决定谁参加试验,公司必须使用其他一些面试流程。


2. 对于候选人来说,试用就业(和大型带回家项目)是昂贵的。即使他们获得报酬,也不是所有候选人都有时间。例如,一名从事全职工作的工程师可能根本无法休假。即使他们可以,许多人也不会。如果工程师已经有了工作机会,他们就不太愿意承担工作试验的不确定性。我们在Triplebyte候选人中清楚地看到了这一点。许多最佳候选人(手头有其他优惠)根本不会做大型项目或工作试验。


试用就业的结果是提供一些候选人的绝佳选择。我认为如果你有支持多个曲目的规模,添加一个试用就业轨道是一个好主意。然而,作为访谈的完全替代,这是不可行的。


与候选人谈论过去的经验有时也被提出作为技术面试的替代品。为了确定候选人是否可以在将来做好工作,逻辑就是,看看他们过去做了些什么。我们在Triplebyte测试了这个,不幸的是我们没有取得很好的效果。沟通能力(推销自己的能力)最终成为比技术能力更强的信号。


找到口口相传的人夸大自己的角色(为团队的工作赢得信任),以及谦虚的人,他们淡化他们所做的事情,这种情况太常见了。如果有足够的时间和足够的质疑,应该可以深入了解这一点。但是,我们发现,在定期面试的时间范围内,谈论过去的经历并不是面试的一般替代品。这是一个与候选人打破僵局并了解他们的兴趣(判断沟通能力和文化适应性)的好方法。但这不是一个可行的完全取代面试


编程面试的好处!

我希望以更积极的方式结束这篇文章。对于面试中出错的一切,对他们来说有很多是对的。

访谈是直接的技能评估。我有老师的朋友,他们告诉我,老师的面试基本上是衡量沟通能力(推销自己的能力)和证书的标准。这似乎适用于许多职业。硅谷并不是一个完美的精英。但我们至少会尝试直接衡量重要的技能,并保持开放的想法,任何拥有这些技能的人,无论背景如何,都可以成为伟大的工程师。凭证偏见常常妨碍这一点。但是我们已经能够在Triplebyte中克服这个问题,并且帮助很多具有非常规背景的人获得了很好的技术工作。我不认为Triplebyte是可能的,例如,在法律领域。对凭证的依赖太高了。


程序员也选择面试。虽然这是一个非常有争议的话题(当然程序员有不同的感受),但当我们开展提供不同类型评估的实验时,我们发现大多数程序员仍然会选择定期面试。我们发现只有少数程序员对使用试用或带回家项目的公司感兴趣。无论好坏,编程面试似乎都在这里说。其他类型的评估是很好的补充,但它们似乎不可能取代面试作为评估工程师的主要方式。要错误引用丘吉尔,“面试是评估工程师最糟糕的方式,除了所有其他经常尝试过的方法。”


结论

面试很难。人类无可救药地复杂化。在某种程度上,在4小时的面试中判断人的能力只是一个愚蠢的差事。我认为保持谦虚很重要。任何面试过程都会在很多时候失败。人太复杂了。


但这不是放弃的理由。Triplebyte,我们的面试是我们的产品。我们集体讨论想法,测试它们,并随着时间的推移而改进。我认为,这是改善工程师聘用方式所需的方法。