带回家作业：评审真正会先打开什么
带回家作业看起来是最公平的形式——没有计时器，没有陌生人盯着，只有活儿本身。然后拒信来了，附带一句含糊的反馈，而你完全想不通，因为测试明明都过了。
没人提起的那种不对等
你的提交只是某个文件夹里的其中一份，而打开它的人是在本职工作之外做这件事。他们不会逐行读。他们打开 README，把项目跑起来，扫一眼目录结构，然后看两三个文件。
这不是偷懒——这是这种形式能规模化运作的唯一方式。但它意味着：花在他们不会看的地方的力气，对最终决定不起作用。
一旦接受“十五分钟预算”这个前提，策略就反过来了：目标不是展示你会的一切，而是让该被看到的东西无法被错过。
被打开的顺序
README。几乎总是第一个。如果它没能在一分钟内讲清楚怎么跑起来，评审从一开始就带着不耐烦。如果项目压根跑不起来，通常到这里就结束了。
启动命令。一条在干净机器上就能跑通的命令，比代码库里任何抽象都更有价值。任何需要本地配置、而你又忘了写进文档的东西，都会算在你头上，而且你永远不会被告知。
入口文件。他们想看你是怎么组织流程的——请求从哪里进来、逻辑放在哪里、数据往哪里去。
一两个真正有逻辑的文件。通常是问题里最难的那部分。他们就是在这里判断你写的代码别人能不能维护。
测试，但只扫一眼。很少逐行读，但会看有没有、是什么形状。在棘手的地方写几个测试，比把 getter 覆盖得滴水不漏读起来更好。
过度设计是最常见的失败
本能是展示广度：加一层缓存、给存储后端做一层抽象、为没人提过的需求做一套插件机制。对写的人来说这像资深，对评审的人来说这像判断力差。
它传达的信号是：这位候选人分不清哪些问题值得解决。在真实团队里这很贵，因为代价落在之后每一个碰这段代码的人身上。
更强的做法是：把被要求的东西干干净净地做完，然后在 README 里写两行你有意没做什么。“没有做缓存——数据集足够小，加上它只会增加复杂度，拿不到可衡量的收益。”这句话证明的，正是那层抽象想暗示而没能证明的判断力。
写 README 时就当你不在场
因为你确实不会在场。三个短章节几乎能覆盖一切：怎么跑起来、你做了哪些决定以及为什么、如果有更多时间你接下来会做什么。
中间那一节是候选人最常跳过、而评审最看重的。每一个不显而易见的选择在代码里都是隐形的——它看起来像唯一的选项，而不像一个决定。两句话就能把一次沉默的选择变成可见的推理。
第三节是你为“没做的事”争取分数的地方。由你自己列出的局限读起来是清醒；同样的局限被评审发现，读起来就是疏漏。
范围和时间
如果题面说四小时，你花了十二小时，这并不是你以为的那种炫技。有些评审会专门核对提交是否与声明的时间预算相符，因为一个不会给自己设时间边界的候选人，到了工作里同样不会。
如果确实超了，别藏着，也别拿来炫耀。在 README 里写明实际花了多久，并说清楚如果要压回题面要求，你会砍掉什么。
而如果时间到了还有东西没做完，就带着一条说明交上去。被你点名的缺失功能是一个范围决定；同样的缺口不提，就是疏忽。
后续那通电话才是真正的考题
很多带回家作业之后会有一次围绕代码的对话，而那通电话的分量通常高过提交本身。他们正是在那里弄清楚你是否真的理解自己写了什么。
要预期不舒服的那种问法：不是“你为什么这么做”，而是“如果输入大一万倍会哪里先垮”，或者“如果明天多出一个数据源，要改什么”。
电话前一小时把自己的代码重读一遍。解释不了一周前自己做的决定，这个信号比决定本身的任何缺陷都更糟。
这时候副驾能做什么
Interview Copilot 实时跟着这一轮，在对方还在说话的时候就把一个结构放到你屏幕上——这个问题真正在问什么、哪个约束是关键、哪个取舍值得说出口。不是让你照念的台词：是一个支架，你用自己的话从上面说下去。
FAQ
评审打开带回家作业时，最先看什么？
先看 README，再看能不能跑起来，然后看测试，最后看代码。正是这个顺序，使得一个能跑、README 清楚的项目，胜过一个更聪明但评审得费劲才能启动的项目。
带回家作业应该花多长时间？
题面说多久就多久，并且说清楚你砍掉了什么。大幅超时不会被奖励——它让你的产出不具代表性，同时暴露范围控制能力差。一小节“再给我一天我会做什么”就能覆盖你没做的部分。
带回家作业做得过度设计是问题吗？
这是最常见的失败。给一个只需要一个服务的任务加上多层抽象、插件机制或消息队列，读起来就是判断不出范围，而这恰恰是资深评审在筛的东西。
后续电话上会发生什么？
你要为决定辩护：为什么是这个结构、你会改什么、它在高负载下哪里会垮。提交为你换来这通电话；真正被打分的是电话本身，所以之前先把自己的代码重读一遍。