今年转做工程经理之后，坐在面试桌另一边的次数多了很多。到目前为止最大的体会是：让候选人随意聊简历，基本聊不出什么东西。简历能告诉你一个人做过什么，却几乎说不清他是怎么工作的。

要补上这块信息，我目前用过最好的工具就是 STAR 格式的行为面试：请候选人讲一段真实经历，然后引导他把前面说的四个环节讲清楚。这套东西一股 HR 培训味——确实也是 HR 培训教材，但它能逼出细节，而信号恰恰藏在细节里。

好答案长什么样

#

拿"讲讲你解决过的一个复杂 bug"这个问题来说，你要听的是：当时的情境（发生了什么、为什么重要）、候选人本人承担的任务、他实际采取的行动（是"我"，不是"我们"），以及结果——最好带数字。

一个够分量的答案大概是这样（技术债的例子）：

“我们的部署流水线要跑 45 分钟，测试还不稳定，开发者经常得重跑好几次构建。我统计了一个月的时间损耗，每人大约 15 个小时。我把数据摆给管理层，提议投入两个迭代做测试并行化、修掉最不稳定的用例。做完之后部署降到 12 分钟，部署频率翻了一倍。”

五句话，情境、任务、行动、结果全有了，个人贡献一目了然。把它和"流水线太慢，我们修了一下"放在一起对比，这个框架的价值就很清楚了。

我反复在用的问题

#

与其面面俱到，我更倾向于围绕团队当下需要的能力来组织问题：

最后一个是我的最爱。一个人怎么讲失败，比三个成功故事透露的信息都多，而且这个问题很难提前背稿。

面试的正戏在追问

#

候选人很少能一上来就按 STAR 的节奏把故事讲全，这没关系——追问才是面试的正戏。对方说"我们提升了性能"，就问提升了多少、怎么衡量的。全程都是"我们"，就问你本人具体做了什么。故事收尾收得过分漂亮，就问下次再遇到会改什么。

还有一条我花了不少时间才学会的经验：对每个候选人问同样的问题，用一张简单的评分表打分。感觉很机械，但这是唯一公平的比较方式，否则你最后只会偏向印象最新鲜的那个人。

当然，这些都替代不了技术评估——一个人到底能不能做出东西，还是得单独验证。但假设性问题容易蒙混过关，过去的行为却很难编造。面了将近一年下来，我对一段被追问透了的真实经历的信任，远高于一段背得滚瓜烂熟的"优缺点"回答。

四行看懂 STAR

#

• Situation（情境）：当时发生了什么，为什么重要。
• Task（任务）：候选人本人负责的是哪一块。
• Action（行动）：他自己具体做了什么。如果全程都是"我们"，就问他本人做了什么。
• Result（结果）：最后怎么样了，最好带数字。对方说"我们提升了性能"，就问提升了多少、怎么衡量的。

延伸阅读

#

本站相关文章：

• 咖啡聊天：招聘流程的前奏 — 在正式流程开始前先认识候选人
• 工程管理中的团队动态 — 招人时也要看他将如何融入团队
• 在创业公司实习的好处 — 评估职场新人时的一些背景参考
• 复盘：反馈循环的力量 — 同样的复盘习惯也适用于面试流程本身

外部资源：

• The STAR Method: The Secret to Acing Your Next Job Interview — The Muse 写给候选人的指南
• Google re:Work: Structured Interviewing — 结构化面试背后的研究
• First Round Review: 40 Favorite Interview Questions — 适合"偷"问题的一篇
• Joel Spolsky: The Guerrilla Guide to Interviewing — 至今不过时的经典