Coding interview preparation

Coding interview cheatsheet：面试前/中/后最佳实践

根据 coding interview 评估标准，给出面试前/中/后应该做什么的 tips，帮助你展示 hire signals

随着 coding interview 越来越成熟，面试官对候选人的面试行为有更明确的预期。某些做法还能帮助你展示 “hire” signals，让面试官看到你沟通能力和处理障碍的能力。

我们基于 top candidates 的做法，以及 coding interview 的评估标准总结了一个详尽 checklist，包含应该怎么做、以及常见错误。

建议你在开始刷题前就阅读并熟悉这份 guide。配合 LeetCode 练习，可以更早内化这些关键行为。

面试前要做什么

✅ 准备纸笔。

方便画图/可视化，尤其是 tree / graph 题。
✅ 用耳机/耳麦，确保环境安静。

不要开外放，回声会影响沟通，重复解释会浪费时间。
✅ 检查网络连接。
✅ 检查摄像头和音频。
✅ 熟悉并设置 coding environment 的快捷键（CoderPad / CodePen）。

设置编辑器快捷键、自动补全、tab spacing 等。会用快捷键能加分。
✅ 如果可以，关掉摄像头。

远程面试很多不需要视频，开着反而分心并占带宽。

不要直接开始写 code。 coding 题往往故意描述得不够精确，面试官就是要看你是否细心。至少问 2-3 个澄清问题。

✅ 复述问题并确认你理解正确。

确认面试官问的是什么。
✅ 澄清假设（参考 algorithms cheatsheets 的常见假设）
- 一个 tree-like 图可能是允许 cycle 的 graph，直接递归会出错。先确认是 tree 还是 graph。
- 是否允许修改原 array / graph / data structure？
- 输入数据是如何存储的？
- 给的是 word list 还是 Trie？
- 数组是否有序？（决定 binary / linear search）
✅ 澄清输入范围。

Inputs 有多大、范围如何？
✅ 澄清输入格式。

负数？浮点数？空？Null？重复？极大？
✅ 走一个简化例子确认理解。

例如 palindrome checker：先举 "KAYAK" => true、"MOUSE" => false，再问面试官是否符合预期。
❌ 面试官没允许前不要直接开始写 code。

最糟糕的是直接开始写。面试官期待你先进行讨论，包括 approach、time/space complexity。

这段讨论可能几分钟到 5-10 分钟，取决于题目复杂度。也给面试官提供机会提示你。

✅ 如果卡住，用结构化方法帮助回忆/找思路。
✅ 提出多个高层方案（不用深入实现细节），像和 coworker 一样讨论 tradeoffs。
例如 Two Sum：
1. 双层循环，时间 O(n²)，空间 O(1)。
2. 用 hash table 一次遍历，时间 O(n)，空间 O(n)。讨论 tradeoffs 并说明为何选择后者（通常时间复杂度更低）。
✅ 明确说出时间/空间复杂度并解释原因。

例如 O(n²) 因为双层 loop；O(n) 因为额外数组。复杂度优化可参考 algorithm optimization techniques。
✅ 选定最佳方案并继续优化。识别重复/重叠计算，用 caching 减少。
❌ 面试官没允许前不要开始写 code。
❌ 不要忽略任何给定信息。
❌ 不要显得对自己的方案或分析不确定。

✅ 只有在解释完方案、面试官点头后再开始写。
✅ 写的同时解释你的意图；必要时对比不同写法。

展示你对语言的掌控力。
✅ 速度适中，能讲清楚，但不要慢到超时。

太慢会没时间回答问题。
✅ 尽量写可运行的 code，而不是 pseudocode。
✅ 写 clean、straightforward 的 code，减少 syntax errors / bugs。

简洁实现优于复杂实现；遵循语言习惯与构造。
✅ 用能解释语义的变量名。

变量名要帮助你讲解。比如找 3 的倍数，用 multiplesOfThree 而不是 arr。
✅ 请求允许使用 trivial functions，而不必手写实现。

比如 reduce、filter、min、max。
✅ 采用模块化写法，从高层函数拆成 helper functions。

比如造车：先写 gatherMaterials()、assemble()，再拆 makeEngine() 等。也可以问是否需要实现 trivial helpers。
✅ 如果为了时间省略细节，要说出来并说明实际场景会怎么做。

例如“真实环境下我会用 regex 解析，而不是 split()”。
✅ [Onsite / Whiteboarding] 注意白板空间管理
❌ 面试官讲话时不要打断。
❌ 不要花太多时间写注释。
❌ 不要重复说同样内容。
❌ 不要用糟糕变量名。
- 避免极长或单字符变量名（除非 i, n 这类惯例）
❌ 不要不检查就 copy/paste 代码（变量可能需要改名）。

写完后不要说“done”。面试官期待你检查错误并补 test cases。

✅ 扫一遍代码，找 off-by-one 等错误。

像第一次读别人代码一样检查，并讲述你如何发现问题。
✅ 和面试官 brainstorm edge cases，并加 test cases。（参考 algorithms cheatsheets）

常见边界：大输入、空集、单元素、负数等。
✅ 用 test cases 走一遍代码。
✅ 找可重构点。
✅ 再次说明时间/空间复杂度。

提醒自己是否有偏离复杂度的实现。
✅ 解释 trade-offs，以及如果有更多时间会如何改进。
❌ 不要写完就直接宣布结束。
❌ 不要和面试官争论。面试官出错的概率很低。