拥抱“瑕疵”：为什么在 Live Coding 中故意犯一个小错，反而能加分？

许多求职者误以为，一场成功的 Live Coding 面试必须是行云流水、零失误的完美演绎，仿佛任何停顿或修改都会成为被扣分的理由。然而，在资深面试官的视角中，这种未经思考便直接输出标准答案的“完美”，往往是极具误导性的信号，甚至可能被直接标记为缺乏实战经验的“背题家”。真正的技术面试核心从来不是考察谁能更像一台没有感情的打字机，而是评估候选人在面对不确定性时展现出的工程思维与解决问题的能力。本文所探讨的“拥抱瑕疵”，绝非建议候选人通过拙劣的演技去故意制造低级错误，而是一种更高阶的“战略性验证”策略：在手撕代码的过程中，与其追求虚假的流畅，不如真实地展示你如何通过 Dry Run 发现逻辑漏洞，以及如何处理那些被暂时搁置的边缘情况（Edge Cases）。这种“自我纠错”的过程（Self-Correction）不仅能打破面试官对“背诵答案”的怀疑，更能强有力地证明你具备生产环境所需的防御性思维与工程韧性（Resilience）。相比于一个一次性写对但无法解释细节的候选人，一个能够主动发现 Bug 并通过逻辑推导完成修复的工程师，才真正展现了资深开发者独有的判断力（Judgment）。理解这一评分标准背后的心理学机制，将帮助你从机械的“做题”模式切换到有机的“解决问题”模式，从而将面试中的潜在危机转化为展示实力的绝佳机会。

核心解析：在 Live Coding 中“故意犯错”真的是高分策略吗？

直接回答：绝对不是。 如果你理解的“故意犯错”是指刻意写出语法错误、逻辑漏洞，或者通过拙劣的“演技”假装思考，这不仅是极高风险的策略，而且极大概率会被面试官直接标记为基础不牢或沟通不诚实。

然而，题目中提到的“拥抱瑕疵”并非指制造低级错误，而是指“战略性地展示验证过程”。在 Live Coding 的高压环境下，面试官并不期望看到一段像从教科书中复制粘贴出来的完美代码，他们更希望看到的是韧性（Resilience）和验证能力（Verification Skills）。

“演技”与“展示工作”的区别

很多候选人误以为面试官想看到的是“解决困难的过程”，因此在面对熟题时故意拖延时间或假装卡壳。这种做法很容易被识破，且毫无价值。真正的高分策略在于区分“表演”与“工程严谨性”：

• 错误的策略（Acting）：明明知道最优解，却故意写一个 $O(n^2)$ 的解法，然后假装突然“灵光一现”优化到 $O(n)$。这种套路化的表演往往显得不自然，且浪费了深入讨论架构或 Edge Case 的宝贵时间。
• 正确的策略（Strategic Verification）： 快速写出核心逻辑，但战略性地将边界条件（Edge Cases）的处理留到测试阶段。例如，你可以先写出主流程，然后主动说：“我现在先不处理空输入的情况，稍后在 Test 环节统一补全。”

为什么“修正过程”比“一次通过”更有价值？

资深的工程管理者常说，Coding skill gets you through rounds, but judgment gets you hired。面试官寻找的不是只会默写代码的打字员，而是具备判断力的工程师。

当你写完代码后，主动通过 Dry Run（人工走查）发现了一个潜在的 Bug（例如索引越界或空指针），并当场通过逻辑推导修复了它，这个过程展示了两个关键能力：

1. 自我纠错能力： 你不需要编译器报错就能发现逻辑漏洞。
2. 防御性思维： 你在思考代码在生产环境中可能如何崩溃，而不仅仅是让它通过当前的测试用例。

相比于一个从头到尾一言不发、一次性写出完美代码但无法解释细节的候选人，一个在验证阶段通过“发现瑕疵”并修复它的候选人，往往更能证明其工程实战经验。

Key Takeaway

* Do Not: 不要为了显得“真实”而故意写错语法或逻辑，也不要表演“假装思考”。
* Do Not: 不要试图通过背诵完美答案来跳过思考过程。
* Do: 利用验证（Testing/Dry Run）阶段来捕捉那些自然的、或被你暂时搁置的遗漏点。让面试官看到你如何通过测试用例来保障代码质量，这才是“瑕疵”带来的加分项。

面试官心理揭秘：为什么“太完美”的回答反而可能有问题？

在面试官的视角里，一场“完美”的 Live Coding 往往并不像候选人想象的那样令人惊艳。当一位候选人看到题目后，不需要任何思考时间，也没有任何停顿，直接敲出一段毫无瑕疵的代码时，面试官的第一反应通常不是“这位候选人是个天才”，而是——“他背过这道题”。

这就是所谓的“面试官困境”（Interviewer's Dilemma）。技术面试的核心目的并非单纯验证代码能否运行，而是评估候选人的工程思维与解决陌生问题的能力。正如资深技术招聘者所言，写出正确的代码只是通过了门槛，而展现出的判断力才决定了你是否会被录用。如果候选人的表现过于流畅，仿佛在默写标准答案，面试官就失去了评估其思维过程（Thought Process）的机会，甚至会怀疑其无法处理现实工作中充满不确定性的复杂场景。

实际上，面试官更倾向于寻找那些能够展现“有机解决问题”过程的信号，而非机械式的“背诵”。相比于一个只会默写最优解的“做题家”，一个能够发现并修复 Bug、能够解释“为什么这么做”的候选人往往展现出了更高的资深程度（Seniority）。

为了更直观地理解面试官的评判标准，我们可以对比以下两种表现模式：

这种心理预期的差异，解释了为什么在展示实力的过程中，适度的“真实感”远比虚假的“完美感”更有价值。接下来，我们将深入探讨面试官是如何具体区分这两者的。

背题嫌疑 vs. 真实解决问题

在技术面试中，面试官最警惕的一类候选人并非“技术不够好”的人，而是“背题家”（Scripted Candidate）。当一道复杂的算法题被毫无停顿、行云流水般地写出来，甚至连标点符号都完美无缺时，面试官的第一反应往往不是惊叹，而是怀疑：你是在解决问题，还是在默写答案？

这种怀疑并非空穴来风。对于资深面试官而言，区分“记忆回放”与“实时思考”有着非常明确的信号判断标准。

警惕“背题”的典型信号

当候选人的表现过于机械化时，往往会暴露出缺乏深层理解的迹象。以下是面试官眼中的典型“背题”红灯：

• 零思考起手：题目刚读完，甚至还没完全理清边界条件，就开始疯狂敲击键盘。这种跳过澄清阶段直接编码的行为，通常意味着候选人只是在急于把脑海中存储的代码“倾倒”在屏幕上，缺乏对当前具体场景的规划。
• 变量命名与语境脱节：例如在处理一个具体的电商库存问题时，机械地使用 dp[i][j] 或 node_a 这类通用教科书式的命名，而不是 minstocklevel 或 current_sku。这显示出候选人并未真正进入业务逻辑的语境。
• 思维断层：能够写出复杂的动态规划转移方程，却无法解释为什么要选择这个状态定义；或者在被问及“如果数据量扩大10倍会怎样”时，无法将已知方案迁移到新场景。这种对标准答案的依赖，导致其在面对变体问题时显得极其脆弱。

真实解决问题的“凌乱感”

相比之下，真实的解决问题过程往往带有一种“有机的凌乱感”。这种不完美恰恰是思维过程透明化的证明。一个正在实时思考的高级工程师，其表现通常包含以下特征：

为什么“修正过程”比“一次做对”更具说服力？

在 Live Coding 中，一个被候选人自己发现并修正的逻辑错误，往往比完美的“一遍过”更能加分。

这是因为“发现并修正错误”展示了高阶的工程能力：

1. 验证思维（Verification Mindset）：证明你并未盲目相信自己的代码，而是在不断进行心理预演（Dry Run）。
2. 抗压能力（Resilience）：在面试的高压环境下，能够冷静地分析 Bug 来源并修复，比单纯的算法记忆更有价值。
3. 真实性（Authenticity）：当你停下来纠正一个 < 还是 <= 的边界问题时，你向面试官证明了你的大脑正在高速运转，处理当前的逻辑细节，而不是在调取缓存。

正如资深工程管理者所言，高级工程师不仅仅是写出正确的代码，更在于他们拥有判断力（Judgment）。这种判断力体现在对代码潜在风险的预判和即时修正中，而这些恰恰是“背题”无法模拟的真实工程素质。

评分标准中的“调试能力”权重

在顶级科技公司（如 Google、Meta 或 Amazon）的面试评分标准中，代码的“一次性完美通过”往往被高估了，而“验证与调试能力”的权重却常被候选人忽视。实际上，在标准的招聘量表（Rubrics）中，代码质量（Code Quality）与验证能力（Verification/Testing）通常是两个独立的评分维度。

理解这一评分机制，是明白为什么“自我修正”优于“死记硬背”的关键。

1. “完美代码”与“工程能力”的博弈

一个普遍的误区是认为面试官只看最终代码是否跑通。但在数据驱动的招聘决策中，面试官寻找的是可复用的工程信号。

• 情形 A： 候选人写出了完美的算法，逻辑无懈可击，但写完后直接告诉面试官“我写完了”，没有进行任何测试。
• 情形 B： 候选人写出的代码包含一个逻辑漏洞（例如未处理空数组），但在随后的“Dry Run（人工走查）”环节中，自己构造测试用例发现了该错误，并迅速修复。

在许多 FAANG 等级的评分表中，情形 B 的得分往往高于情形 A。
这是因为情形 A 虽然在“算法正确性”上得分较高，但在“验证能力”上可能得零分或低分，因为面试官无法判断代码的正确性是源于运气、背题还是实力。相反，情形 B 展示了完整的工程闭环：编码 -> 测试 -> 发现问题 -> 解决问题。正如 Tech Interview Handbook 中提到的，高级技术能力的信号不仅在于代码实现，更在于能否展示出良好的编码习惯和对边缘情况的掌控。

2. 谁发现了 Bug？——信号的正负之分

在 Live Coding 过程中，Bug 的出现本身并不是毁灭性的，关键在于谁发现了它。评分标准通常遵循以下层级：

• 正向信号（Positive Signal）： 候选人通过测试用例或逻辑推演，自己发现并修复了 Bug。这直接证明了候选人具备生产环境所需的调试能力（Debugging Skills）和代码卫生意识。
• 中性偏负信号（Neutral to Negative Signal）： 面试官提示“如果输入是 X 会怎样？”，候选人此时才意识到错误并修复。这表明候选人依赖外部审查来保证质量。
• 负向信号（Negative Signal）： 代码运行报错或测试失败后，候选人无法定位原因，或者需要面试官指出具体的代码行才能修复。

因此，在评分逻辑中，一个被自己“抓获”的瑕疵，实际上是展示主动性验证（Proactive Verification）的最佳机会。DEV Community 的相关指南也指出，除了解决问题本身，能够主动识别边缘情况（如 null 输入或空集）并确保方案鲁棒性，是区分“合格”与“优秀”的重要标准。

能够“加分”的瑕疵：如何设计高价值的“错误”

在 Live Coding 面试中，并非所有的错误都是平等的。拼写错误、语法报错或基本的 API 误用通常被视为“低级错误”，会引发面试官对你基础能力的担忧。然而，有一种特殊的“错误”如果运用得当，反而能体现出候选人的工程成熟度——这就是“策略性遗漏”（Strategic Omission）。

策略性遗漏的核心不在于“假装不懂”，而在于优先级管理。资深工程师在解决复杂问题时，往往采用 “Happy Path First”（主流程优先） 的策略：先集中精力实现核心算法逻辑，暂时“忽略”复杂的边缘情况（如空数组、整数溢出或非法输入）。

这种做法在代码完成的瞬间看似留下了一个“瑕疵”——代码在特定边界条件下会失败。但这并非因为疏忽，而是为了避免在早期陷入细节泥潭，从而展示出一种“先抓重点，再完善细节”的大局观。正如 Pragmatic Engineer 所指出的，从一个朴素甚至不完美的方案开始，往往比追求一步到位却卡在细节上要有效得多。这种“不完美”为后续展示你的验证能力和调试思路预留了绝佳的空间。

策略性遗漏：将边缘情况留给 Test Case 环节

在 Live Coding 中，许多候选人倾向于追求“一次性写出完美代码”，在动笔前就试图在脑海中处理完所有可能的异常情况。这种做法不仅容易导致思维卡顿，还可能让你错失展示“调试与验证能力”的黄金机会。与其在编码初期就默默处理掉所有细节，不如采用策略性遗漏（Strategic Omission）：先专注于核心逻辑（Happy Path），将边缘情况留给测试环节去“发现”和修复。

这种策略的核心在于将隐性的思维过程显性化。通过在验证阶段“捕捉”到自己遗漏的边界条件，你实际上是在向面试官演示一套完整的工程化工作流。

执行流程：从“遗漏”到“修复”的四部曲

1. 构建核心逻辑（Happy Path First）
   在编码初期，明确告知面试官：“为了保持逻辑清晰，我先实现主流程，稍后再补充边界检查。”这不仅能让你快速产出可运行的代码框架，避免陷入细节泥潭，也符合由简入繁的解题策略。此时，即使你意识到需要处理空数组或非法输入，也可以选择暂时忽略，或者仅写一行 TODO 注释。
2. 主动发起测试（Propose a Test Case）
   代码写完后，不要等待面试官发问，立即进入验证环节。选择一个典型的边缘案例（Edge Case），例如 input = null、array = [] 或整数溢出场景。
   > 话术示例： “现在的逻辑在正常输入下应该没问题，让我们跑一个测试用例，比如输入为空时会发生什么。”
3. 演示“发现问题”的过程（Realize the Failure）
   在 Dry Run（人肉跑代码）的过程中，当执行到相关代码行时，停顿并指出问题：“啊，这里如果输入是空数组，直接访问 index 0 会抛出异常。”
   这一步至关重要——它证明了你具备代码审查（Code Review）的能力，能够通过逻辑推演发现潜在 Bug，而不是依赖编译器报错。
4. 现场修复（Fix It Live）
   随即补上 Guard Clause（卫语句）或相应的处理逻辑。此时，这个补丁不再是“因为粗心漏写的补救”，而是“经过严格测试后增强鲁棒性”的成果。

为什么要这样做？

这种做法将原本可能被视为“疏忽”的错误，转化为了展示测试意识的道具。

• 如果一开始就默默写好： 面试官可能认为这是你背诵了题目，或者根本没注意到你考虑了边缘情况。
• 如果通过测试发现并补全： 面试官看到的是一个严谨的工程师，懂得如何通过测试用例来验证代码的正确性。正如技术面试指南中所强调的，能够主动识别并处理 Null 输入或空集，是代码达到“Production-Ready”标准的重要标志。

风险提示：把握“自然”的尺度

使用此策略时需注意分寸，避免表演痕迹过重：

• 不要遗漏核心算法逻辑： 遗漏应该是针对边界条件（Edge Cases）或防御性编程（Defensive Coding）的部分，而不是算法的主体。如果在核心循环条件上犯错，会被视为基础不牢。
• 不要犯低级语法错误： 拼写错误或漏掉分号属于“噪音”，不属于“高价值瑕疵”。
• 保持流畅： 整个过程应像呼吸一样自然，体现出这是你日常开发习惯的一部分，而非刻意设计的剧本。

“我也许错了”：展示假设验证的思维过程

在 Live Coding 面试的高压环境下，许多候选人认为“完美”意味着像机器一样从头到尾零停顿地输出代码。然而，资深面试官往往更看重一种微妙的品质：智识上的诚实（Intellectual Honesty）。与其试图掩盖不确定性，不如主动暴露它，通过“口头假设验证”将思维过程透明化。这种做法看似暴露了知识盲区，实则展示了你作为工程师的严谨与稳健。

把“不确定”转化为“协作信号”

当你对某个 API 的返回值或循环边界感到犹豫时，不要通过猜测来蒙混过关。赌对了可能只是运气，但赌错了会直接暴露基础不牢或鲁莽的性格。相反，你应该大方地承认这种不确定性，并立即提出验证方案。

这种“自信的示弱”通过语言将面试官拉入你的调试循环中，创造了一种协作解决问题的氛围。以下是几种将“瑕疵”转化为加分项的话术策略：

• API 行为确认：
  > “我不确定 Map.get() 在键不存在时是返回 null 还是抛出异常。通常我会查文档，但这里我先假设它返回 null 并做空指针检查，您觉得这样处理可以吗？”

这种说法表明你具备防御性编程的意识，同时也尊重面试官的引导。正如 VerveCopilot 的观察 所指出的，不经澄清直接跳入编码往往是缺乏规划的表现，而主动确认细节则是成熟工程师的标志。

• 逻辑边界自查：
  > “我感觉这个 while 循环的终止条件可能存在 Off-by-one（差一错误）的风险。在运行代码之前，我想先用一个简单的测试用例手动演练（Dry Run）一下。”

这不仅仅是在防错，更是在展示你的调试习惯。你不是在等着代码报错，而是在积极地进行静态分析。

对比：不懂装懂 vs. 审慎验证

为了理解为什么这种策略有效，我们可以对比两种候选人的表现：

为什么这能建立信任（Trust）

在工程实践中，没有人能记住所有 API 的细节。面试官寻找的不是一本行走的百科全书，而是一个在遇到未知时知道如何安全着陆的队友。当你坦诚地说“我也许错了，让我检查一下”时，你实际上是在向面试官传递一个强有力的信号：我不会让未经验证的假设流入生产环境。

这种沟通方式不仅能缓解你的紧张感，还能让面试官看到你思维的颗粒度。正如 Udara Writes 在关于面试技巧的分享 中提到的，在调试和思考过程中保持沟通，能够将单向的考核转变为双向的“清晰对话”，这才是通过高级技术面试的关键。

弄巧成拙的风险：绝对要避免的“低级错误”

虽然在面试中展示真实的思考过程（包括纠错）可以拉近距离，但刻意制造错误是一把极其危险的双刃剑。如果分寸把握不当，这种策略极易被面试官解读为基础能力缺失。面试官寻找的是能够胜任工作的同僚，而不是需要手把手教导语法的初学者。

在任何情况下，你都绝对不能将以下类型的错误作为“展示调试能力”的道具。这些被称为“硬伤”，一旦出现，往往直接扣分甚至导致面试失败。

1. 语法错误与基本 API 误用

有些候选人误以为偶尔漏写分号或括号能显得“写代码很自然”，但这通常适得其反。基础语法的频繁失误（如在强类型语言中混淆类型声明，或在 Java 中对 List 使用 .length 而非 .size()）并不是“可爱的瑕疵”，而是缺乏实战经验的直接信号。

根据 Tech Interview Handbook 的评分标准，能够产出“无语法错误且实现清晰的代码”是评估候选人基本技术胜任力的核心指标。面试官默认熟练的工程师应当具备肌肉记忆，能自动规避这些低级噪音。如果你需要在这些基础问题上花费时间“调试”，这不仅浪费了宝贵的面试时间，还暴露了你可能并不熟悉这门语言。

2. 逻辑死胡同与数据结构选型错误

永远不要为了展示“优化过程”而故意先写一个完全错误的数据结构（例如在明显需要哈希表查重的场景下，故意先写一个 $O(N^2)$ 的双重循环，假装不知道有更优解）。

这种做法有两个巨大风险：

• 时间耗尽：你可能没有足够的时间完成从错误解法到最优解法的重构。
• 能力质疑：面试官可能会认为你的直觉就是低效的。高效的工程师通常会先沟通多种方案的优劣，而不是直接跳进坑里。

Verve Copilot 的分析指出，糟糕的问题拆解能力和缺乏系统的调试方法是面试中的重大红旗。如果你的“错误”导致代码逻辑混乱，或者需要大规模重写才能修复，这显示的是规划能力的缺失，而非解决问题的能力。

3. 拙劣的“表演”

这是最致命的风险：面试官通常能看穿你在演戏。

资深工程师往往面试过数百名候选人，他们对真实的卡顿、真实的思考停顿和真实的灵光一现有着敏锐的直觉。当你面对一个显而易见的 bug 却假装“苦思冥想”，或者对一个简单的 API 表现出不自然的犹豫时，这种不协调感会立刻破坏信任。

正如 GitConnected 的内行指南 所强调，混乱的代码和流程会制造困惑。一旦面试官感觉到你在试图“操纵”面试流程而非真诚协作，你的诚信度（Trust）就会大打折扣。与其冒着被贴上“不诚实”标签的风险去设计情节，不如专注于代码的清晰度与可读性，这才是稳妥加分的正道。

比“故意犯错”更稳妥的替代方案：展示调试力的正道

试图通过“演戏”来展示调试能力不仅风险极高，而且容易被经验丰富的面试官识破。更稳妥且更能体现工程师素养的策略，是将重点从“修复错误”转移到“主动验证”（Aggressive Verification）上。

这种方法的核心在于：在代码提交运行（或面试官开始Review）之前，你先通过“Dry Run”（人肉编译）的方式，自行对代码进行严密的逻辑审查。这不仅能达到展示调试能力的目的，还能让你在面试官眼中显得更加稳重和专业。

核心技巧：化身为“人肉编译器”

正如 Google 前资深工程师 Anthony D Mays 所建议的，你应该“把你的大脑变成一个编译器”。这不仅仅是通读代码，而是要像 CPU 执行指令一样，逐行模拟代码的运行状态。

实施这一策略的具体步骤如下：

1. 选定测试用例：不要只盯着代码看。选择一个具有代表性的输入（例如一个非空的数组或一个特定的字符串），最好包含一个简单的边缘情况。
2. 建立“变量监视表”：在白板或共享文档的空白处，列出代码中的关键变量（如指针 i, j，累加器 sum，或临时节点 temp）。
3. 逐行步进（Step-through）：

• • 大声说出逻辑：“现在 i 是 0，nums[i] 是 5，满足 if 条件，所以我们要进入循环内部……”
  • 实时更新状态：每执行一行，就手动更新一下“监视表”中的变量值。这展示了你对代码控制流的绝对掌控。

两种结局，都是赢家

使用“主动验证”策略，无论结果如何，你都能获得加分：

• 结局 A：你真的发现了 Bug
  这是最理想的情况。你不需要“假装”犯错，而是通过严谨的验证流程真的捉住了一个潜在的 Off-by-one 错误或空指针异常。
• • 加分点：这展示了你具备自我纠错的能力，且这种能力是结构化的，而非依赖运气。正如 FreeCodeCamp 的建议，面试官非常欣赏那些能像调试器一样通过测试用例发现并修复自身问题的候选人。
• 结局 B：代码完美无缺
  如果你跑完了整个测试用例，代码逻辑完全正确。
• • 加分点：你向面试官证明了你的代码是“经得起推敲”的（Solid）。你没有盲目自信，而是用数据验证了假设。这种严谨性（Rigor）往往比单纯写出代码更具说服力。

为什么这比“故意犯错”更高级？

“故意犯错”是一种被动的表演，依赖于面试官的配合；而“主动验证”是一种主动的工程习惯。

资深技术主管 Nick Ciubotariu 指出，在没有 IDE 和编译器的面试环境中，能够手动“Walk through”代码并关注空值检查（Null Checks）和角落情况（Corner Cases），是区分初级与高级候选人的重要分水岭。

与其冒着被认为是“基础不牢”的风险去埋雷，不如堂堂正正地展示你如何通过结构化的验证流程来确保代码质量。这才是展示调试力的正道。

Dry Run 技巧：人肉编译器的演示艺术

在 Live Coding 面试中，与其冒险去“表演”一个故意犯下的错误，不如通过扎实的 Dry Run（人工演练） 来展示你对代码质量的极致掌控。Dry Run 并非简单的“读一遍代码”，而是一种将自己化身为“人肉编译器”，模拟计算机执行逻辑的严谨过程。

这种技巧不仅能帮你捕捉到 90% 的逻辑漏洞（如 Off-by-one error 或空指针异常），更是向面试官展示你具备“写完代码不急着运行，而是先做自我审查”的资深工程师素养。以下是一套可直接执行的 Dry Run 标准动作：

1. 准备变量追踪表 (The Trace Table)

不要只在脑子里空想。在代码编辑器的注释区域，或者白板的右侧，列出所有关键变量的名称。

示例： 如果你在写一个双指针算法，写下 left, right, current_sum, target。

2. 选定测试用例

选择一个简单的 Happy Path（正常用例）和一个典型的 Edge Case（边界用例，如空数组或单元素）。告诉面试官：“我现在用 [1, 3, 5] 这个输入来跑一遍逻辑。”

3. 逐行“执行”与更新

这是最关键的一步。像调试器（Debugger）一样，用光标逐行扫过代码，并实时更新追踪表中的值。

• 动作：当代码运行到 i++ 时，手动将注释里的 i: 0 改为 i: 1。
• 话术：大声说出逻辑判断。“现在 i 是 1，小于数组长度 3，进入循环。nums[1] 是 3，不等于目标值，继续……”

4. 验证循环结束条件

大多数 Bug 藏在循环的边界。当循环即将结束时，放慢语速，明确演示最后一次迭代是否执行，以及退出循环后的返回值是否符合预期。

为什么这比“故意犯错”更加分？

“故意犯错”是一种高风险的博弈，容易被误判为基础不牢；而 Dry Run 则是防御性编程的具象化。当你通过 Dry Run 自己发现了一个逻辑漏洞（比如少了一个 = 号），并自然地说出：“啊，这里如果走到最后一步会越界，我需要加一个检查。”——这不再是一个“错误”，而是一次高质量的自我修正演示。

这种过程向面试官传递了强烈的信号：你不需要依赖报错信息来写代码，你拥有在代码运行前就确保其正确性的能力。 这种确定性，是所有 Tech Lead 都在寻找的稀缺特质。