回家作業：審查的人真正會先打開什麼
回家作業看起來是最公平的形式——沒有計時器、沒有陌生人盯著，只有工作本身。然後拒絕信來了，附上一句含糊的回饋，而你完全想不通，因為測試明明都過了。
沒人提起的那種不對等
你的作業只是某個資料夾裡的其中一份，而打開它的人是在本業之外抽空做這件事。他們不會逐行讀。他們會打開 README、把專案跑起來、掃一眼目錄結構，然後看兩三個檔案。
這不是偷懶——這是這種形式能大量運作的唯一方式。但它代表：花在他們不會看的地方的力氣，對最後的決定沒有作用。
沒有哪家公司公開每份作業的審查時長，但請照「幾分鐘而不是幾小時」來準備。接受這個前提之後，策略就反過來了：目標不是展示你會的一切，而是讓該被看到的東西不可能被錯過。
被打開的順序
README。幾乎都是第一個。如果它沒辦法在一分鐘內講清楚怎麼跑起來，審查的人從一開始就帶著不耐煩。如果專案根本跑不起來，通常到這裡就結束了。
啟動指令。一行在乾淨機器上就能跑起來的指令，比程式碼裡任何抽象都更有價值。任何需要本機設定、你又忘了寫進文件的東西，都會算在你頭上，而且你永遠不會被告知。
進入點檔案。他們想看你怎麼組織流程——請求從哪裡進來、邏輯放在哪裡、資料往哪裡去。
一兩個真正有邏輯的檔案。通常是題目裡最難的部分。他們就是在這裡判斷你寫的程式碼別人能不能維護。
測試，但只掃一眼。很少逐行讀，但會看有沒有、長什麼樣子。在棘手的地方寫幾個測試，比把 getter 覆蓋得滴水不漏更好看。
過度設計是最常見的失敗
直覺會想展示廣度：加一層快取、替儲存後端做一層抽象、為沒人提過的需求做一套外掛機制。對寫的人來說這看起來很資深，對審查的人來說這看起來是判斷力不好。
Google 公開的 Code Review 指南甚至把這條寫進檢查清單：開發者不應該去實作那些「將來也許需要、但現在並不知道需要」的東西。
它傳達的訊號是：這位應徵者分不清哪些問題值得解決。在真正的團隊裡這很昂貴，因為代價會落在之後每一個碰這段程式碼的人身上。
更好的做法是：把被要求的東西乾乾淨淨地做完，然後在 README 裡寫兩行你刻意沒做什麼。「沒有做快取——資料量夠小，加上它只會增加複雜度，拿不到可以衡量的效益。」這句話證明的，正是那層抽象想暗示卻沒證明的判斷力。
寫 README 時，就當你不在場
因為你確實不會在場。三個短段落幾乎能涵蓋一切：怎麼跑起來、你做了哪些決定以及為什麼、如果有更多時間你接下來會做什麼。
中間那一段是應徵者最常跳過、而審查的人最看重的。每一個不明顯的選擇，在程式碼裡都是隱形的——它看起來像唯一的選項，而不像一個決定。兩句話就能把一次沉默的選擇，變成看得見的推理。
第三段是你替「沒做的事」爭取分數的地方。由你自己列出的限制，看起來是清醒；同樣的限制被審查的人發現，看起來就是疏漏。
範圍和時間
如果題目說四小時，你花了十二小時，這並不是你以為的那種炫技。審查的人可能會檢查作業是否符合題目給的時間預算，因為一個不會替自己設時間界線的應徵者，到了工作裡也一樣不會。
如果真的超時了，別藏起來，也別拿來炫耀。在 README 裡寫明實際花了多久，並說清楚如果要壓回題目要求，你會砍掉什麼。
如果時間到了還有東西沒做完，就附上一段說明交出去。被你點名的缺漏功能是一個範圍決定；同樣的缺口不提，就是疏忽。
後面那通電話才是真正的考題
很多回家作業之後會有一場圍繞程式碼的對談，而那通電話的份量通常比作業本身還重。他們就是在那裡弄清楚你是不是真的理解自己寫了什麼。
要預期那種讓人不太舒服的問法：不是「你為什麼這樣做」，而是「如果輸入大一萬倍，哪裡會先垮」，或「如果明天多一個資料來源，要改什麼」。
電話前一小時把自己的程式碼重讀一遍。解釋不了一週前自己做的決定，這個訊號比決定本身的任何缺陷都更糟。
這時候 Copilot 能做什麼
Interview Copilot 即時跟著這一關，對方一講完問題，就把結構放到你的螢幕上——這個問題真正在問什麼、哪個限制條件是關鍵、哪個取捨值得講出來。不是讓你照念的台詞：是一個支架，你用自己的話從上面講下去。
資料來源
- Google Engineering Practices — What to look for in a code review — Review 要檢查什麼，包括競爭條件和過度設計（查證於 2026-10-14）
- Amazon Jobs — SDE II interview prep — 線上測驗、四場 55 分鐘面試、至少一道系統設計題（查證於 2026-10-14）
註：Google 的面試建議頁面寫明，面試期間不允許使用 Google 搜尋和 AI 工具。其他公司各有規定——在真正的面試中使用任何助手之前，先確認對方的規則。
FAQ
審查的人打開回家作業時，最先看什麼？
通常先看 README，再看能不能跑起來，然後是進入點和一兩個核心邏輯檔案，測試主要看有沒有、長什麼樣子。沒有哪家公司公布固定順序，但這解釋了為什麼一個能跑、README 清楚的專案，勝過一個更聰明但要費很大力氣才能啟動的專案。
回家作業應該花多少時間？
題目說多久就花多久，並且說清楚你砍掉了什麼。大幅超時不會被獎勵——它讓你的成果失去代表性，也暴露出範圍控制不好。一小段「再給我一天我會做什麼」就能涵蓋你沒做的部分。
回家作業過度設計是問題嗎？
這是最常見的失敗。替一個只需要一個服務的任務加上多層抽象、外掛機制或訊息佇列，看起來就是判斷不出範圍，而這正是資深審查者在篩的東西。
後面那通電話會發生什麼事？
你要為自己的決定辯護：為什麼是這個結構、你會改什麼、它在高負載下哪裡會垮。作業幫你換到這通電話；真正被打分數的是電話本身，所以之前先把自己的程式碼重讀一遍。