010. 導言｜面試的 Bar 變高，真正稀缺的是判斷力
四年前有效的系統設計面試框架，到了 AI 普及、教材滿天飛的今天，為什麼仍然有效？因為工具與題庫改變了，面試真正想看的東西沒有變：你能不能在資訊不完整、時間有限、方案不只一個的情況下，做出合理判斷，並讓另一個工程師願意跟你一起往下走。
這支影片由 Terry Chen 與具備矽谷面試、招募經驗的來賓討論「工程師面試的 Bar 是否變高」，以及怎麼在 System Design interview 裡拿到 Strong Hire。原始來源可在這裡觀看：工程師面試 Bar 變高了？如何在面試中拿 Strong Hire。
影片的答案不是再背一套更完整的模板。Strong Hire 的核心，是候選人展現出超過應徵職級的訊號：面中階職位時像 Senior，面 Senior 時讓人看見 Staff 的潛力。這個「超過」也不是塞更多技術名詞，而是主導問題、解釋取捨、控制複雜度、取得 buy-in，必要時還能帶給面試官一個原本沒想到的視角。
這也是為什麼基礎知識越容易取得，面試反而可能感覺更難。當 LeetCode、System Design 教材與 AI 把平均準備水位往上抬，會背 cache、queue、sharding 已經不稀奇。真正拉開差距的，是你是否知道何時不該加 cache、為什麼現在不需要 queue，以及什麼條件出現後才值得讓架構變複雜。
021. Strong Hire 是什麼｜不是零失誤，而是表現超過職級
影片把 Strong Hire 定義成一種「高於當前 level 的表現」。如果候選人面的是中階職位，卻從頭到尾展現 Senior engineer 的訊號；或面 Senior，卻讓面試官看到 Staff level 的潛質，就更容易留下強烈印象。
這和「每題都答對」不完全相同。系統設計面試本來就沒有唯一解，面試官通常也不是拿一張標準架構圖逐格比對。更重要的是：當條件改變、需求模糊或方案被質疑時，你能不能繼續推進討論。
影片提到一個更高階的訊號：資深候選人若能讓面試官在討論中學到新東西，通常代表他不只是讀過材料，而是真的接觸過類似系統，能把複雜問題講得深入淺出。面試官往往也熟悉題目，很快能分辨一個 option 是從實戰限制推導出來，還是候選人臨場拼出的術語組合。
不過，這不代表面試時要刻意「教」面試官，更不是用冷門細節壓過對方。真正有效的狀態是合作：你提出一個對需求有幫助、又能讓討論往前的觀察。知識深度只有在能服務共同決策時，才會成為 Strong Hire 的訊號。
影片也討論應徵 Senior 還是 Staff 的策略。來賓傾向在有選擇時挑戰較高 level，理由包括部分公司可能提供 down-level offer，而且不同職級的薪資 band 不同。但這是講者依個人經驗提出的策略，不是所有公司都適用。不同組織的職級校準、面試 loop 與 down-level 政策差異很大，候選人仍應向 recruiter 問清楚。
032. 誰在主導面試｜Junior 等題目，Senior 重寫問題
影片對 Junior 與 Senior 的分界，給了一個很有操作性的判準：Senior 候選人應該主導 interview，而不是等面試官一步步引導。
「主導」不是搶話，也不是無視題目直接畫出自己背好的架構。它更像真實工作裡帶一個 project：先確認問題，再根據需求與現有工具提出幾個選項；說明各自的 pros and cons；最後把選擇和 requirement 綁在一起，邀請面試官確認方向。
Junior 候選人常見的狀態，是需要提示才會補上根本需求，或很快跳到某個元件，卻沒有先說清楚它在解什麼問題。這不一定是能力不足，更多時候是經驗尚未形成「同時看廣度、深度與時序」的習慣。
Senior 的對話可能是：
這裡有 Option A 與 Option B。A 的實作和維運成本較低，足以支撐目前的流量；B 在 scale-up 時更有彈性，但會增加系統複雜度。依照我們剛才確認的需求，我會先選 A，並在某個門檻出現時再切換。
這段話的技術內容未必驚人，卻同時完成四件事：提出選項、辨識代價、連結需求、建立升級條件。面試官能從中看見的，不只是一張圖，而是候選人未來如何與同事做設計評審。
主導也包含傾聽。影片後段特別強調 confidence 與 learner mindset 必須同時存在：你要有自信說明為什麼這樣做，也要在面試官提出質疑時聽懂背後問題，適時修正。只會堅持不是 seniority；能吸收新資訊後更新設計，才是。
043. 技術深度怎麼被看見｜不要背答案，要能拆 Trade-off
沒有做過每一種系統，怎麼回答陌生題？影片先把許多服務還原到共同骨架：request-response、server、state、database，再依 traffic pattern 與業務需求調整。表面的 business logic 不同，底層常反覆出現 read-heavy、write-heavy、latency、consistency、availability、成本與維運等問題。
真正的學習不是記住「某題用 Cassandra」，而是一路追問：為什麼是 Cassandra？同樣是 NoSQL，其他 option 為什麼不適合？它在這個情境的優勢與代價是什麼？如果流量、資料模型或一致性需求改變，答案是否也要改？
這種追問會形成可遷移的知識。資料庫產品很多，但它們解決的底層問題高度重疊；差別在採取的 approach、犧牲的性質與適用條件。候選人若只背產品名稱，面試官一改 requirement，答案就會垮掉。若理解問題本質，沒有看過原題也能重新推導。
影片的關鍵句是：Option A 與 Option B 可能都能 work，面試官想聽的不是唯一正解，而是你能否 justify decision，並證明它 meet requirements。這裡的深度不等於講得越底層越好。若題目還在 high-level design，你卻花十分鐘解釋 virtual node，反而可能失去節奏。
深度應該由問題驅動：先建立最小可行架構，再挑真正有風險、會影響目標的部分 deep dive。面試時間有限，能判斷「哪裡值得深入」本身就是能力。
054. Always Start From Simple｜用決策合理化換取 Buy-in
「Always start from simple」是整支影片最值得帶走的實戰原則。架構圖上每增加一個 box，都不只是多一個漂亮元件，也代表新的開發成本、金錢成本、監控需求、故障模式與維運責任。
因此，讓系統變複雜之前，候選人要回答兩個問題：這個複雜度解決了哪一個已確認的需求？如果先不加，系統會在哪個具體條件下失效？
這會把「炫技」改寫成「投資決策」。例如 cache 可以降低 database 負擔，但也帶來 invalidation、stale data 與額外觀測問題。queue 可以削峰與解耦，但也加入重試、順序、重複處理與 eventual consistency。這些元件不是看到關鍵字就自動加入，而是在需求與限制推導後才出現。
Buy-in 也在這個過程裡形成。候選人可以明確說：「目前需求下我會先用較簡單的方案，因為它已足夠；若 QPS、延遲目標或可靠性門檻提升，再引入另一層架構。」面試官不必和你偏好同一套技術，但他能看見你的決策是可追蹤、可辯論、可修改的。
影片指出，較不資深的回答常停在「這裡就是要用某個技術」。當面試官追問原因，理由卻沒有與 requirement 綁定。這時問題不一定是技術選錯，而是候選人無法證明自己在解題，而不是在重播準備材料。
065. Senior 與 Staff 的分界｜廣度之外，還要有可辨識的 Expertise
影片把 Senior 與 Staff 的差異概括為：Senior 需要一定廣度；Staff 除了廣度，還要在特定領域有足夠深度，形成可辨識的 domain expertise。
這種 expertise 在面試裡通常不是自我宣告，而是從決策角度自然露出。當大家都在比較 Technology A 與 B，Staff-level 候選人可能會補上一般討論忽略的成本模型、組織限制、遷移風險、操作經驗或 failure mode。他不只知道底層原理，也能把這些資訊轉成 leadership 聽得懂、願意採納的理由。
因此，Staff signal 不是知道更多名詞，而是能看見「技術選擇如何穿過系統、團隊與商業限制」。同一個架構在十人新創與大型平台未必有同樣答案；同一個 database 在新系統與高風險遷移案，也有完全不同的成本。
對經驗較少的工程師，影片沒有假裝讀幾篇文章就能補齊實戰。講者直接承認：若沒有 deploy 過大型分散式系統，很多細節只能先從材料推演。但仍有務實做法：利用公有雲與現成工具搭一個端到端服務，讓它真的上線、真的被使用，再去讀文件、比較不同雲服務的設計與適用情境。
AI 可以在這裡幫忙摘要文件、解釋陌生概念，但學習不能停在摘要。真正可用的知識，來自你把服務接起來、遇到限制、看到帳單、處理錯誤，然後理解原本抽象的 trade-off 為什麼存在。
076. 練習不是多刷題｜Mock Interview、AI 與真實案例
影片建議在準備後期安排 Mock Interview，最好由有面試官經驗的人提供回饋。原因很直接：正式面試往往不會告訴你哪裡失分；沒有 feedback，做一百次也可能只是重複同一個盲點。
Mock 的價值不只是熟悉題型，而是暴露對話問題：是否太快進 solution、是否漏問 scope、是否每次被追問就防禦、是否無法在白板與口頭敘事間維持共同脈絡。這些問題只看書很難發現。
影片也談到 AI 的位置。講者認為，AI 很適合在你已有知識框架時補足細節：你知道自己缺什麼，能問出 right question，也有能力判斷回答是否 make sense。反過來，如果對問題完全沒有概念，AI 可能給出非常完整、非常濃稠的答案，你卻不知道如何抽出一個適合一小時面試的 high-level solution。
換句話說，AI 可以加速查資料，卻不能替代問題定義與品質判斷。這和系統設計面試本身的要求一致：答案不是資訊量競賽，而是取捨與結構。
影片分享一個 Anthropic 面試案例。題目圍繞有限 GPU 下的 traffic scheduling，目標是提高資源利用率。講者表示自己沒有做過完全相同的題目，但從目標出發，思考如何把低優先流量移到離峰、以 async processing 平滑尖峰，再透過紙上計算提出合理 scheduling。這個案例的價值不在具體解法，而在示範：陌生包裝底下，仍可用既有的容量規劃、優先級與非同步處理經驗推導。
087. 一套可重複的框架｜從 Clarify Requirements 到 High Level Design
影片最後把陌生題目的處理方式收斂成一套 top-down framework。
第一步：Clarify Requirements
先把抽象題目縮成可完成的 scope。「設計 YouTube」不是要在一小時內設計所有功能，而是確認這輪要處理觀看、上傳、留言，還是哪個核心 feature。Requirement 也要包含非功能性條件：流量、延遲、一致性、可靠性、資料量與優先級。
第二步：建立 High Level Design
先畫出少量 high-level abstraction，說明每個 black box 的責任，讓 end-to-end data flow 可以滿足剛才確認的需求。這一階段不需要急著把每個元件拆到最細。
第三步：提出選項與決策
對關鍵節點提出 Option A、B，說明 pros and cons，並清楚指出目前為何選其中一個。決策必須和 requirement 相連，而不是和記憶中的標準答案相連。
第四步：選擇性 Deep Dive
依照風險、瓶頸與面試官追問，深入資料模型、容量、cache、partition、queue、consistency、failure handling 或 scheduling。Deep dive 的位置與品質，往往最能顯示候選人的 seniority。
第五步：保持共同設計
持續確認面試官是否同意 scope 與方向。面對質疑時先理解問題，再調整設計。面試不是一場單向簡報，而是一次壓縮版的 design review。
這套框架不能替你補上所有實戰經驗，也無法保證 Strong Hire。它真正的作用，是避免在陌生題目前失去節奏：先定義問題，再建立最小方案；先證明簡單方案不夠，再增加複雜度；先讓對方看懂你的決策，再展示技術深度。
面試的 Bar 也許真的提高了，但值得投資的能力並沒有變成更花俏的答案。最可靠的訊號仍然是：你能把模糊問題變清楚，把多個選項變成決策，把技術細節變成團隊可以承擔的設計。這才是 Strong Hire 背後真正可帶回工作的能力。