↓ 跳过正文
仁才德
  1. 文章/

开发者面试中的 STAR 方法

· loading · loading ·
仁才德
作者
仁才德
居住在韩国首尔的领导者和软件工程师
目录

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

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

好答案长什么样
#

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

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

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

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

我反复在用的问题
#

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

能力维度问题
问题解决“讲讲你在压力下调试生产环境问题的经历。”
协作“描述一个你必须和难缠的利益相关方共事的项目。”
技术领导力“讲讲你在没有直接权限的情况下影响技术决策的经历。”
学习能力“描述一次你必须快速上手陌生技术的经历。”
主人翁意识“讲讲你做的东西失败了的经历。你当时怎么办的？”

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

面试的正戏在追问
#

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

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

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

延伸阅读
#

本站相关文章：

外部资源：