技术面试为什么该加入 Debugging 环节：基于程序员认知模型解析 tech-interview-handbook 中的调试面试观

技术面试长期以算法题为主，但这并不能完整刻画一名工程师的真实工作。本文基于 tech-interview-handbook 仓库中 《Why You Should Include Debugging In The Interview Process》 一文展开：从"程序员大脑"的五阶段认知模型出发，说明为什么标准编码面试漏掉了搜索、理解等关键能力，以及如何在面试流程中设计一场能覆盖全部编程活动的 Debugging 面试。读完后，你既能向团队论证增加调试轮的价值，也能拿到一套可直接用于面试评审的调试行为检查清单。

问题起点：标准技术面试过度偏向编码

作者 He Zhenghao（时任 Instacart 高级工程师，前 Amazon）在过去两年中接受了 10 多家技术公司的面试，对象从 Coinbase、Stripe、Instacart 等热门初创公司到 Amazon、Meta 等 FAANG 公司，覆盖不同级别的软件工程师岗位。他观察到这些公司的技术面试流程有一个共同点：

• 每家公司至少包含两轮编码面试，题型要么是算法型（LeetCode 风格）问题，要么是构建实际应用/功能的实操题；
• 无论哪种题型，候选人都从一块"白板"（empty slate）起步：算法题意味着编辑器里是一个空文件；实操题最多提供一些样板代码或工具函数，但功能本身仍要从零构建。

作者承认这些面试确实考察出了他的编码能力，但问题在于：行业标准面试流程把权重过度压在了"编码"这一单项上。作为工程师，除去开会和写设计文档，他至少一半的编程工作不是"写代码"，而是在代码库中搜索、阅读既有代码，以及阅读与代码相邻的产物——错误信息、测试、日志。而且很多时候，编码并不是最难的部分。

这一观察在仓库的其他内容中也能得到呼应：engineering-levels.md 在描述初级工程师职责时，将 "Writing code, debugging, testing" 并列列为日常责任，说明调试从来都是岗位工作的一等公民，而非编码的边角活动。

编程到底是什么：五阶段认知模型

编程是一项复杂任务，要研究它就需要拆解。作者参考了 Felienne Hermans 的著作 The Programmer's Brain（一本研究编程认知过程的书籍），该书将编程拆分为五个更具体的活动：

活动	含义	当前编码面试是否覆盖
Searching（搜索）	在代码库中定位特定信息，例如找到需要修复的那个 bug 的确切位置	否
Comprehension（理解）	阅读代码以理解其功能与设计意图，还包括运行代码并观察结果	否
Transcribing（转写）	把想法或解法转化为可执行代码——这也就是我们通常说的"编码"，是当前标准编码面试唯一考察的活动	是
Incrementation（增量迭代）	在既有代码库上迭代，例如新增一个功能；是搜索、理解与转写的混合活动	部分（实操题）
Exploration（探索）	用代码做草图和原型，试错并把代码当作思考工具；同样是前几种活动的混合	否

由此可以清楚看到当前面试流程的缺口：Searching 和 Comprehension 被完全排除在外，而这两项恰恰是软件工程师工作中占很大比重的能力，候选人在标准面试中没有任何途径去证明它们。这正是补入一轮 Debugging 面试的动因。

Debugging 为什么是"全能型"面试环节

Debugging 的特殊之处在于：一次调试过程会同时调动全部五种活动——它是一个"搜索 → 理解 → 探索 → 写代码"的序列。而观察一个人如何调试，信息量极大。原文列出了面试中应观察的信号清单，这也是可以直接落地的评审要点：

1. 是否有计划地调试：是迭代式地对代码做二分排查，还是随机地乱改代码？
2. 如何在不熟悉的代码库中导航，并形成关于 bug 的多种假设（hypotheses）？
3. 是否尝试编写一个能可靠复现问题的测试？
4. 能否找到行为开始分叉（diverge）的位置，并一路追溯到根因（root cause）？
5. 是否熟悉所用的 IDE/编辑器，知道如何使用断点（breakpoints）、监视变量（watches）等工具逐步执行（step through）代码？
6. **是否会读错误信息、利用调用栈（stack traces）**定位问题？
7. 最终能否实现修复？
8. 以及更细粒度的信号——清单可以不断延伸。

除覆盖面完整之外，debugging 还是工程师日常高频进行的工作，与真实岗位高度相关——这是纯算法题无法提供的"岗位效度"（job relevance）。

这一点与仓库中 coding-interview-rubrics.md 的评分体系互为印证：其第 4 项 Testing 维度中明确把"能够以系统化方式验证代码正确性（例如像调试器一样逐行执行、在每一步更新程序状态）"列为考察信号，"Strong no hire" 档的定义则是"代码连典型用例都没测，发现明显 bug 都没指出就宣布完成"。换言之，"像调试器一样工作"在现有面试方法论里已经被视为高价值行为信号，而 Debugging 面试不过是把这一信号从"编码题的附属观察项"提升为"独立的一轮"。

实践案例：Stripe 的 "Bug Squash" 面试

在作者面试过的所有公司中，只有 Stripe 做过调试面试。Stripe 把它称为 Bug Squash：候选人深入一个大型的、代码质量很好的库（library）代码库，去修复真实世界的开源 bug。作者的直接反馈是：这一轮面试让他玩得非常尽兴，而这正是那些"无聊的 LeetCode 题"给不了他的体验。

对招聘方而言，这种面试确实比"直接甩一道 LeetCode 题"要费工——需要维护代码库、挑选合适的 bug、设计题面与评分标准。但作者在原文明确指出：流程中加入这一轮，能让你获得更多信号来挑选真正有能力的、有经验的工程师，并希望更多公司在招聘中拥抱这一形式。

结合本文的检查清单，一个可操作的 Bug Squash 面试设计大致是：

1. 选题：从团队真实代码库或成熟开源库中挑一个"症状明确但根因不浅"的 bug——症状要能复现，根因要跨越若干模块，以考察搜索与理解能力；
2. 环境：提供完整 IDE 而非白板，允许使用断点、监视、日志等工具，考察候选人的工具熟练度；
3. 过程记录：面试官按上文 8 项清单观察候选人的假设形成、二分定位、复现测试与根因追踪行为；
4. 验收：以"修复生效 + 回归测试通过"为完成标准，而非"讲出思路"。

候选人侧：如何为 Debugging 面试做准备

对候选人来说，Debugging 面试既是最贴近日常工作的环节，也是差异化展示的机会。原文给出的进阶学习材料（此处仅列书名，外部链接见原文档）值得跟进：

• Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems —— Dave Agans；
• Debugging Software —— Mark Erikson；
• How I got better at debugging —— Julia Evans。

配合仓库内的其他内容做系统准备效果更好：coding-interview-techniques.md 强调多构造示例用例并"把多个例子留作最终验证解法的测试用例"，这与调试清单第 3 条"写一个可靠复现问题的测试"是同一套心法；而 coding-interview-rubrics.md 的 Testing 维度则展示了面试官如何给"系统化验证"打分，候选人可以反向对齐这些评分信号。

小结

• 标准编码面试只考察了编程五活动（Searching、Comprehension、Transcribing、Incrementation、Exploration）中的 Transcribing 一项，系统性漏掉了搜索与理解；
• Debugging 是少数能同时覆盖全部五种活动的任务，观察候选人调试的过程能暴露其是否有计划的二分排查、假设能力、复现测试意识、根因追踪和工具熟练度；
• Stripe 的 Bug Squash 面试是这一理念的落地范本：用大型高质量库代码库中的真实 bug 替代算法题；
• 对招聘方，这是一次"投入更高但信号更足"的流程升级；对候选人，调试能力是可以直接准备、并在日常工作中高频兑现的面试硬实力。

完整的论证原文见 博客原文，配套的面试评分标准与编码技巧文档分别位于 coding-interview-rubrics.md 与 coding-interview-techniques.md。