面试官追问细节时，怎样讲清楚你做过的项目

这是你的项目。大部分代码是你写的，最棘手的故障是你凌晨两点修好的，房间里没有人比你更了解它。所以当面试官问缓存为什么这样失效，那个感觉显而易见的答案说到一半就散了，你会很吃惊。

心理学家测量过这种差距。了解它的原理以后，准备起来就容易多了。

为什么讲清楚自己的工作很难

在一组著名研究中，Leonid Rozenblit 和 Frank Keil 请耶鲁大学的研究生用七分制评估自己对日常物品的理解程度，包括拉链、抽水马桶、圆柱锁和直升机。随后学生们一步一步写出每样东西的工作原理，并重新评分。分数下降了。在回答一个需要真正了解机理的诊断问题之后，比如怎样撬开一把圆柱锁，分数降得更多。最后学生们读了专家的解释，回头评估自己原先懂多少，分数仍然很低。他们最初的理解感本来就太高了（Rozenblit 和 Keil，2002）。

作者把这种现象称为解释深度错觉。它在解释类知识上比在事实、步骤或故事上强得多，而作者给出的原因和软件项目吻合得惊人。工作的时候系统就在眼前，于是能查到的东西感觉像是已经知道。你理解了上一层，就以为下面几层也都懂。你很少需要从头到尾讲一遍整个系统，所以从来没发现自己的解释会在哪里断开。

面试问的正是那个诊断问题。

面试官在追问什么

亚马逊的招聘人员直接指出了最常见的失误，候选人讲得不够深入。对每个问题，他们希望听到一个具体情境的详细经过，包括数字、项目里都有谁，以及你交付的成果。他们还请候选人用第一人称描述行动，因为面试关心的是你做了什么（亚马逊招聘人员）。亚马逊的领导力准则之一 Dive Deep（刨根问底），要求人们始终掌握细节（亚马逊）。

不论在哪里面试，都可以预期同样的形式。你给出一个简短概述，面试官接连提问，每个问题都深入一层。概述是简单的部分，评估你的是追问。

两分钟介绍项目

开头讲问题，以及受它影响的人。一两句话，带上让它变难的那个限制条件。

我们患者门户的搜索要将近一秒，春季版本上线后相关工单翻了一倍。

你负责什么、别人做了什么，各用一句话说明。两分钟里的大部分时间属于两三个决定，每个决定都要说出你放弃的那个方案。带有被放弃方案的决定能体现判断力，一串工具名称什么也说明不了。

我们本来可以加副本。我选了预先计算的索引，因为慢的是排序，副本只对读取有帮助。

结尾讲结果、一个数字，以及你会改变什么。

p95 从大约 800 毫秒降到了 200 毫秒以内。如果重做，我会从一开始就给重建任务加上背压控制。

讲到这里就停下来，让面试官选择往哪里追问。

准备好追问的阶梯

有几个追问几乎在每次深挖项目时都会出现，每个都值得在面试前写下一两句话。面试官会问你为什么用这个设计、没有选那个显而易见的方案，最难的故障是什么、你是怎样找到的，你怎样知道它有效、衡量了什么。他们还会问某个依赖宕机、任务执行到一半重启或者输入量变成十倍时会发生什么，哪些部分是你亲自写的、决定的或审核的，以及如果重做你会怎么改。

Rozenblit 和 Keil 的测试同样可以用在自己身上。挑出项目的核心流程，一个请求或一个任务从头到尾怎样执行，不打开代码，一步一步写下来。为它加一个诊断问题，比如服务在中途重启会发生什么，并回答它。每一个让你犹豫的地方，都是一个等着你的追问。打开代码，补上这个缺口，把回答写成一句你能说出口的话。

让好项目减分的错误

最常见的错误是罗列技术名称。React、Node、Postgres 和 Redis 说明不了你怎样思考。紧随其后的是从头到尾替整个团队发言，而你来这里是为了讲自己的部分。很多项目介绍从头到尾没有一个数字。延迟、用户数、金额、节省的时间或者错误率，一个就够。有些候选人说得比做得多，而下一个问题会再深入一层。还有人把每个组件都讲一遍。挑出承载了最有意思的决定的两个，其余留给提问。

让文件替你做一部分功课

我们做 Prepped，部分原因就在这里。在 Prepped 里为一场面试添加项目文件夹或 GitHub 仓库，会前准备会读取这些文件，针对你可能被问到的代码问题写好回答，并标明每个回答出自哪个文件。文件里没有依据的内容会被标出来，你知道该核对哪里。面试题库还有一个项目结构，包括问题、你的角色、关键决定和成果，可以用来反复练习项目介绍，直到能在两分钟内讲完。