Coding interview preparation

顶级科技公司 coding interviews 的评估标准

整理自 Google、Amazon、Apple、Netflix 的 coding interview rubric

想知道 Google、Amazon、Apple、Netflix 这些 top tech company 是怎么评估 coding interview 的么？

其实各家标准差异不大。虽然 rubric 用词不同，但评估维度基本一致。

这篇会详细讲 big tech 的通用评估流程，并附上一个 example rubric，方便你自己或和朋友练习时使用。

如果你还没看过，可以先看我的 Coding interview best practices cheatsheet，它总结了如何在面试中满足这些评估标准。

Candidate scoring methodology

在 FAANG / MANGA 公司里，coding interview 的 rubric 通常可以分成 4 个维度：

Communication - 是否会澄清问题、解释思路、在写 code 时持续沟通？
Problem Solving - 是否理解问题、能提出合理解法、做 trade-offs 分析并优化？
Technical Competency - 实现速度与准确度如何？有没有 syntax errors？
Testing - 是否覆盖常规与 corner cases？能否自我修正 bug？

常见评分方式有两种：

每个维度给分（如 1-4），最后汇总成总分
根据整体表现直接给一个总分（如 1-4）

不管哪种方式，评分区间一般是：

Strong hire
Hire
No hire
Strong no hire

有些公司会加一个中间档，用于面试官犹豫或需要更多评估时。

分数如何影响结果？

不管评分方法如何，最终结果取决于整体表现，而不是单纯数学分数。

每个 phone screen 通常只有 1 位 interviewer，所以如果他们不给你 “pass”（相当于 “Leaning hire” 以上），你就不会进入下一轮。如果该轮没有明显信号，可能会要求你做 follow-up phone screen。

大部分 top tech companies 会让候选人完成 full interview loop 后再做最终决定。如果不同轮次结果有分歧（有的 pass，有的 fail），interviewers 会基于你展示的 signals 进行讨论。这就是为什么整个面试流程的表现都很重要。

在一些情况（比如 follow-up phone screen），如果出现以下情况，可能会让候选人补一轮：

评估内容有缺口，例如两位 coding interviewer 问了非常相似的问题
候选人在某些维度 signal 混乱，需要更多轮次来判断

一般来说，每轮评分和 feedback 都对所有面试官可见。有时他们还能看到你过去在同公司面试的反馈，避免重复出题。公司也会看你是否比过去有所成长。如果你曾经被拒，可以反思原因并在下一次面试中解决。

各评估维度的详细说明

1. Communication

基础 communication signals：

提出合适的澄清问题
解释思路、理由与 tradeoffs
写 code 时持续沟通
表达清晰、有条理、简洁

Score	Overall evaluation
Strong hire	全程沟通充分、有条理、简洁清晰，能清楚表达思考过程、对题目的理解、解法与 trade-offs。面试官完全能跟上。
Leaning hire	沟通清晰但不够充分，面试官需要追问某些点（比如思路或推导）。
Leaning no hire	沟通不足/不清晰/缺乏结构（例如直接开始写 code 不解释），面试官难以跟上。
Strong no hire	没法清晰沟通，甚至被问到也沉默，面试官很难理解候选人的思考过程。

2. Problem solving

基础 problem solving signals：

提问澄清，快速理解问题
系统化、逻辑化处理问题
能提出优化解法
正确分析时间/空间复杂度
不需要面试官给大量提示

高级 problem solving signals：

能提出多个解法
清楚解释 trade-offs，最终选出最适合方案
有时间讨论 follow-up / extensions

Score	Overall evaluation
Strong hire	基础 signals 全部满足，并有时间完成大部分高级 signals。
Leaning hire	能完成所有基础 signals，但时间不足以覆盖高级 signals。
Leaning no hire	只表现出部分基础 signals，其他欠缺。
Strong no hire	无法解决问题，或几乎不解释思路，解法混乱且错误。

3. Technical competency

基础 technical competency signals：

将讨论的方案转为可运行 code，bug 极少或没有
实现 clean/straightforward，无多余代码，无 syntax errors，遵守良好 coding practices（例如 DRY）
编码风格整洁（缩进、空格、变量命名等）

高级 technical competency signals：

能比较多种 coding 写法
展示对语言 constructs 和 paradigms 的掌握

Score	Overall evaluation
Strong hire	轻松展示基础与高级 competency signals。
Leaning hire	只展示基础 competency signals，落地为 code 时略有困难，语言范式使用不够理想。
Leaning no hire	很难写出可运行方案，syntax errors 多，语言范式使用不当。
Strong no hire	无法写出可运行方案，syntax errors 严重，语言范式使用非常糟糕。

4. Testing

Testing signals：

用更多常规 case 测试
能发现并处理 corner cases
能识别并自我修正 bug
能系统化验证正确性（像 debugger 一样逐行走）

Score	Overall evaluation
Strong hire	轻松展示所有 testing signals。
Leaning hire	testing signals 有一定表现，但难以覆盖所有 corner cases。
Leaning no hire	做了测试但忽略 corner cases，无法发现或修正 bug。
Strong no hire	没有测试常规 case，也没发现明显 bug，就直接宣布完成。