This is why you never end up hiring good developers 这就是为什么你永远招不到优秀的开发人员

中文为我的译文，英文为原文

英文原文地址：http://qz.com/258066/this-is-why-you-dont-hire-good-developers/

这就是为什么你永远招不到优秀的开发人员

 

你并不擅长主持技术面试。是的，就是你。你没有找对相应的技巧，雇佣了不适合这份工作的员工，这会毁掉你自己和你的公司。然而，你并不需要改变应聘者群体，就能雇佣到完全不同的人。你的公司将会发展得更好，你也会更享受你自己的工作。

 

我知道这是很大胆的断言。从我资历深到足够去面试应聘者的这十年来，我已经主持了很多场的技术面试，成为了许多或大或小公司招聘团队的一员，并且观察了各种不同类型的录用会给这些公司带来什么影响。我并不是在宣称我在聘用员工这件事上做的很完美——事实上，我已经做过了几乎所有我将要告诉你不要去做的错事。以下这些就是我迄今为止学习到的东西。

 

你在寻找错误的事物

 

1.不要为了应聘者已经掌握的技能雇佣他们

人们在对应聘者进行面试的时候犯的最基本的错误就是高估了他们目前已经掌握的技能，而低估了他们将来的成长空间。不要为了他们已经掌握的技能录用他们。恰好会做这份工作的人的数量远远小于足够聪明、能学习着胜任这份工作的人的数量。

比起这个更为糟糕的是我们判断应聘者是否掌握相应技能的方法。面试官在面试中会问一些晦涩的编程语言的语法特征问题，或者是一些流行的应用程序编程接口的细节问题。很著名的fizzbuzz测试 【注：让应聘者写一段会输出整数1-100的代码，如果是3的倍数则用“fizz”替换输出，如果是5的倍数则用“buzz”替换输出，如果既是3的倍数又是5的倍数则用“fizzbuzz”替换输出】只会简单的问一句：“你知道取模操作吗？”如果对方的答案是没有，他们很可能就是个糟糕的应聘者。这个问题虽然简单，但它正好可以提供给我们想要的那一点信息。不过为此人们将会在面试中花费20分钟的时间在这上面，这是对有限时间的巨大浪费。

 

2.不要为了应聘者在面试时记得的东西雇佣他们

我过去常常让应聘者在面试的过程中写代码。这是非常糟糕的事。在白板上写代码远不能展示他们真正写代码的能力。甚至让他们在电脑上写代码也是错误的测试编程能力的方式（这更多地测试了他们的临场能力）——你让他们在有限的时间，并且在有人旁观的压力下写代码。一些我认识的最棒的工程师在这种状况下都无法表现好。并且如果你相信在紧张的时间压力下写代码是你日常工作的一部分，那你应该检查一下这是不是你们公司出现了问题。

在白板上写代码的面试通常也会让面试者（用更新颖的方法）去重新实现一些常见的解决方法或者底层数据结构。这恰好不是一个优秀的工程师该做的事。一个优秀的工程师会尝试着利用程序库去解决（除最新颖问题外的）尽可能多的问题来增大产量。白板测试同时也不能测试出面试者真正的能力----你怎么知道他们是真的在解决问题而不是仅仅背下了其他人的解决方案？把你仅用15s的时间就能搜索出来的算法背下来没有任何的价值。

 

3.不要为了应聘者的高学历雇佣他们

有些面试官会被学术证书打动。而在我的经验积累中，上过好大学或者根本没上过大学一点也不能衡量应聘者能否具备工程师的能力。在相关领域取得过博士学位是很棒，但是它也并不是一个可靠的预测准则：工程师写代码、装软件，而学术者证明理论、给概念写证明。聪明的人或许能够两者兼备，但这两者之间绝没有很大的联系。

 

4.不要为了应聘者的前东家雇佣他们

人们高估了应聘者简历上前东家的名气。不要因为应聘者曾经在一家很热门或是很出名的公司工作而雇佣他们，特别是当这些公司是大型公司的时候。大型公司的团队之间差异非常大。一家公司很成功并不意味着你的应聘者对它有任何贡献。如果你对一家公司的雇佣流程足够熟悉，能保证它总能挑选到合格的人，那你可以优先考虑曾在那家公司工作的应聘者。除此之外，还是先考虑综合实力排在应聘者队伍最前面的人吧。

 

5.不要雇佣朋友和家人

你如果能够避免雇佣家人和朋友，那就绝对不要雇佣他们。你们之间已经存在的关系会让你有偏见，在公司中形成利益小团体和责任网，而这些都和你公司的利益有冲突。你只能向你的朋友家人或者你的公司妥协。比起陷入被逼着选择其中一方的困境，你还是完全避免这个冲突比较好。

 

你应该寻找的是什么

 

你主持面试的第一阶段应该试图去回答以下两个问题：

（1）他们能做这份工作吗？这跟“他们现在能做这份工作吗？”完全不一样。不过如果他们现在不能做这份工作，你必须要确定他们能够学会怎样去做。

（2）这份工作他们能越做越好吗？回答必须是肯定的。

 

1.相关的工作经历是个加分项，但不是必要条件

询问有关语法和应用程序接口方面的问题旨在找寻有相关工作经历的人，但是这并不是一个好方法，和应聘者谈谈他们在这份工作上将会用到的技术，看他们对此了解多少。但这并不是要你仅仅根据这个决定雇用或淘汰他们。如果他们并不太了解做这份工作所需要的技能，那就转换话题，聊聊另外一个他们掌握的技能，让他们多谈谈那方面的东西，如果有必要的话，让他们细细地解释给你听。你要寻找的是能够理解复杂的论题并能将之解释清楚的人，这两者才是工程师应该具备的能力。

 

2.能不断的进步是一项必要条件

应聘者的学习方法和学习的速度比他们已经掌握的知识重要得多。你要寻找在以往经历中，能学习到新技能并成功地运用该技能的人。谈谈他们的工作经历，看他们的工作责任心有没有日益增加（这跟资历有关，但并不相同）。记住你雇佣的人每年都要有提升，没能一直提升意味着他们在退步，除非他们具备的技能的价值提高了。

 

3.聪明机警，能把事情做好

Joel Spolsky的经典论文《The Guerilla Guide to Interview》和它的姊妹篇《Smart and Gets Things Done》是关于雇佣技术人才的最棒的文章之一。聪明与否是很难判断的，不过我将要谈论的一些技巧应该会对这种判断有帮助。但除此之外，应聘者能把事情做好也同样重要，你可以问问他们测试过真正的软件吗。

不过Joel和我并不是对每件事的看法都相同。我并不觉得现场的编程测试很重要，而Joel就（或者曾经是）热衷于在面试中谈论对指针数学计算的理解，这也能测试出应聘者是否具有我上面提到过的能“能理解复杂论题”的能力，但很多优秀的工程师也都并不具备这方面的能力。所以这虽然可以作为一个有用的话题，但并不应该成为一个尖刻的测试。

 

4.能聪明的谈论技术

我上面提到过，作为一个工程师，应具备的两项技能是能理解复杂概念，并且能清楚地把这个概念传递给别人。那些只能做到其中之一的人可能在其他领域能有好的建树，但却无疑会是个很糟糕的工程师

 

5.了解自己不知道的东西

当我在面试应聘者的时候我总是试图问一些我比他们更了解的专业知识方面的问题。这并不是在证明我更聪明，而只是在测试当他们在面对超出他们知识领域的问题时是如何反映的。

最不合格的参与者会试图含糊带过或者大胆猜测。这是一个很糟糕的信号，首先因为这并不能解决问题，其次是因为他们以为这种程度的回答就可以了。在达可效应【注：达克效应（D-K effect），全称为邓宁-克鲁格效应（Dunning-Kruger effect）。  它是一种认知偏差现象，指的是能力欠缺的人在自己认识不足的基础上得出错误结论，但是无法正确认识到自身的不足，察觉到自己的错误行为。这些能力欠缺者们沉浸在自我营造的虚幻的优势之中，常常高估自己的能力水平，却无法客观评价他人的能力。】中，他们就是那种最底层的人，没有能力准确判断他们缺乏了相关的知识。这也意味着他们在其他的场景下也会如此表现。

优秀的参与者会直接说他们不知道——一旦这个问题超出了他们的能力范围。并且会开始询问这方面的知识。最优秀的参与者会说：“但是如果我必须要猜的话…”然后试图推算出正确答案。这是很棒的表现，因为它展现了参与者的诚实和想要把事情弄清楚的欲望。

 

6.这是一个交谈的过程，不是一个审讯的过程。

正如我之前所说，去寻找一个你比面试的对象更了解的领域是一个好主意。但这并不是为了证明你比他们更聪明或者是更优秀，这是为了发现他们有多少特长，感受一下他们知识储备的深度和广度。你也许会碰到他们知识的边缘地带，而这也正是关键。如果你发现他们的知识触底了，那也不意味着他们失败了。

让他们也意识到这一点，这很重要。你要让你的应聘者感到放松和舒适，因为这是他们做这个工作的时候就该有的状态（如果感受不到这些，那说明你的公司很糟糕，请离开这家公司吧）。你从紧张的、倍感压力的应聘者中得到的答案基本上都是没什么用处的。即使他们回答的是很好的答案，也是这个样子的，因为回答的都不是具有代表性的答案。压力和恐慌不是一个长期的状态，所以你冒险录用了一个只在有压力的情况下表现好的人。

 

 始终会有一个例外

 

如果你的应聘者之前没有任何相关的经验，你唯一的选择就是一个比较传统的技术面试。这对于没有任何经验的新人和从别的行业转行过来的有工作经验的人来说都是这样的。

假设有个人刚完成了培训课程，无论课程多么的紧凑，也无论他表现的多么好，他也不知道如何成为一个工程师。他们也许知道怎么敲代码，但这只完成了一半的工作。有些刚毕业的大学生如果离开了书上的标准答案，甚至都不一定真的知道该如何编程。从我的经验来看，如果某个人专业从事编程不到一年，不到一年的这些时间根本不够用来判断这个人是否擅长编程。

刚从大学毕业的毕业生以及其他类似的新人也完全不知道该如何表现的专业一些。这不仅仅会让面试变的更麻烦，这对你也会是个很重的责任：一旦你雇佣了他们，你的公司的文化和工作经验会在他们看来就是十分普通的公司该有的样子。

我的规则里的另外一个例外就是你工作在非常大的公司里，大到工程师们的都精于极小的一部分工作。

当这种情况发生的时候，你其实需要那种并不擅长解释自己在做什么的很牛的程序员。如果你的公司足够大，你也可以雇一个经理全职负责和这个很牛的程序员的沟通，成为他和公司其他员工交流的桥梁。这么做十分有效，但花销也十分大，所以并不是创业公司一开始就可以承担的起的。当你已经有了第一批50名工程师的时候，也许你可以考虑一下。

 

问问你自己：我愿意和这个人一起工作吗？

 

当你确信这个应聘者能胜任这份工作的时候，你就要回答另外一个问题：我愿意和这个人一起工作吗？对于这个问题是没有一个特定的答案的，这只能从他们如何回答其他问题中才看的出来。这就有可能要做一个性格测试，而性格测试也是一个非常令人担忧的领域。性格测试是非常主观的，这就意味着你会把自己的偏好带进来。个人的偏好，不明显的偏好，无意识的偏好。

由于一些可能你自己都不知道的偏好，会导致你拒绝了一个很好的应聘者，这也正是为什么人们会觉得用单纯只有对错的问题会更好。其实并不是这样子的，它们只是更简单而已。事实上，这对避免偏好没有任何的帮助。当你有50个语法问题要问的时候，很容易就会给出暗示，并且将你觉得更好的回答偷偷的把信息传递给了应聘者。我发现过我自己有这种行为。这没有一种简单的解决方法，你必须注意到这些偏心，不断地有意识发现他们并且改正他们，不然你会因为你雇了不合格的人而毁了你的公司。

 

1.寻找一个共事的伙伴

我最常看到创业公司的的一种现象是会把“我愿意和他一起工作吗？”和“我愿意和他交朋友吗？”这两个问题混淆起来。

把那种想法赶出你的大脑。他们根本不是同一回事。即使你和其他人没有什么共同爱好或是相似之处，但你也完全可以和其他人进行出色的、专业的工作交流。你的公司并不需要大家觉得是一个“大家庭”。这当然不是你的什么兄弟会（常见于美国大学的一种组织）的屋子，你并不是在挑一个酒友（但是另一方面，如果你的公司认为喝酒也是公司文化中很重要的一部分，你也许就要考虑一些更深层次的问题了）。

 

2.不要混球

从在npm公司的第一天开始我们就实施了不要混球的政策。并且我也很高兴知道Polyvore（某个看起来在维护一个多样化的工程团队方面做的很棒的公司）也有类似的政策。

不要“高智商混球”，不要愤世嫉俗的人，不要恶霸，不要势利小人。不要和一些刻薄的，不愉快的，会贬低同事的人一起工作。没有什么辉煌成果或者工作产量能弥补失去的团队的士气，而且一旦团队的文化被破坏了就很难再恢复了。就算雇佣这些人能帮你度过一段公司的困难期，也不值得这样做。如果你意外的招了一个这样的人，赶紧毫不犹豫的开除他们。

发现自己正在录用的是个混球的最简单的方式就是：“你也许会录用他，但不是为了这个团队而录用他”。这意味着“这个人的确是有技术的，但是我并不想和他直接共事”。既然你不愿意和他共事，那别人也不会愿意的，所以就不要让他影响其他人了。

但一般来说，混球是很容易发现的。如果有人有严重的性格缺陷，甚至在面试的几个小时里都不能好好的收敛一些，那在以后真正的工作环境中会产生很大的问题。傲慢、无礼、不注重细节——这些情况会很快就显现出来，一旦你发现了这些迹象，请相信你的直觉，尽量去避免这些问题。

 

3.不要为了“团队建设”而雇人

我所听到过的“团队建设”的定义到最后都听上去像“团队偏好建设” 。像“他们看起来就像是属于这里的”的话听起来很可怕。更可怕的是一些类似于“不喜欢我们平常做的那些社会活动”。成熟点吧，你的办公室不是你的兄弟会屋子，和你的同事出去社交活动并不是什么（为了进入兄弟会而必须的）关键考验。只要你愿意和他们一起工作，没人会要求你在社交当中也喜欢和他们一起。

而我，作为一个内向的，并且终生不喝酒的人，可以提出一个个人请求吗？请你不要把社会活动带进你的招聘过程中吗？职业交流和社会交流是不一样的。有些人喜欢在闲谈的时候小酌一口，但是在酒吧会感到不舒服。还记得要确保你的面试对象感到放松和舒适吗？是让他们觉得舒适，而不是你。

你要怎么调解好“不要为了团队建设而雇人”、“不要混球”、“录用你想要与之共事的人”这几个要求呢？区别是很微妙的，但也是很重要的：那个对你团队有帮助的人，不一定就是你想要和他交朋友的那个人。找到一个既对团队有帮助，又能做朋友的一个人，听起来很有诱惑力，但这并不就能决定你的公司是否会成功，最终也不会长期下去。

我不会得出一个结论说出于社会目的“多样性在本质上是好的”。这是一种愚蠢的看待方式。缺乏多样性很明显的对你的公司是不好的。你意外的录用了“像我这样子的”而不是录用“最适合这个工作的”。不可能这个世界上最出色的程序员都是一个样子的，所以缺乏多样性只意味着一些不好的事情。这意味着“这个团队不懂如何雇人”、“管理层和HR不够出色，无法发现、改正这种情况”，最糟糕的是，“这个团队的人都不是最出色的人”。

 

但如果我找不到这样子的人该怎么办？

 

这里我必须要挥挥手。npm在人才方面是十分幸运的：人们喜欢node和npm，我们只要一发布职位空缺就能得到许许多多符合资格的应聘者。我之前在的创业公司：awe.sn，就没有那么的受欢迎了，但我们也想方设法的想找到优秀的人才。这是需要花费很长的时间的，并且要尝试每一种方式：通过Hacker News的Who’s Hiring上发布招聘信息，通过我们的博客，以及曾经也通过TechCrunch的封面。

你要记得的一件很重要的事是录用一个不合格的人会比等待一个合适的人选花费更大的代价并且浪费更多的时间。也许你会说“在这个份上了，无论是谁都可以做啦”，但其实不是这样的。不合格的人不只是会无法胜任自己的工作，他们也会让每个人减缓自己的工作效率并且不乐意工作。如果你不确定这个人是否合适，那就不要去录用他。如果你录用了一个不太优秀的人，请尽可能给他足够的鼓励和指导。但如果你看不到他有任何进步，那就算你再怎么粗鲁无礼也要让他走人。

 

这是很困难的工作

 

给别人一个糟糕的面试更方便一些，这也就是为什么你给别人的技术面试不怎么样的原因。因为糟糕的面试更不需要你动脑筋，也不需要你的创造力、努力。这些面试技术很难去定义也很难去学习。但招聘工作就是这个样子的。这是个很困难的工作，这比你原本期望的还要花更多的时间。相关的规定很模糊不清，也没有什么相应的严峻考验。但是你努力之后的回报就是更大的公司，更出色的人才，更棒的产品，团队中每个人更开心的工作生活。而作为招聘经理，你唯一的工作就是使这些实现。

 

摘要

1. 许多面试技术中会测试与工作生活最不相关的技巧。

2.你想要某人现在就能胜任这份工作

3. 或者某人足够聪明并且有足够的动力尽快熟悉工作

4.你想要某人一直保持越做越好的态势

5.你的面试应该是个互相交谈的过程，而不是像审讯一样互相争论

6.你也想要一个愿意与他共事的人

7.区分“能成为同事”和“能成为朋友”十分重要

8.不要录用混球，无论他们多么优秀

9.如果你的团队不够多样化，你的团队会变的更糟糕

10.招聘过程会是一件花费很长的时间并且很困难的事情

 

 

This is why you neverend up hiring good developers

 

You are bad at givingtechnical interviews. Yes, you. You’re looking for the wrong skills, hiring thewrong people, and actively screwing yourself and your company. Without changinganything about your applicant pool, you can hire different people and yourcompany will do better and you will enjoy your job more.

I realize theseare bold claims. In the ten years since I became senior enough to be asked tointerview people, I have conducted a great number of technical interviews, beenpart of a lot of teams at companies big and small, and watched the effect thatdifferent types of hires have had on those companies. I’m not claiming to beperfect at hiring — at various points, I have done nearly all of the thingswrong that I’m about to tell you not to do. But here’s what I’ve learned sofar.

You are looking for the wrong things

1. Don’thire for what they already know

The primarymistake that people make when interviewing is over-valuing present skills andunder-valuing future growth. Don’t hire people for what they already know; thepool of people who do exactly the thing you need them to do is much, muchsmaller than the pool of people who are smart enough to be good at that job.

But even worse is the way we try to determinewhether people have these skills. People ask questions in interviews aboutobscure syntactical features of programming languages, or details of popularAPIs. The famous fizzbuzz test simplyasks “are you aware of the modulo operator?” If the answer is “no” then theyare probably a pretty weak candidate, but it provides exactly 1 bit of data.Yet people will spend twenty minutes on it in an interview, a huge waste oflimited time.

2. Don’thire for what they can remember in an interview room

I used to askpeople to write code in interviews. This is terrible. Writing code on awhiteboard is an experience so far removed from the real practice of writingcode as to be no predictor. Even writing code on a computer, as part of a pairfor instance, tests for the wrong ability — you are asking them to write codeunder time pressure, with somebody watching. Some of the best engineers I knowwould melt under those conditions. And if your belief is that writing codeunder intense time pressure is part of your job, then you should examinewhether that’s a problem your company has.

Whiteboard and coding interviews alsoroutinely ask people to re-implement some common solution or low-level datastructure. This is the opposite of good engineering. A good engineer will tryto maximize productivity by using libraries to solve all but the most novelproblems. It’s also a poor test: how do you know if somebody is solving theproblem or merely remembering somebody else’s solution? There is no value tomemorizing the details of algorithms you can google in 15 seconds.

3. Don’thire for a fancy degree

Some people are impressed by academiccredentials. Having gone to a good college, or having gone to college at all,are not in my experience good predictors of ability as an engineer. Having aPhD in a relevant field is interesting but also an unreliable predictor:engineers write code and ship software; academics prove theories and writeproofs of concept. Somebody smart might be able to do both but it’s by no meansa given, or even very strongly correlated.

4. Don’thire for their previous employers

People also over-value brand names onresumes. Don’t hire somebody because they worked at a hot company, or a famousone, especially not if that company is big. Variation across teams in bigcompanies is enormous. Just because a company was successful doesn’t mean yourcandidate had anything to do with that. If you are familiar enough with anothercompany’s hiring process that you can vouch for it as a good selector ofqualified people, you might use that to bump them to the front of an applicantqueue, but beyond that, go with what’s in front of you.

5. Don’thire friends and family

And finally, never hire your family and ifyou can avoid it, don’t hire your friends either. Existing relationships createbias and implicit power structures, webs of obligation and loyalty that are atodds with what is best for your company. You will either compromise yourfriendship or your company, and rather than being forced to pick one or the other,just avoid the conflict entirely.

What you should be looking for instead

Your first stage of interviewing should beattempting to answer two questions:

1.    Can they do this job? This is not the same as“can they do this job right now?” but you need to be confident they can learnhow to do the job.

2.   Are they going to getbetter at this job? The answerhas to be yes.

1.Relevant experience is a plus but not a requirement

Syntax and API questions are aimed at findingrelevant experience but they are bad ways of doing so. Instead, talk about thetechnology they’re going to be working with. Find out how much they know aboutit. You’re not looking to hire or pass on the basis of any individual fact. Ifthey are weak on the skills they need for the job, then find a topic they knowa lot about instead, and get them to talk about it, if necessary explaining itto you. You are looking for grasp of complex topics and the ability to clearlycommunicate about them, which are the two jobs of the working engineer.

2.Somebody who is constantly improving is a requirement

Much more important than what they know ishow they learn it, and how quickly. You are looking for somebody with a trackrecord of learning new skills and applying them successfully. Talk about theircareer path, and look for evidence of increasing responsibility (which isrelated to, but not the same as, seniority). Remember that anybody you hirewill expect raises every year: somebody who isn’t getting better all the timeis going to become worse and worse value unless their skills increase in value,too.

3. Smartand Gets Things Done™

Joel Spolsky’s classic essay The Guerilla Guide toInterviewing (and thebook that followed it, Smart and Gets Things Done) are someof the smartest things that have ever been written about technical hiring.Smartness is hard to judge, and some of the techniques I’m talking about hereshould help. But “gets things done” is equally important. Have they shippedreal software?

Joel and I don’t agree on everything, though.I don’t think live coding exercises are particularly valuable. Joel is (or was)also pretty big on understanding pointer math, which is an interesting “cangrasp a complex topic” question but likewise outside the experience of manyexcellent engineers, so while it can be a useful thing to try talking about, itshouldn’t be an acid test.

4.Somebody who can intelligently discuss technology

As I mentioned, the two jobs of an engineerare to understand complex concepts, and then communicate them clearly. Somebodywho can do just one or the other may have a brilliant career in some otherfield, but is going to be an inferior engineer. The best programmer in theworld can develop incredibly efficient algorithms in record time, but the jobof an engineer is to work with a team to achieve something larger, and if youare unwilling or unable to spend time communicating with your colleagues you’reonly doing half of your job.

5.Somebody who knows what they don’t know

When interviewing I always attempt to findsome area of expertise where I definitely know more than my subject. This isnot to prove I’m smarter — see below — but because it’s important to see howsomebody reacts when they find themselves out of their technical depth.

The weakest candidates will try to waffle ormake wild guesses. This is a terrible sign, firstly because it never works, andsecondly because they thought that it would. In Dunning Kruger terms theyare in the bottom quartile, unable to accurately judge their own lack ofknowledge. It also means they will try to do this in other situations.

Strong candidates say “I don’t know” as soonas they hit their limit, and may start asking questions. The very strongestcandidates say “but if I had to guess” and then attempt to extrapolate. Thoseare great because it shows intellectual honesty and a strong desire to figurethings out.

6. This isa conversation, not an interrogation

As I said before, it’s a good idea to find anarea where you know more than your interview subject. But this is not to proveto them that you’re smarter or better: it’s to explore the extents of theirexpertise, to get a sense of the breadth and depth of their knowledge. You willbump into the edges or touch bottom, and that’s the point. When you do so itdoesn’t mean they’ve failed.

It’s important that they’re aware of thiscontract, too. You want your interviewee to be relaxed and comfortable, becausethat is the state they’ll be in when they’re doing their job (if not, yourcompany is awful, please quit). Answers you get from candidates who arestressed or panicky are basically useless. This is true even ifthey’re good answers, because they’re not representative answers.Stress and panic are not sustainable states, so you risk hiring someone whoonly performs when pressured to do so.

There’s always an exception

If your candidate has no relevant priorexperience, your only option is a more traditional technical interview. This istrue of both very junior candidates, and also more experienced people switchingfrom other careers.

Somebody who has just completed a trainingcourse, no matter how intensive or well-regarded, does not know how to be anengineer. They may know how to code, but that’s only half the job. Somebodyfresh out of college may not even really know how to code beyond academicpuzzle-solutions. In my experience, if someone has been coding professionallyfor less than a year, there’s not really been enough time to know if they’regood at it.

Fresh-out-of-college and other junior typesare also not going to know anything about how to interact professionally. Notonly does this make interviewing them trickier, it’s also a terrifyingresponsibility: if you hire them, the culture and working practices of yourcompany will be what they think of as “normal” forever.

The other exception to my rules is if youwork at a company large enough that engineers can become deeply specialized.When that happens, you may in fact need the genius programmer who isn’t verygood at explaining what they’re doing. If you’re big enough, you can hire amanager whose full-time job is to communicate with that person and thentranslate back and forth between them and the rest of the company. This worksreally well but is expensive, so it’s not something startups can really affordto do. Past your first 50 engineers, you might consider it.

Ask yourself: do I want to work with thisperson?

When you’re sureyour candidate is good enough to do the job, you have another question toanswer: do I want to work with this person? There are no specific questions toask to get this answer; it’s more about how they answer the other questions.This makes it a personality test, and that makes it very, very dangerousterritory. Personality is subjective, and that means you are inviting bias intothe equation. Personal bias, implicit bias, unconscious bias.

The terrifyingpossibility of turning away a great candidate because you are biased towardsthem in some way you don’t even know about is why people think giving pure,right-or-wrong technical questions are better. They’re not, they’re justeasier. And they do nothing to protect against bias: when there are 50 syntaxquestions you ask, it is easy to give hints and passes to the candidates youimplicitly prefer and pretend that they were just better. I’ve caught myselfdoing this. There is no simple way around this: you have to be aware of yourbiases, constantly conscious of them, and correct for them, or you will screwyour company by hiring inferior people.

1. Lookfor somebody to work with

The most common way I see startups get the“do I want to work with them?” question is by confusing that question with “doI want to be friends with this person?”

Get that assumption out of your head. Thosetwo are not the same. You can have brilliant, productive professionalinteractions with someone with whom you have absolutely nothing in common withon a personal level, and that’s fine. Your company does not need to “feel likea family”. It’s sure as hell not your frat house. You are not picking adrinking buddy (and as an aside, if your company regards drinking as a big partof its culture you probably have deeper problems).

2. Nojerks

From day one at npm Inc weimplemented our No Assholes policy, and I was pleased to read recently thatPolyvore (who seem to do brilliantly at maintaining a diverse engineering team)have pretty much the same policy. Avoidthe “genius assholes”, avoid the bitter and cynical, the bullies, the snobs.Don’t work with somebody who is going to be mean, unpleasant, or demeaning totheir co-workers. There is no level of brilliance and productivity that cancompensate for poisoning the morale of your team, and once a team culture isbroken it is very hard to fix. Hiring these people, even to get you through acrunch, is not worth what it costs. And if you hire one by mistake, fire themfast, and without hesitation.

The easiest way to spot that you are hiring ajerk is the phrase “hire, but not for this team”. That means “this person hasskills, but I don’t want to work with them directly”. If you don’t, nobody elsewill, so don’t inflict crappy people on other teams.

But in general jerks are easy to spot. Ifsomebody has a personality flaw so strong and baked-in they can’t keep it incheck for a couple of hours while being interviewed, it is going to be a hugeproblem in the regular work environment. Arrogance, rudeness, inattention todetail — these things turn up quickly, and if you spot them, trust your instinctto avoid them.

3. Don’thire for “team fit”

I have never heard a definition of “team fit”that didn’t end up sounding like “let our bias run free“. Phraseslike “looks like they belong here” are terrifying. More insidious arecomplaints like “doesn’t like the same social activities we do”. Grow up. Youroffice is not your frat house, and socializing with your co-workers outside ofwork is not some crucial test. There is no requirement that you like someonesocially as long as you want to work with them.

And while I’m at it, as an introvert andlifelong non-drinker, may I make a personal plea that you stop incorporatingsocial events into your hiring process? Professional interactions and socialones are not the same. Some people suck at small talk, and are not comfortableat bars. Remember the part about making sure your subject is relaxed andcomfortable? It’s about them being comfortable, not you.

How do youreconcile the “don’t hire for team fit” rule with the “no jerks” policy and the“somebody you want to work with” requirement? The distinction is subtle, butimportant: somebody who is good for your team is not necessarily somebody youwant to be friends with. It’s tempting to look for both, but it’s the wrongmetric for the success of your company and is ultimately unsustainable.

4.Homogeneity is disastrous

I’m not going to make an argument that“diversity is intrinsically good” for some social purpose. That’s a stupid wayof looking at it. Lack of diversity is obviously, mathematically, bad for yourcompany. Instead of hiring for “best for the job” you have accidentally hiredfor “looks like me”. There is no chance that all the best programmers in theworld look the same, so a lack of diversity means only bad things. It means“this team sucks at hiring”, it means “management and HR are not strong orcompetent enough to spot and correct this”, and worst of all it means “thisteam is not the best people available”.

But what if I can’t find anybody like this?

Here I musthand-wave. npm is incredibly lucky on the talent front: people love node andnpm, and we get dozens of qualified candidates just by posting a vacancy. Myprevious startup, awe.sm, was not nearly so popular, but we managed to findgood people anyway. It’s a matter of taking a long time, and trying everychannel: we got great candidates via posts to the Who’s Hiring post on HackerNews, via our blog, and once from some coverage on TechCrunch.

The importantthing to remember is that hiring a bad person is more expensive and wastes moretime than waiting for a good person. It’s tempting to say “at this point,anybody would do” but that’s never, ever true. The wrong person will not merelyfail to do their job, they will make everybody slower at theirs, and unhappy toboot. Don’t hire if you’re not sure about somebody, and if you hire somebodywho’s no good, give them as much support and direction as you can afford to getthem to turn around, but if you don’t see any improvement be ruthless inletting them go.

This is all very hard

This is whyyou’ve been giving bad technical interviews all this time: bad interviews areeasier to give. They require less thought and creativity and effort on yourpart. These techniques are tricky to define and tough to follow. But that’swhat hiring is like. It’s really hard, and it always takes much longer than youhope it will. The rules are fuzzy, and there are no acid tests that can beapplied. But the payoff to trying harder is a stronger company, better people,a better product, and a happier working life for everyone on the team. Makingthose things happen is, as a hiring manager, your only job.

TL;DR

1.    Many interview techniquestest skills that are at best irrelevant to real working life;

2.   you want somebody whoknows enough to do the job right now;

3.   or somebody smart andmotivated enough that they can learn the job quickly;

4.   you want somebody whokeeps getting better at what they do;

5.   your interview should bea collaborative conversations, not a combative interrogation;

6.   you also want somebodywho you will enjoy working with;

7.    it’s important toseparate “enjoy working with” from “enjoy hanging out with;”

8.   don’t hire assholes, nomatter how good they are;

9.   if your team isn’tdiverse, your team is worse than it needed to be;

10.       accept that hiring takesa really long time and is really, really hard.