tech-interview-handbook 面试官速查手册：算法面试全流程 Do/Don'ts 操作清单

本篇技术指南围绕 interviewer-cheatsheet.md 这一"面试官版"速查清单展开，完整继承其覆盖面试前准备、开场、出题、编码中、编码后、收尾与面试后共 7 个阶段的全部 Do/Don'ts 条目，并结合仓库中的候选人评分标准与各大公司面试形式等文档，解释每条操作背后的信号采集逻辑。读完本篇，你可以直接照着清单组织一场结构完整、信号可靠的技术（算法）面试，并写出有据可依的面试反馈。

需要说明的适用前提：原文明确指出，这份清单"主要是针对算法类面试（mainly for algorithmic interviews）"，其中部分条目只适用于电话面（phone screen）或白板面（whiteboard interview），但大部分两者通用。作者本人作为面试官，在每次面试前都会重新修订这份列表来自我提醒，直到最终全部内化——这也是本文建议读者采用的使用方式：不要当作"看过即会"的文档，而应作为每场面试前的检查单使用。

另外原文附有一条针对候选人的提示：如果你是候选人，这一页对你不是关键资料，但理解面试官在关注什么，对你同样有帮助。候选人侧的操作清单见候选人最佳实践清单。

清单总览：图例、结构与适用场景

原文用一套三符号图例标注每一条行为建议：

符号	含义
✅	Do（应该做）
❌	Don't（不应该做）
⚠️	Situational（视情况而定）

当前清单主体使用 ✅ 与 ❌ 两类标注，全部条目按面试流程的时间线组织为 7 个阶段：Before interview（面试前）→ Introduction（开场）→ Upon delivering the question（交付问题）→ During coding（编码中）→ After coding（编码后）→ Wrap up（收尾）→ Post interview（面试后）。

从仓库结构看，该页面在 sidebars.js 中被归入 "Beyond the interview" 栏目（与面试形式、职业成长等"面试之外"的主题并列），其 Docusaurus frontmatter 中 id: interviewer-cheatsheet，定位为面向面试官的补充性参考资料。这与正文的自我定位一致：它是一份"straight-to-the-point, distilled list"（直击要点、蒸馏后的清单），而非面试方法论的长篇论述。

阶段一：Before interview —— 面试前准备

这是清单中条目最多的阶段之一，覆盖环境、题目、工具三类准备：

	操作
✅	Make sure your surroundings are well-lit.（确保周围环境光线充足。）
✅	Find a quiet environment with good Internet connection.（找一间安静、网络良好的房间。）
✅	Ensure webcam and audio are working. Test that your VC app is working well.（确认摄像头与音频正常，并测试视频会议应用可用。）
✅	Prepare two to three questions and be familiar with the different approaches for solving the questions. Good questions have multiple solutions each with different tradeoffs.（准备 2～3 道题，并熟悉每道题的不同解法；好的题目应该有多解、且各解法之间存在不同的 tradeoff。）
✅	Choose questions from different topics to identify possible knowledge gaps.（从不同知识点选题，以便定位候选人可能的知识盲区。）
✅	Familiarize yourself with the coding environment (CoderPad/CodePen). Set up the coding shortcuts, turn on autocompletion, tab spacing, etc.（熟悉编码环境（CoderPad/CodePen），设置好编辑器快捷键、开启自动补全、调整 Tab 缩进等。）

几条值得展开的执行细节：

1. 准备 2～3 道题，且要熟悉各题的多种解法。这条的隐含标准是"Good questions have multiple solutions each with different tradeoffs"——面试官必须能预判候选人可能走出的每条路径（暴力解、哈希优化、分治、DP 等），否则无法判断候选人的解法处于哪个水平，也无法在编码中给出有效提示。对照 候选人最佳实践清单 中要求候选人"Explain a few approaches... Discuss the tradeoffs"的条目，面试官只有事先掌握多解法，才能对候选人的 tradeoff 讨论做出有依据的评估。
2. 跨知识点选题。"Choose questions from different topics" 的目的是在有限时间内探测更宽的能力面，避免两道题都来自同一个算法域而错过盲区信号。
3. 提前配置编码环境。原文点名 CoderPad/CodePen 两个协作编辑器，要求面试前设置快捷键、开启 autocompletion、调整 tab spacing。这一点在 各大公司面试形式 的文档中得到交叉印证：Airbnb 的算法轮在 CoderPad/CodePen 上进行，Dropbox 允许查 API，Lyft 的电话面通过 JSFiddle 进行——远程协作编辑器确实是主流载体，面试官若不熟悉其操作，开场浪费的时间会直接挤压有效评估时间。
4. 物理环境（光线、安静、网络） 是远程面试的基础设施项。作者作为面试官把这些列为 ✅，说明其面试形式以远程为主；对现场白板面试，这几项自然退化为会议室条件检查。

阶段二：Introduction —— 开场

	操作
✅	Check if candidate wants to use the restroom or take a break.（先询问候选人是否需要上厕所或休息。）
✅	Give an overview of the interview format (introduction, duration, programming languages available, 5 min at the end for Q&A).（概述面试流程：自我介绍、时长、可用编程语言、最后留 5 分钟 Q&A。）
✅	Do a self-introduction and get the candidate to introduce themselves.（先自我介绍，再请候选人自我介绍。）
✅	Explain to candidate that there will be multiple questions (where relevant), they do not have to finish all questions and you might interrupt them abruptly.（如有多题，提前说明：不要求做完所有题目，且你（面试官）可能会突然打断他们。）
❌	Allow the candidate to spend too long introducing themselves.（不要让候选人花太长时间自我介绍。）

这个阶段有两条看似矛盾、实则互补的规则，值得单独解释：

• "提前说明我会打断你"（✅ 第 4 条）与"白板面试中给候选人留空间"（见后文 During coding 阶段）是同一设计思想的两面：面试官对时间拥有主导权。多题面试（原文标注 "where relevant"，即视题量而定）本质上是信号采样问题——与其让候选人把第一道 Easy 做穿，不如按时推进到下一题换取更多维度的信号。提前告知"可能会被突然打断"，是为了管理候选人预期，避免打断被误解为不尊重。
• 对自我介绍设时间上限（❌ 第 5 条）。这与 候选人侧清单 中"自我介绍控制在 1～2 分钟以内、不要占用编码时间"的条目形成镜像：候选人侧被要求短，面试官侧被要求执行这个约束。

开场流程的固定模板（原文给出的要素顺序）：自我介绍 → 请候选人自我介绍 → 说明流程与时长 → 说明可用语言 → 预告最后 5 分钟 Q&A。其中"最后 5 分钟 Q&A"与后文 After coding 阶段"剩余 5 分钟时打断候选人"的条目是配套的——Q&A 时间需要在流程设计阶段就明确承诺并预留。

阶段三：Upon delivering the question —— 交付题目

	操作
✅	Ask if the candidate has seen the question before.（先问候选人是否见过这道题。）
✅	Give a small example for the question and the desired output.（给出一个小例子和期望输出。）
✅	Get the candidate to talk through the solution first before diving into coding.（让候选人先口头讲思路，再进入编码。）
✅	Provide hints where appropriate.（在合适的时机给提示。）
✅	If candidate is still stuck after providing hints, provide the solution and move to coding so that you can get coding signals.（若给过提示仍卡住，直接给出解法并转入编码，以便收集编码信号。）

这一阶段是整场面试"信号采集策略"最密集的地方，可以逐条拆解其评估动机：

1. 询问是否见过原题：这是数据质量控制。若候选人是背题，后续观察到的"流畅度"不能归因于真实能力；知道这一点后，面试官可以把评估权重向编码质量、边界处理与复杂度分析转移，甚至换题。
2. 给出小例子和期望输出：编码题通常故意写得模糊（underspecified），面试官给出的例子用于锚定输入输出格式，避免双方对题意理解不一致而浪费编码时间。
3. 先讲思路再编码（"talk through the solution first"）：这直接对应 评分标准 中 Problem Solving 维度的基础信号——"Approached the problem systematically and logically"。口头阶段暴露的理解力问题，成本远低于编码之后才暴露。
4. 提示（hints）的给定时机：提示是面试官主动施加的刺激，候选人在提示后的反应（能否沿提示推进、能否独立收尾）本身就是一个强信号，可映射到 Problem Solving 维度中"Did not require any major hints from the interviewer"这一基础信号。
5. 卡住时直接给解法、转入编码：这条是清单中最反直觉的一条——很多面试官会犹豫"直接给答案是否公平"。原文给出的理由很明确："so that you can get coding signals"。因为一场面试要同时评估多个维度（见后文信号与评估维度映射一节），若候选人在思路阶段卡死，继续耗在讨论上只会让 Technical Competency 维度缺失数据；给出解法后观察其"把已知思路翻译成可运行代码"的能力，正是 Technical Competency 维度的核心测量点（"Translates discussed solution into working code with minimal to no bugs"）。

阶段四：During coding —— 编码过程中

	操作
✅	If whiteboard interview, stand alongside candidate but also giving them space, instead of being distant, e.g. seated down.（白板面试时，站在候选人旁边但留出空间，而不是坐在远处。）
✅	Take note of all the positive and negative signals.（记录所有正面与负面信号。）
✅	If you have multiple questions, don't let the candidate spend too long on one question, especially if the first question is an Easy one.（多题时不要让候选人在一题上耗太久，尤其第一题是 Easy 时。）
❌	Check the time in an overly-obvious manner.（不要用过于明显的方式看时间。）

两条展开说明：

1. 白板站位。"stand alongside candidate but also giving them space" 描述的是一个行为分寸：站得太远（甚至坐下）会让协作退化成旁观，候选人卡住时你也不好介入；贴身压迫则会造成心理压力、干扰表现。原文给出的是相对动作而非绝对距离，实践中以"候选人需要时可以自然地指向板面、你能即时给出一句提示"为宜。这条仅适用于白板面，远程 CoderPad/CodePen 场景不适用（原文也声明部分条目只适用于其中一种形式）。
2. 记录信号，且要对照评分框架记录。原文在此条直接链接到 coding-interview-rubrics.md（原始相对链接 ./coding-interview-rubrics.md，按仓库根路径即 评分标准文档）。该文档定义了跨 FAANG/MANGA 公司大体一致的 4 个评估维度，面试官"take note"时应当有结构，而不是记流水账：
   • Communication：是否主动澄清、是否在编码中持续表达思路；
   • Problem Solving：是否系统性理解问题、能否做 tradeoff 分析、是否需要大量提示；
   • Technical Competency：实现是否快而准、有无语法错误、代码风格是否整洁；
   • Testing：是否测试常规与边界用例、能否自查并修正 bug。 按维度归类的信号记录，能直接支撑面试后快速产出结构化反馈（对应清单最后一条 "Write feedback as soon as possible"）。
3. 时间分配规则："第一题是 Easy 时尤其要注意"——Easy 题的边际信号递减很快，过度深挖不如推进到下一题。这条与 Before interview 阶段"准备 2～3 道题"形成呼应：题量设计、时间推进、信号记录是一整套组合动作。
4. ❌ 不要过于明显地看表。时间压力应通过"打断 + 预告打断"的方式管理（见 Introduction 阶段的 ✅ 条目），反复偷看手表会给候选人施加额外的焦虑干扰，污染你在 Technical Competency 上观察到的表现。

阶段五：After coding —— 编码结束后

这是清单中条目最多的阶段，直接决定你能否拿到完整的评估数据：

	操作
✅	Ask for candidate to provide test cases and run through the code with them.（请候选人自己给出测试用例，并陪他们一起过一遍代码。）
✅	Identify edge cases the candidate missed and ask the candidate to address them. Ask the candidate "What if X was the input? What would your code produce?" instead of pointing the issue out directly.（找出候选人遗漏的边界情况并让他处理；用"如果输入是 X，你的代码会输出什么？"来提问，而不是直接指出问题。）
✅	Take note of the duration the candidate spent on each question to include in the feedback.（记录每道题的耗时，写进反馈。）
✅	Ask for time complexity and space analysis.（要求候选人做时间与空间复杂度分析。）
✅	Preserve the code somewhere - take a picture or copy the code out.（把代码保存下来——拍照或把代码拷出来。）
✅	Stop the candidate when there is 5 minutes left. e.g. ("I'll stop you here and let's go to the next section")（剩余 5 分钟时停止当前环节，例如："我先停在这里，我们进入下一环节"。）

逐条解读：

1. 让候选人出测试用例：Testing 维度的测量方式是"让候选人自己驱动"，而不是面试官代劳。评分标准文档 对 Testing 维度的定义包括"提出常规用例并测试代码、发现并处理边界情况、识别并自行修正 bug、能系统化地验证正确性（如像调试器一样逐行推演状态）"——候选人自述用例并现场推演，正好覆盖这些信号。
2. 用假设式提问探测边界："'What if X was the input?' 而非直接指出问题"是一条重要的提示伦理——它把"发现并修正遗漏"的机会留给候选人，你观察到的是他真实的自查能力，而不是"被告知答案后照做"的能力。这与"Provide hints where appropriate"一脉相承，只是用在了编码后阶段。
3. 记录每题耗时：耗时是反馈中的硬数据。多题面试中，"第一题 Easy 用了 40 分钟"本身就是信号；把它记下来，面试后写反馈时不用凭印象。
4. 要求复杂度分析：对应 Problem Solving 维度的基础信号"Determined time and space complexity accurately"。很多候选人在写完后会忘记这一步，面试官主动询问既是评估点，也是公平性设计——把规则显式化。
5. 保留代码：拍照或拷出代码原文。这服务于两件事：反馈中可以引用具体代码片段作为证据；跨面试官讨论（debrief）时有据可查。
6. 5 分钟硬停：原文给出了可直接复用的话术（"I'll stop you here and let's go to the next section"）。这与 Introduction 阶段承诺的"最后 5 分钟 Q&A"闭环：Q&A 时间必须被硬停保护，否则会被编码环节自然吞掉。

阶段六与七：Wrap up 与 Post interview —— 收尾与面试后

Wrap up

	操作
✅	Allow candidate to ask questions and answer them to the best of your ability.（让候选人提问，并尽你所能作答。）
✅	Thank the candidate and wish them all the best.（感谢候选人并祝愿顺利。）

Q&A 环节兑现的是 Introduction 阶段的承诺（"5 min at the end for Q&A"）。从信号角度看，候选人问的问题本身也携带信息（候选人清单 把"提出好的、贴合公司的问题"列为面试收尾的必做项）；从体验角度看，认真作答是专业度的一部分。

Post interview

	操作
✅	Write feedback as soon as possible to not forget details.（尽快写反馈，以免细节遗忘。）

这条虽然只有一句，却是整条清单的落点——前面 6 个阶段的所有"take note"动作（信号记录、耗时记录、代码留存）都是为它服务的。结合 评分标准文档 描述的评分机制可以更具体地理解"尽快"的含义：

• 反馈通常落在 4 档评分区间：Strong hire / Hire / No hire / Strong no hire（原文表述为 Strong hire、Hire、No hire、Strong no hire，对应各维度如 "Strong hire: no trouble achieving all basic... signals" 的档位描述），部分公司在拿不准时还有中间档；
• 反馈会对全部面试官可见，有时公司甚至能看到候选人在该公司历史面试的反馈，以避免重复出题——这意味着你今天写的反馈质量，会直接影响后续轮次的题目选择与最终决定；
• 电话面通常只有一名面试官，其"pass"（相当于 Leaning hire 及以上）决定候选人能否进入全轮次面试。

因此"as soon as possible"不是礼貌性建议：信号记忆的衰减很快，而这份反馈将进入一个多方可见、影响后续流程的决策包。

面试官操作与评估维度的映射

把整份清单的动作与 评分标准 的 4 个评估维度对齐，可以得到一张"每个阶段的动作在采集什么信号"的总表。这张表是原文各条目的隐含逻辑显式化，用于帮助你在执行清单时理解取舍：

阶段 / 操作	主要采集的信号	对应评估维度
准备多解题、跨知识点选题	为观察多解法与 tradeoff 分析预设探测点	Problem Solving
先让候选人讲思路再编码	是否系统性理解问题、是否主动澄清	Problem Solving / Communication
合适时机给提示、卡住后直接给解法转编码	提示敏感度；把已知方案翻译成可运行代码的能力	Problem Solving / Technical Competency
记录所有正负信号（按维度归类）	4 个维度的原始证据	全部
控制单题耗时、第一题 Easy 不深挖	时间压力下的推进能力、编码节奏	Problem Solving / Technical Competency
让候选人自出测试用例并推演代码	常规与边界用例覆盖、系统化验证正确性	Testing
"What if X?" 假设式提问	自行发现并修正遗漏的能力	Testing / Problem Solving
要求复杂度分析	时间/空间复杂度判断是否准确	Problem Solving
记录每题耗时、留存代码	反馈硬数据与证据	全部（支撑反馈写作）
5 分钟硬停并进入 Q&A	兑现流程承诺，保护收尾环节	—（流程控制）

这张映射也解释了清单中"反直觉"条目的存在意义：比如"卡住时直接给解法"看似降低难度，实则是用 Problem Solving 上已经获得的有限数据，去换取 Technical Competency 维度的必要样本——4 维评估中任何一维缺失都会让最终评分失去依据。

与候选人侧清单的关系

这份面试官清单与 候选人最佳实践清单 是同一枚硬币的两面，几处条目可以互相对照，帮助面试官理解自己在执行什么：

面试官动作（本篇）	候选人侧对应规则
开场说明"可能会有多题、可能突然打断你"	候选人应预期并适应被打断，而非视为失礼
"先讲思路再进入编码"	"Do not jump into coding right away"（未获许可前不要直接写码）
编码后请候选人自出用例	"做完不要宣布完成，先扫描错误、补边界用例、复述复杂度"
剩余 5 分钟硬停	候选人应预留最后的 Q&A 环节并准备贴合公司的问题

同时，各大公司面试形式文档 解释了为什么清单要在"白板"与"CoderPad/CodePen"之间做区分：Meta 的现场面明确要求只使用白板（"No laptops involved"），而 Airbnb、WhatsApp 等公司普遍在 CoderPad 上进行算法轮——面试官在 Before interview 阶段选择准备哪一类环境，取决于所面公司的既定形式。

适用前提与使用建议

最后重申本文边界与使用建议：

• 适用范围：清单主要针对算法类技术面试，部分条目仅适用于电话面或白板面（如白板站位、看时间方式），大部分两者通用；行为面（behavioral）与系统设计面的流程管理不适用本清单。
• 使用方式：与作者一致——把本文 7 个阶段当作每场面试前的检查单逐条过一遍，前几次面试逐字执行，逐步内化为默认流程；
• 配套动作：记录信号时对照 4 维评分框架 归类；面试结束后立即写反馈，因为反馈对后续轮次可见且影响最终决定；
• 候选人视角：若你实际是候选人，本文的价值在于让你知道面试官在每个阶段的关注点与提示伦理，候选人侧的完整操作请见 coding-interview-cheatsheet。

以上所有内容均出自仓库内 面试官速查清单 原文，信号定义与评分档位来自 coding-interview-rubrics，编码环境与公司形式细节来自 interview-formats-top-companies，可沿这些文件在仓库中继续深入。