一场面试让候选人在白板上写"LRU 缓存"。他直接写出了完整的双向链表 + 哈希表实现，代码正确、边界到位，20 分钟一字不差。面试官给了高分——而团队后来发现，他在这类"背过的题"上很强，遇到"没见过的需求"就完全卡住。
白板环节的价值不在"能不能写出正确代码"，而在能不能在"不完整的信息"下推演出方案。这个区分有个"低成本"的办法：在他开始写之前问一句"你打算怎么验证"。想过的人会说"我会先测空表与重复键"；背过的人会说"应该没问题"。
而"背过"与"想过"在白板上的表现截然不同，只是需要特定的观察方式。
1. 白板环节该看什么
| 观察点 | 说明 |
|---|---|
| 澄清需求 | 会不会先问"规模多大、读写比多少" |
| 拆解步骤 | 能否把问题切成可验证的小块 |
| 选择方案 | 有没有比较过两种做法 |
| 处理边界 | 会不会主动想到空/满/并发 |
| 应对变化 | 需求改一处时能否调整 |
第一项最能区分人："背过的人直接开始写，想过的人先问约束"。第一项的观察要具体：他问的是"约束"还是"细节"。"数据规模多大"是约束，"用什么语言"是细节——前者说明他在考虑方案，后者只是准备动手。
而问约束这个动作，在真实工作里是必需的。
第五项是最有区分度的：在写完初版后加一个约束（如"现在要求 O(1) 的随机访问"），看他能否调整——"背过"的答案调整不了。
2. 三道题的设计
| 类型 | 目的 |
|---|---|
| 熟悉题（如 LRU） | 看基本功与代码质量 |
| 变形题（加约束） | 看适应能力 |
| 开放题（设计一个模块） | 看拆解与取舍 |
第二项（变形题）的成本几乎为零：不用新出题，只需加一句约束。而它恰好落在"背过的答案扛不住"的位置上。
第一项不应占全部时间：它区分度低（很多人背过），但能看"代码是否整洁、边界是否想到"。
第二项是"性价比最高"的：在原题上加一条约束，成本几乎为零，区分度立刻上升。
第三项适合资深岗：没有唯一答案，因此能看到"怎么权衡"。
白板前还要说清"规则"，否则分数会被"形式不熟"污染：
// 开场的三句说明（十秒）
1 语言随意，伪代码也行，重点在思路
2 可以随时提问，我不会因为你问而扣分
3 写完后我会加一个约束，你现场调整
// 第 3 句是关键：提前说"会变"，能看出"是否准备了应对"
3. "卡住"时的处理
| 候选表现 | 面试官动作 |
|---|---|
| 沉默超过 20 秒 | 给方向，不给答案 |
| 写出错误方案 | 让他自己验证（举例） |
| 反复改同一处 | 提示"先写能跑的版本" |
| 说"我不会" | 换更小的子问题 |
第一项的"20 秒"是个经验值：**超过这个时长，多数人的思考已经变成"焦虑循环"**第二项（写出错误方案）不该立刻纠正：让他自己举一个例子跑一遍，往往能自己发现问题。而"被指出错误"与"自己发现错误"，反映的是两种不同的能力。
，而提示能把它拉回来。
第三项的用处在于"改变评价维度"：从"能不能一次写对"变成"能不能迭代"。而后者才是真实工作里的常态——真实需求永远不是一次写完的。
第三项的提示很有效："先写一个能跑但慢的版本" ——它把"完美主义"变成"可迭代"，而后者更接近真实工作。
// 提示阶梯（从轻到重，每级只给一级）
L1 "你可以先说说思路，不用写"
L2 "如果数据量很小，你会怎么做？"
L3 "这个场景下，读多还是写多？"
L4 "考虑用一个哈希表加速查找"
// 记录：用了第几级才推进 → 这是评分的一部分
4. 代码质量的观察点
| 观察点 | 说明 |
|---|---|
| 命名 | 是否有意义、是否一致 |
| 分层 | 有没有把"数据结构"与"操作"分开 |
| 边界 | 空、满、重复键 |
| 复杂度 | 会不会主动说明时间/空间 |
| 可测性 | 会不会想到"怎么验证" |
第四项要求"主动说明"："这里查找是 O(1)，删除是 O(1)"——能说清复杂度的人，通常真的理解自己的方案。
第五项常被忽略："怎么验证" 这个问题在真实工作里天天出现第四项（复杂度）要听"是否主动"：写完就说明复杂度的人，通常在心里已经推过一遍；而问起来才说的人，可能只是记住了结论。
，而在白板上几乎没人问。
"变形题"的设计有几个模板，可以直接套用：
// 四种变形（原题不变，只加一层）
1 加约束：LRU 改成"还要支持 O(1) 随机访问"
2 改规模：从"1 万条"改成"1 亿条，内存 2GB"
3 改并发：从"单线程"改成"多线程安全"
4 改接口：从"get/put"改成"批量 get"
// 每一种都能暴露"背答案"与"真理解"的差别
5. 白板 vs 上机
| 形式 | 优势 |
|---|---|
| 白板 | 看思路、看沟通 |
| 上机（IDE） | 看工程习惯、可验证 |
| 带回家的作业 | 看真实产出，但可代做 |
| 现场结对（pair） | 最接近真实工作 |
第四项是"信息量最高"的形式：两个人一起改一段真实代码，能看到"他怎么读代码、怎么提问、怎么接受反驳"。
第二项（上机）的代价是"IDE 会补全"：自动补全让人可以不理解 API 也能"写出来"，于是"理解程度"被掩盖。这也是"上机题要看过程而不只看结果"的原因。
而白板的独特价值是"无法运行"：没有编译器帮你，于是"能不能想清楚"暴露得更彻底。
还有一类"看似通过"的情形值得标记：候选人写完后自己说"这里可以优化，但时间不够"。这句话本身是好信号（他知道局限），但要看"他指的是哪一处"——指到真问题说明理解到位，指到无关细节说明只是口头惯性。
// 三类"收尾发言"的读法
"这里时间复杂度是 O(n)，可以用堆优化到 O(log n)" → 理解到位
"命名可以更好" → 无关细节
"应该没问题" → 无自评能力（弱信号）
6. 排错：五种"白板环节失效"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 所有人都做得很好 | 题目被背过 | 加变形题 |
| 有人完全写不出 | 紧张或不适形式 | 允许说思路 |
| 分数与入职表现不符 | 只测了记忆 | 加"应对变化" |
| 时间不够 | 题目太大 | 拆成两段 |
| 争议大 | 只看结果不看过程 | 记录关键动作 |
第三项是"白板"最常被质疑的地方，而它的解法不是"取消白板"，而是加"变形"与"变化"第五项（争议大）的解法是"记录关键动作"："第 8 分钟开始写、第 12 分钟主动加边界、第 18 分钟被加约束后重排了结构"——这类记录比"感觉还行"更能支撑复议。
——因为"背过"扛不住变化。
最后一个"记录"模板，让白板环节的结论可复核：
// 白板记录（五行）
澄清：问了"规模/读写比/是否并发"
过程：先写朴素版（10 分钟）→ 加边界（5 分钟）→ 被加约束后重排（8 分钟）
质量：命名清晰、边界覆盖空/满、主动说明复杂度
卡点：第 14 分钟卡在"删除时如何维护顺序"，给 L3 提示后推进
结论：思路可靠、应对变化能力强（L3 才需提示）
7. 边界：什么情况不必用白板
| 场景 | 为什么 | 做法 |
|---|---|---|
| 资深岗（看架构判断） | 白板太细 | 用系统设计题 |
| 前端/移动端 | 更看工程实践 | 上机或看作品 |
| 时间极短（20 分钟） | 不够写代码 | 只谈思路 |
| 已有高质量开源作品 | 作品即证据 | 直接看作品 |
最后一条与"候选人体验"有关的边界：白板环节最容易让人紧张，而紧张与能力无关。所以"允许先讲思路再动手""允许用伪代码"这类安排，实质是"降低与岗位无关的干扰"。
判断口径一句话：我要判断的是"能不能想清楚"还是"能不能写出来"。前者用白板（或口头推演），后者用上机——两者的题目设计完全不同。
8. 自测
- 白板环节最该看哪一项？为什么"先问约束"能区分"背过"与"想过"？
- 三道题里哪一道"性价比最高"？它为什么能立刻提升区分度？
- "卡住超过 20 秒"为什么必须给提示？"先写能跑的版本"解决了什么问题？
- 代码质量五个观察点里，哪一项在真实工作里天天出现却在白板上几乎没人问？
- 白板的独特价值是什么？为什么"带回家的作业"信息量反而低？
- 判断"该用白板还是上机"的那个问题是什么？