面试技巧

区分优秀程序员和差劲程序员

亲爱的 KV,

我的工作组刚刚获批招聘四名新程序员，现在我们所有人都必须面试人员，包括电话面试和现场面试。我讨厌面试别人。我从不知道该问什么。我还注意到，人们在写简历时往往对真相漫不经心。我们正在考虑为下一轮面试者进行编程测试，因为我们意识到之前的一些候选人显然连最基本的编程都做不到。一定有一些技巧可以在不影响我们招聘人员质量的前提下加快招聘速度。

厌倦了空谈不编码

亲爱的厌倦了空谈,

我首选的评判潜在求职者的方法是美国海军陆战队使用的方法：打击候选人，直到他或她没有任何个性和自尊，如果候选人仍然想为你工作，那就雇佣这个人，因为那时你就拥有了他或她的灵魂。不幸的是，每次我在办公室建议“新兵训练营式招聘”时，我们的法务部门都会勃然大怒，所以我还没有实施和测试这种方法。在无法在实战中判断人们的能力的情况下，你必须使用不太直接、更微妙的方法。

任何面试的真正目标都是让双方——面试官和被面试者——弄清楚这个人是否能胜任工作，并且是否适合团队的其他成员。有很多才华横溢的程序员，但我永远不会雇用他们，因为他们的性格缺陷对团队其他成员的有害影响将超过他们作为程序员的能力。要问的问题是：“我如何在 30 到 60 分钟内确定这个人是否能完成我们需要的工作，并且以一种我可以忍受他或她每天 10 小时、每周 5 天，甚至可能长达数年的方式？” 对于如此短暂的会议来说，这要求很高。

弄清楚某人是否具备你认为工作所需的知识可能是面试中最容易的部分。你此时真的不需要给候选人进行编程测试；你只需要问一些你最近在工作中回答过的问题。这假设这个人将从事与你一直在做的工作相同类型的工作，这通常是一个安全的假设（程序员很高兴很少被要求面试会计部门的人）。我倾向于首先从基本问题开始，你不应该觉得资深人士不屑于回答简单的问题。仅仅因为某人有很多经验并不能成为他或她不知道如何使用（例如）链表的借口。如果一个人有很多经验，那么他或她会很快用完你的琐碎问题，你可以继续处理更困难的问题。

一旦你确定这个人具备工作所需的基本知识，你就需要弄清楚，至少在较高的层面上，他或她是如何解决问题的。在这一点上，我发现白板是面试的最佳工具。我总是让编程职位的候选人以框图形式描述他们熟悉的系统。如果程序员或软件工程师无法将系统描述为框图，我不太可能雇用这个人。候选人可能很聪明，可能了解他或她工作的系统，但无法向另一个人解释的候选人在任何工作组中都将毫无用处。

但是，在候选人令我满意地描述了一个系统之后，我总是问以下问题：“如果你有更多时间，你会改变什么或添加什么功能？” 这种开放式问题非常重要。无法回答这个问题的人几乎就是一个机器人，只是执行别人的意志。我不喜欢与机器人一起工作；我喜欢与有思想的人一起工作，他们对他们正在构建的东西有自己的看法，并且始终在思考如何扩展他们正在工作的系统。优秀的程序员明白，他们的系统永远不会真正完成，总有一些他们可以做的事情，如果他们有更多时间的话。

虽然有些公司使用编程测试来评估候选人，但我更喜欢两种不同的方法来实现同样的目的。多年前，我曾在一家公司工作，该公司要求你提交一段可以编译和运行的代码。代码需要有良好的文档记录，并且足够简单，以便别人在一个小时内弄清楚。我更喜欢真实的代码示例，而不是要求某人在纸上编写冒泡排序。随着开源项目的广泛参与，这种测试变得不那么必要了，因为你通常只需搜索程序员的名字，就可以在某个地方看到程序员添加到开源项目中的一些代码。无论你如何做，都要确保获得代码样本，因为这比他或她在法律用纸上如何编码更能说明程序员的情况。如果你是偏执型的人，并且你不相信这个人不会发送朋友的代码，那么在面试期间询问有关代码的问题。如果这个人是在虚张声势，那么你很快就会知道；如果这个人确实提交了朋友的代码，但可以虚张声势地解释清楚，那么无论如何你都应该雇用这位候选人。

我喜欢用代码来考查程序员的另一种方法是提供一段在某些方面存在错误的代码，并要求他们找出错误。程序员的大部分工作时间都花在调试上，我非常重视这种能力，几乎和重视编写无错误代码的能力一样。即使程序员自己编写无错误代码（这种情况不太可能发生），他们也会处理别人的代码，因此他们必须具备快速分析非自己代码的能力。

有些面试官喜欢出脑筋急转弯，但我发现这些没什么用，除非它们与现实世界中的编码有关。脑筋急转弯在几个层面上都失败了。在一个层面上，一个人可以简单地记住大多数流行的脑筋急转弯。快速搜索显示，有 2000 多本关于如何轻松通过面试问题的书，其中一些书专门介绍软件。如果候选人发现你的公司是那种使用脑筋急转弯的公司，那么他们会在面试前临时抱佛脚，很可能会蒙混过关。

避免使用脑筋急转弯方法的另一个原因是，有些非常优秀的程序员不擅长脑筋急转弯，因此你会错过一些优秀的人，因为他们在你的测试中看起来不够聪明。让我们面对现实吧，大多数程序员不会整天看着编码问题并试图将它们与脑筋急转弯联系起来。他们会查看问题并尝试在代码中找出如何解决问题。你是在招聘程序员，而不是游戏节目参赛者。

我意识到你最初要求找到一种加快招聘和面试流程的方法。我已经提出了一个可以加快速度的建议：让被面试者在来面试之前给你发送代码。我建议你在电话筛选之后但在现场面试之前这样做，因为如果这个人发送给你的代码完全是垃圾，你可以放弃面试。

避免浪费人们时间的第二件事是在你的每个团队成员与此人交谈后，评估是否将该候选人发送给下一个团队成员。虽然在第一或第二位面试官与候选人交谈后就让人回家可能会令人尴尬，但这比让整个团队走过场面试某人（仅仅是为了礼貌）要轻松得多。就像在代码中一样，最好尽早失败。

KODE VICIOUS，凡人称之为 George V. Neville-Neil，为乐趣和利润从事网络和操作系统代码工作。他还教授与编程相关的各种科目。他的兴趣领域是代码探险、操作系统和重写你的糟糕代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位，并且是、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行家，目前居住在纽约市。

最初发表于 Queue 第 9 卷，第 6 期——
在数字图书馆中评论本文

更多相关文章

João Varajão, António Trigo - 评估 IT 项目成功：感知与现实
通过提供对 IT 项目成功的新见解，这项研究对实践、研究和教育具有重大意义。它通过报告项目成功（而不仅仅是项目管理成功）扩展了项目管理知识体系，并以几个客观标准为基础，例如项目后期阶段客户对可交付成果的使用、客户对项目相关支持/维护服务的雇用、客户对新项目的承包以及客户对潜在客户的供应商推荐。研究人员可以找到一套标准，他们在研究和报告 IT 项目的成功时可以使用这些标准，从而扩展当前对评估的看法并有助于得出更准确的结论。

Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler - DevEx：真正驱动生产力的因素
开发者体验侧重于开发者的实际体验以及他们在日常工作中遇到的摩擦点。除了提高生产力外，DevEx 还通过提高效率、产品质量和员工保留率来驱动业务绩效。本文提供了一个理解 DevEx 的实用框架，并提出了一个测量框架，该框架将来自开发者的反馈与他们与之交互的工程系统的数据相结合。这两个框架为领导者提供了清晰、可操作的见解，让他们了解需要衡量什么以及在哪里关注才能提高开发者生产力。

Jenna Butler, Catherine Yeh - 设身处地为他人着想
新冠疫情在许多方面改变了人们的工作方式，但许多结果本质上是自相矛盾的。对一个人有效的方法可能对另一个人无效（甚至对同一个人第二天也无效），我们尚未弄清楚如何准确预测对每个人都有效的方法。正如你在此处描述的综合角色中所见，有些人与孤立和孤独作斗争，很难与他们的团队进行社交联系，或者发现与远程团队进行混合工作的时间压力令人难以承受。其他人则喜欢这种新的工作方式，享受更多与家人共处的时间、白天锻炼的更大灵活性、更好的工作/生活平衡以及为世界做出更大贡献的愿望。

Bridget Kromhout - 容器无法修复你破碎的企业文化（以及其他残酷的真相）
我们常常只关注技术反模式，而忽略了我们社会结构内部的类似问题。剧透警告：许多看似技术难题的解决方案可以通过检查我们与他人的互动来找到。让我们来谈谈与那些被称为人类的讨厌生物一起工作时你想要了解的五件事。