翻译:你的技术面试做的真的很糟

翻译自:You suck at technical interviews

你根本不会做技术面试,是的,你不会。你在考察不必要的技巧,雇用了不适合的人,让你自己甚至你的公司蒙受损失。无需改变候选人群,你可以雇到对的人,让你的公司更好的运作,而你也将更加享受工作时光。

我知道这么说是很大胆的。自从我做技术面试以来的十年中,在大大小小的公司做了很多场技术面试,也可谓阅人无数。我并不敢说在面试上已经做到多么完美,但从另一个角度上讲,我很多错误的方法我倒是都用过,这也正是下面我想介绍的,不要重蹈我的覆辙。

你的考察方式是错的

不考已知

面试中一个主要的错误就是过分的看中应试者目前所具备的技能,而低估了其未来的增长潜力。不要为了一个面试者已知的知识而做出雇用决定。候选人中有很多人能够完成你交付的任务,但是能够出色完成的却不多。

更糟糕的是我们经常去评测应试者是否具备某种技能。比如问某种编程语言的一种晦涩的语法特性,或者问一个接口的使用细节。著名的fizzbuzz test测试,常常应试者要花二十分钟去完成,如果应试者回答错误,那确实不合格,但是如果回答正确呢?也就是考察了:你是否知道模运算。信息太有限了,纯属浪费时间。

不考背诵

我过去经常让应试者现场编写代码。现在看起来简直是场噩梦。通过在白板上编写代码来考察应试者完全是一个不切实际的想法,因为上面的代码更不无法得到验证。即使让应试者在计算机上编写代码也是错误的,因为这不是在考察编码能力,而是在考察在规定时间内,在其他人监视下完成编码工作。很多优秀的工程师也未必能够做到这点。如果你确定在时间压力情况下编写代码是工作中的一部分的话,你应该做的是去看看公司那里出了问题,而不是在面试中找到具备这种能力的工程师。

编码测试的题目经常是重实现一个通用的方法或者底层数据结构。而这恰恰是优秀工程师的反面。一个优秀的工程师会竭尽所能的复用已有的库来高效的解决全新的问题。而且也无法判断应试者是真才实学,还是仅仅是记下了其他的代码。背下来一个通过Google在15秒内就能够搜索的到的算法的实现细节又有什么用呢。

不看学历

面试官往往对拥有高学历的应试者印象深刻。上过名牌大学,或者上过普通大学,都不是评判一个工程师是否优秀的标准。在相关领域拥有博士学位当然很优秀,但是也不是一个可靠的判断条件。工程师的工作是编写代码,发布软件;研究员的工作是证明理论,编写证据。有人聪明也许能够做到这两点,但它绝不是给定的,也没有很强的相关性。

不看经历

简历上那些大公司的名字也被高估了。不要因为应试者在热门公司或者知名公司工作过就雇用他,尤其是在大公司工作过。大公司中各团队之间的差异也是巨大的。公司的成功并不证明应试者与之有什么关系。如果你对其所在公司的面试程序相当认可,你可以把应试者列为重点考察对象,仅此而已。

不雇亲朋好友

永远不要雇你的家人,除非万不得已,朋友也一样。既有关系会带来偏见和隐形的权利结构,结党营私也与公司利益不符。既有关系一旦被引入到工作中,你要么危及你的友谊,要么危及公司,与其二者皆伤不如放弃一者。

应该考察什么

面试第一阶段就应该问两个问题:

  • 应试者能够完成这项工作吗?这个问题不等同于“应试者能够现在完成这项工作吗?”,但是你需要证明应试者能够学会如何完成。
  • 应试者能够做得更好吗?答案必须是:是,否则就考虑放弃吧。

经验是加分项

语法和接口的题目是原本的目的是为了找到拥有相关经验的候选人,只是方式错了。相反的,应该询问应试者他们实际用到的技术,了解他们对这项技术了解多少。而且不能基于单一的事实就做出通过决定。如果应试者对应聘职位所需的某项技能不是特别了解,可以寻找他最了解的某项技能进行询问,并且让他做出阐述,以便考察应试者化繁为简,清晰表达的能力,这两项是工程师必备素质。

持续提高是及格线

快速学习能力比经验更加重要。你应该寻找那些有持续学习、付诸实践经验的候选人。了解他们的职业发展路线,找到承担更加重要职责的证据(可能与工作时间有关,但不是论资排辈)。记住,你雇的每个人每年都必须成长,那些停滞不前员工的价值会越发贬值。

聪明并且能把事情做成

Joel Spolsky的经典文章The Guerilla Guide to Interviewing(书:Smart and Gets Things Done)是技术招聘类文章中的最漂亮的文章之一。聪明与否比较难判断,我这里介绍了一些可能会帮得上忙的技巧。把事做成相对来说好判断一些,例如:他们有发布过真正的软件吗?

当然Joel和我的意见并非完全一致,我不认为现场编程测试有什么价值。Joel非常了解(或者曾经了解)指针运算,虽然这也是个能够考察应试者化繁为简能力的题目,但是同样也超出了很多出色的工程师的经验范畴,所以指针运算适合作为探讨性题目,而不应该是苛刻的测试。

沟通的智慧

就像我上面提到的,工程师两项主要工作就是化繁为简和清晰表达。只能在一方面表现优异的候选人,可以在其他领域做到卓越,但是却不是一个合格的工程师。世界上最优秀的程序员可以开发出难以置信的高效算法,但是工程师的工作是与团队一起完成目标,如果候选人不愿或者不能花时间与同事沟通协作,那他也就只能完成一半的职责。

不知为不知

在面试的过程中,我总是试图去寻找那些我比候选人更加擅长的领域进行提问。这当然不是想证明我有多牛,而是为了去考察一个应试者在遇到他们了解的技术上更加深入的问题时的表现。

较差的候选人会表现出尽力胡扯或者胡乱猜测的信号,这是非常可怕的信号,因为首先这些尝试无法奏效,更要命的是他们以为能。在Dunning Kruger看来他们就是垫底的那四分之一,他们无法准确判断自己的知识缺乏。这也以为着他们在其他类似场景下也会如此表现。

较强的候选人在超出他们能力范畴的时候会直接说:“我不知道”,并且能够有目的的开始询问。更强的候选会接着说:“但是如果我猜”,然后进行合理的推断。这显示出候选人理智诚实,并且有较强的好奇心。

交谈而不是审问

就像我之前说的,最好找到一个你比候选人更加了解的领域进行提问。这不是为了证明你比他聪明或者更强,而是为了探知他们能力的极限,去了解他们知识的广度和深度。当然你会触到候选人的能力边界,点到为止,并不代表他们面试失败。

主要的是让候选人也知道这个规则。你要尽可能的让你的候选人放松、舒服,因为这是他们在实际工作中应有的状态(如果不是,那你的公司也太差劲了,赶紧离职吧)。如果候选人在有精神压力或者惊慌失措的情况下,你得到的面试题目答案也没有任何意义了。就算是答案不错也一样,因为这些不是候选人在应有的状态下做出的。精神压力和惊慌失措不是常态,所以雇用一个只能在这种状态才能完成工作的员工,风险是很大的。

总有例外

如果候选人没有相关经验,也只好进行传统方式了,这对于初级应试者和跨界的有经验的应试者来说都是有可能的。

应试者刚刚完成不管是多么密集和广泛的培训课程,也不会了解如何成为一名合格的工程师。他们可能知道如何编写代码,但这只是工程师工作的一个方面。一些刚刚从大学毕业的学生甚至可能都无法完成超出其课程作业能力范围之外的编码任务。以我的经验,如果一个人从事专业编程的时间少于一年,可能没有足够的时间去了解他们是否真正的掌握。

刚从大学毕业的学生和其他初级的应试者都不了解什么是专业的工程师行为。这不但让面试变得困难,而且还要承担巨大的责任风险:如果雇用了他们,他们会永远任务这些不专业的行为是正常的公司的文化和工作行为。

大公司也容忍差的沟通者

另外一个另外规则是:如果你在一个大型公司工作,工程师都从事专门领域的工作。那你可能需要天才型的程序员,虽然他们不太善于表达他们的想法。如果你的公司真的很大,那你可以雇佣一个专门的管理人员,他的全部职责就是去跟这些天才沟通然后代替他们去与其他人进行沟通。这种办法确实可行,但是成本过高,对于创业公司来说是不切实际的。如果你有超过50个工程师,你倒是可以考虑这么做。

最后一个问题:你想与这个人共事吗?

当你确定候选人确实非常胜任这份工作,那你应该问问自己:你想与此人共事吗?并没有特定的题目可以得到答案,更多的是从他回答其他问题的过程中判断。这是一项个性判断,当然也非常非常的危险。个性往往是偏主观的,也就意味着你将把偏见引入公平的测试流程中来。例如个人偏见,隐患偏见,无意识偏见等等。

由于通过某种方式向应试者传递出了某种偏见,从而错过优秀的候选人,这种可怕的可能性存在,所以大家认为纯粹的、是非类的技术题目会比较好。当然不是这样,这样的题目只是更简单了而,而且也并没有防止任何的偏见:当你处了50道语法题,会很容易向应试者传递你可能更看重这方面的能力,从而装作他们很在行的样子。我曾经发现自己也这么干过。没有什么简单方式可以避免:你必须对偏见保持敏感,持续的保持关注,并且予以纠正,否则你可能会雇佣到错的人从而毁了公司。

寻找值得共事的人

创业公司把“我是否想与此人共事”这个问题搞错了,通常错误就是把这个问题与“我是否想与此人成为朋友”混为一谈了。

刨除所有假设,这两个问题是不同的。你可以与一个没有任何私交的人建立非常高效专业的职业关系。你的公司可没义务让大家觉得是“一个大家庭”。公司可不是你的联谊宿舍。你可不是在找一个酒友(相反如果你的公司恰好认为喝酒是公司文化的一部分,那你可能真的遇到大麻烦了)。

不要坏蛋

在npm公司的第一天我们就定下一条规矩:不要混蛋,最近我很高兴读到Polyvore(他在管理一个多样性个的工程师团队方面干的很漂亮)。不要“极品混蛋”,不要忌苦的人,不要愤青,不要恶霸,不要势利小人。不要与吝啬的,令人不快的,贬低同事的人一起工作。任何聪明才智和工作效率都无法弥补对团队士气的打击,而且一旦团队的文化被破坏是很难修复的。雇用了这些人,即使能够予以纠正,也是得不偿失。所以一旦错误的雇用了一个这样的人,不要犹豫,尽快把他辞掉。

最简单的分辨你是否在雇用一位坏蛋就是那句话“雇他,但不要在我的团队”。这往往说明候选人确实有能力,但是我不想与其直接合作。己所不欲勿施于人。

通常来说坏蛋是很好分辨的。如果一个人在性格上有较大的缺陷,那么在几个小时的面试过程中总会露出一些蛛丝马迹,这些缺陷会给日常的工作带来巨大的麻烦。比如傲慢,粗鲁,不注意细节。这些现象可能转瞬即逝,如果一旦端倪,就相信你的直觉免得漏掉。

不是为了团队融洽

我从没听过关于团队融洽的定义不是最终演变成了“让我们的偏见肆意妄为”。类似“他看起来挺适合这的”这种话尤其危险。像“他并不太合群”这种抱怨很容易滋生隐患。醒醒吧。办公室可不是你的单身宿舍,与你的同事在工作之外保持良好的社交关系可不是什么至关重要的事情。公司并没有要求你只要与他们成为同事,就得喜欢他们。

作为一个内向的、从来不喝酒的人,我可否请求你能否在面试的过程中不再搞什么社交活动了?职业交流和社交交流更不就不是一码事。一些人确实不善言谈,在酒吧里也很拘谨。请记住之前提到的让你的面试对象放松的部分,那说的是让他们感觉舒服,可不是说你自己。

你打算如何协调“不是为了团队融洽”规则,“不要坏蛋”政策,“寻找值得共事的人”需求,三者之间的关系?它们之间的区别很细微,但是却很重要:适合你团队的人可不一定适合做你的朋友。很多人都试图二者兼顾,但从长远来看不利于公司的稳定。

同质化是个灾难

我可是出于什么社会合理构成的原因才认为“差异性本质上就是好的”。那种看法也太蠢了。缺乏差异性对公司的危害是极为明显的。很多面试官潜意识的会雇佣“跟自己类似”的员工,而不是“最适合工作的”员工。世界上优秀的程序员根本不可能都一样,缺乏差异性是百害而无一利。它说明这个团队的招聘工作糟糕透了,说明经理和HR没有能力发现这个问题并予以纠正,最糟糕的是说明这个团队没有最好的工程师。

找不到理想的人怎么办

这个问题我也束手无策。NPM非常幸运,人们喜欢Node.js也喜欢npm,我们只是发出招聘需求就能够得到很多优秀的候选人。我工作的上一家创业公司,awe.sm,就没这么幸运了,我们不得不想尽一切办法去寻找合适的候选人。这需要很长的时间,而且需要尝试多种渠道:我们通过Hacker News上的招聘版块上发信息找到了一些优秀的候选人,通过我们的博客,甚至有一次是通过从TechCrunch的新闻报道中找到的。

切记:雇用一个差的员工比等待一个优秀的员工代价更高也更费时间。我们试图认为:“总有一天他们可以做到”,可这永远都是不可能的。不合适的员工不仅仅无法完成他们的本职工作,而且由于他们的失误会拖延所有人的效率,还得痛苦的推动他。在你不确定的时候就不要雇用,但如果你一旦雇了一个不称职的人,就必须尽你所能给他们帮助和指导。如果你发现他们没有任何进步,必须不留情面的辞退他们。

招聘确实很难

这就是你们一直以来在招聘中犯下的错误:当然这种面试最省事,因为没有过多的思考和创新。上面的一些建议不是很好给出清晰的定义也比较难遵循。但是面试确实如此,相当的困难,总是消耗比你期望更长的时间。上面提到的规则是模糊不清的,也没有清晰的测试可以验证。不过只要努力尝试,回报将会是强大的公司,更优秀的同事,更优秀的产品和更快乐的工作时光。作为面试官,你的唯一职责就是让这些变成可能。

Written on October 13, 2015