Tech Interview Handbook：编码面试全流程行为指南——面试前、中、后的最佳实践清单

本文基于 tech-interview-handbook 仓库中的 coding-interview-cheatsheet.md 整理扩写。它给出了一份覆盖编码面试「之前、之中、之后」三个阶段的完整行为清单（含常见错误），并解释每一条建议如何对应大厂面试评分维度中的 "hire" 信号。读完后，你可以直接把它当作面试前夜的检查清单，以及刷题练习时刻意训练行为模式的参考框架。

为什么行为同样重要：这份清单背后的评分逻辑

仓库中的 coding-interview-rubrics.md 指出，各大厂编码面试的评估维度大致可归纳为四个：

1. Communication（沟通）：是否做了澄清、是否表达了思路和权衡、编码过程中是否持续表达；
2. Problem Solving（问题解决）：是否系统性地理解问题、提出可行方案、做权衡分析并优化方案；
3. Technical Competency（技术能力）：实现的速度与正确性、语法错误、代码整洁度；
4. Testing（测试）：是否覆盖了常规与边界用例、是否发现并自行修正了 bug。

评分档位通常为 Strong hire / Hire / No hire / Strong no hire。这份 cheatsheet 的核心价值在于：它把「如何展示 hire 信号」拆解成了可执行的动作清单。文档也明确建议：在开始刷 LeetCode 之前就应该先熟悉这份指南，让正确的面试行为在练习早期就被内化，而不是临场临时学习。

面试前（Before）的准备清单

通用准备

• 穿着舒适即可。通常不需要正装，休闲装（T 恤、牛仔裤）在绝大多数场合都可接受。
• 提前准备好自我介绍与面试结尾要问面试官的问题，这两部分在仓库中分别有专门文档支撑：
  • self-introduction.md：将自我介绍设计成 30 秒到一分钟的「电梯陈述」，包含基础背景、最有亮点的项目（可带数据）、以及你为何适合这个职位，并反复练习到自然；
  • final-questions.md：准备了分场景的结尾问题清单，例如技术向的「团队目前面临的最大工程挑战是什么」、角色向的「这个岗位最需要我解决的最重要问题是什么」、文化向的「在这里工作最让你沮丧的一点是什么」。这些问题正是面试收尾阶段展示兴趣与思考深度的抓手。

针对虚拟 onsite（远程现场）面试

• 准备纸笔。需要随手记录和可视化时非常有用，画树/图结构图时尤其关键（这也呼应了 coding-interview-techniques.md 中「先画出问题来可视化」的解题技巧）。
• 使用耳机/耳麦，并确保环境安静。避免用扬声器，回声大会显著增加沟通成本，来回重复问题会浪费宝贵的面试时间。
• 检查网络连接是否正常。
• 检查摄像头与音频是否正常工作。
• 熟悉并设置好编码环境（CoderPad / CodePen）的快捷键：配置编辑器快捷键、开启自动补全、调整 tab 缩进等。面试官会对你熟练使用快捷键这件事留下好印象。
• 如果可以，关闭摄像头。多数远程面试不要求开视频，一直开着只会分散注意力并占用网络带宽。

针对电话面试（phone screen）

• 使用耳机，把手机放在桌上。避免一只手举着手机、只剩一只手可以打字。
• 主动请求改用 Zoom / Google Meet / Hangouts / Skype 而不是纯电话。这样方便发送链接或文本，沟通效率更高。

针对 onsite 白板面试

• 学习白板空间管理。行与行之间留出空隙，以便之后需要在已有代码中间插入新行。

面试中（During）的六个阶段

面试中的行为规范是整个文档的主体，按时间顺序分为六个阶段。

1. 开场：做一个好的自我介绍

• 用不到 1~2 分钟、几句话完成自我介绍（方法参考 self-introduction.md）。
• 表现出热情：带着微笑说话，声音自然会更投入。
• ❌ 不要花太多时间在自我介绍上——留给写代码的时间会相应减少。

2. 拿到题目后，先做澄清（不要直接写代码）

编码题往往故意写得模糊、规格不完整，以便考察候选人的细致程度。至少问 2~3 个澄清问题：

• ✅ 复述并确认题意（paraphrase the question back）。
• ✅ 澄清隐含假设（常见假设可参考 algorithms/study-cheatsheet.md）。典型例子：
  • 树状图的结构可能是一个允许环的图，朴素的递归解法在这种情况下不成立——先确认它是树还是图；
  • 是否允许以任何方式修改原始数组/图/数据结构？
  • 输入是如何存储的？
  • 给定的单词字典是字符串列表还是 Trie？
  • 输入数组是否已排序（这决定了你该用二分查找还是线性查找）？
• ✅ 澄清输入值的范围：多大？上下界是什么？
• ✅ 澄清输入值的格式：可为负？浮点？可为空？为 null？有重复？极大值？
• ✅ 用一个简化例子验证你理解了题目。例如做回文判断器之前，先给出 "KAYAK" => true、"MOUSE" => false 这样的测试用例，再和面试官确认是否符合预期。
• ❌ 不要在面试官给出「绿灯」之前就开始写代码。

3. 和面试官一起推演并优化解题方案

拿到题目后最差的做法就是直接开写——面试官期望有一段双向讨论的时间来确定方案，包括时间与空间复杂度分析。这段讨论可能从几分钟到 5~10 分钟不等，取决于题目难度。这也是面试官给你提示、引导你走向可接受解法的机会窗口。

• ✅ 如果在方案或优化上卡住了，使用 coding-interview-techniques.md 中的结构化方法（画图、手工推演、补充例子、拆分子问题、套用常见数据结构）来寻找思路。

• ✅ 在高层次上给出几个可选方案，讨论各自的 tradeoff——就像和同事协作解决问题一样，不必陷入实现细节。经典例子是 Two Sum：

  1. 双重 for 循环：时间 O(n²)，空间 O(1)；
  2. 单遍扫描 + 哈希表存储「值 -> 索引」，后续值查询哈希表判断是否存在可凑成 target 的数：时间 O(n)，空间 O(n)。

  把两种方案都讲出来，说明权衡，最后通常收敛到时间复杂度更低的那个。

• ✅ 明确陈述并解释所提方案的时间与空间复杂度（Big O）。例如「时间 O(n²)，因为有嵌套循环；空间 O(n)，因为额外创建了一个数组」。

• ✅ 与面试官敲定最优方案并继续优化：识别重复/重叠计算，用缓存消除它们（同样见 coding-interview-techniques.md 的优化章节，其中还给出了 BTTC「最佳理论时间复杂度」的判断方法、用前缀数组消除重叠计算、换数据结构降复杂度等具体手段）。

• ❌ 不要在未获「绿灯」前直接写代码。

• ❌ 不要忽略题目给出的任何信息。

• ❌ 不要在方案或分析上显得不自信。

4. 边写代码边讲解

• ✅ 只在讲清方案、获得面试官「绿灯」之后才开始写代码。
• ✅ 编码过程中持续说明你在实现什么；在相关处比较不同的编码写法，借此展示对所选语言的掌握。
• ✅ 速度要适中：慢到能解释清楚，但快到来得及在时间用尽前完成全部内容。
• ✅ 尽可能写真正可编译、能运行的代码，而不是伪代码。
• ✅ 代码要干净、直白、整洁，语法错误和 bug 越少越好；始终选清晰直白的实现而非复杂晦涩的实现。
• ✅ 用能自解释的变量名。需要向面试官解释代码时，好名字就是你的解释。例如在数字数组中找 3 的倍数时，结果数组命名为 multiplesOfThree 而不是 array / numbers。
• ✅ 对无需自己实现的基础函数，主动征得同意后直接使用，例如 reduce、filter、min、max。
• ✅ 模块化地写：先写高层函数，再拆成小工具函数。比如「造一辆车」可以先写 gatherMaterials()、assemble()，再把 assemble() 拆成 makeEngine()、polishWheels()、constructCarFrame()；甚至可以向面试官确认某些琐碎的辅助函数是否可以不实现。
• ✅ 如果代码里做了简化（cutting corners），大声说出来，并说明在非面试环境（没有时间压力）下你会怎么做。例如：「非面试环境下我会用正则来解析这个字符串，而不是用 split()，因为它可能覆盖不了某些边界情况。」
• ✅ 【白板场景】练习白板空间管理（同面试前准备一节）。
• ❌ 面试官说话时不要插嘴——他开口往往是在给你提示或引导方向。
• ❌ 不要在写注释上花太多时间。
• ❌ 不要重复自己已经说过的话。
• ❌ 不要用糟糕的变量名：不要用极长的命名，也不要用单字符命名（i、n 这类惯例除外）。
• ❌ 不要粘贴代码后不检查——粘贴后往往有变量需要重命名。

5. 写完代码后：自查并补充测试用例

写完代码后不要宣布完成。面试官期望你开始扫描错误、补测试用例来改进代码。

• ✅ 通读代码找错误——尤其是差一错误（off-by-one）。用「第一次看到别人代码」的新视角去读，并口述你排查的过程。
• ✅ 和面试官一起头脑风暴边界情况，并补充测试用例（常见 corner case 可参考 algorithms/study-cheatsheet.md）。题目给定的测试用例通常被刻意设计得很简单；要主动想到大输入、空集合、单元素集合、负数等。
• ✅ 用这些测试用例**逐步执行（step through）**你的代码。
• ✅ 寻找可重构的点。
• ✅ 再次复述代码的时间与空间复杂度——这能帮你发现可能偏离原有复杂度的代码问题（例如循环里多做了一次 len() 调用、缺少提前返回等，参见 coding-interview-techniques.md 中「避免冗余工作」各小节）。
• ✅ 说明当前方案的权衡，以及如果还有时间可以如何改进。
• ❌ 不要一写完就宣布完成——先做上面这些事。
• ❌ 不要和面试官争辩。即使他错了的概率也不低……但通常不低的是他对——毕竟面试官对这道题非常熟悉。

6. 面试收尾：留下好印象

• ✅ 问出针对该公司、有质量的结尾问题（问题清单见 final-questions.md）。
• ✅ 感谢面试官。
• ❌ 不要一个问题都不问就结束——按 final-questions.md 的说法，没有问题的候选人往往显得对这个职位兴趣不足。

面试后（After）的动作

• 把面试的题目和你的解法记录下来。这既可以作为以后的参考，也能在遇到重复提问时让你展示成长。
• 发送跟进邮件或 LinkedIn 邀请，感谢面试官的时间和机会。文档作者以面试官的身份确认：这类跟进确实能给面试官留下持久印象。

在仓库中继续阅读

如果你要把这份行为清单落地，可以按仓库 sidebars.js 中「Coding interview preparation」分栏的顺序配合阅读：coding-interview-prep.md（准备方法论）→ coding-interview-study-plan.md（学习计划）→ 本文对应的 coding-interview-cheatsheet.md（行为清单）→ coding-interview-techniques.md（找方案与复杂度优化技巧）→ coding-interview-rubrics.md（评分标准，可用其中的示例 rubric 做模拟面试）。刷题侧的题目模式与 corner case 则集中在 algorithms/study-cheatsheet.md 及其各专题页面中。