Google 內部數據承認：面試表現與工作績效零相關
Google 前人資副總裁 Laszlo Bock 公開揭露：腦筋急轉彎和演算法白板題，無法預測任何事情。那外商面試到底在測什麼？
2015 年，Max Howell 在 Twitter 上寫了一段話，至今仍然是工程師圈子裡最被廣泛轉發的面試故事之一：
Homebrew 是 macOS 上最廣泛使用的套件管理器之一。它的創始人去面試 Google，因為一道白板演算法題被拒了。
這個故事之所以讓人不舒服，不是因為它荒謬 — 而是因為每一個有實力的工程師都在裡面看到了自己的影子。
你可能沒有創造過 Homebrew。但你可能有過類似的經驗：你的技術實力不差，甚至在某些領域比面試你的人還強。但因為你在一個限時、高壓、跟真實工作完全無關的白板環境下表現不好，你就被篩掉了。
問題是：那個篩選機制，真的有效嗎？
Google 自己的數據說：沒有
Google 前人力營運資深副總裁 Laszlo Bock 在 2013 年公開揭露了一份內部分析的結果：在分析了數以萬計的面試資料後，他們發現腦筋急轉彎與演算法白板題，與候選人入職後的實際工作績效之間的相關性是 : 零。
Bock 在接受紐約時報訪問時直言：「這些問題完全是浪費時間。它們無法預測任何事情。唯一的功用是讓面試官覺得自己很聰明。」
這不是某個教練或顧問的觀點。這是 Google 自己承認的。
白板面試測量的是什麼？焦慮
如果白板題不能預測工作表現，那它到底在測量什麼？
North Carolina State University 在 2020 年發表的一項研究給出了答案：傳統的技術面試帶來的壓力，會讓候選人的表現僅僅因為「被觀看」就下降超過 50%。
研究的結論是：白板面試測量的不是程式設計能力，而是「表演焦慮」。
你在一個限時的、有人在旁邊盯著你的環境裡，被要求解一道跟你真實工作幾乎沒有關係的題目。你的表現主要取決於你多擅長「在壓力下表演」，而不是你多擅長「做工程」。
我在 Arm 和 Intel 做 Hiring Manager 的時候，親眼見過這種情況太多次了。有一次，一位極資深的工程師在白板前緊張到連 for-loop 都寫錯。但我後來讓他坐下來，用紙筆畫他做過的系統——半小時後，他畫出了我見過最清楚的架構圖之一。
白板題判定他「不合格」。但他在真實工作中解決的問題，比大多數通過白板題的人都複雜得多。
不同面試方式的預測效度
那什麼樣的面試方式能真正預測工作表現？數據告訴我們：
| 面試方式 | 與工作績效的相關係數 | 意義 |
|---|---|---|
| 非結構化面試（閒聊型） | r = 0.20 – 0.38 | 幾乎沒有預測力 |
| 演算法白板題 | ≈ 0（Google 數據） | 零預測力 |
| Take-Home 實作測試 | r = 0.62 | 強預測力 |
| 程式碼品質 vs 可維護性 | r = 0.67 | 最強預測力 |
數據來源：McDaniel et al. (1994) 面試效度元分析、Google 內部數據（Bock, 2013）、IEEE Software Journal (2023) Take-Home 測試研究。
模式很清楚：越接近真實工作情境的測試，預測力越強。越遠離真實情境的測試（白板題），預測力越低。
LeetCode 獎勵的是「在封閉環境中找到單一最優解」的能力。但真實的工程工作充滿模糊性、妥協和跨部門溝通。這兩者之間的距離，就是面試結果和工作表現之間零相關的原因。
那外商面試到底在測什麼？
如果你理解了「白板題不能預測工作表現」，下一個問題自然就是：那什麼能？
Microsoft Research 在 2019 年發表的一份研究報告指出，高效能的工程師有兩個關鍵特徵：
第一，能處理模糊性。在有限的資訊和不完整的需求下，能獨立判斷該做什麼、不該做什麼。
第二，能避免分析癱瘓。知道什麼時候該停止分析、開始行動。不是追求完美方案，而是在限制條件下交付「夠好」的方案。
這兩個能力，白板題完全測不出來。白板題的環境恰恰相反 – 任何題目是精確定義的、有唯一最優解的、不需要跟任何人溝通的。
而在真實面試中（不是白板環節，而是 behavioral 和 system design 環節），好的 Hiring Manager 在聽的就是這兩件事：你能不能在模糊中做判斷？你做判斷的邏輯是什麼？
（如果你想更詳細了解 Hiring Manager 在面試的每一分鐘到底在評估什麼，我在另一篇文章裡用了三個場景做了詳細拆解：外商面試官真正在聽什麼: 來自一個做了十年 Hiring Manager 的人）
這對你意味著什麼？
你不需要刷更多 LeetCode。你需要改變你準備面試的方式。
具體來說：
停止把所有準備時間花在演算法題上。演算法是基本功，你需要會，但它不是決定你是否拿到 offer 的因素。數據已經告訴我們了 — 面試官最終的判斷，跟你的白板表現幾乎無關。
把更多時間花在準備你的「判斷力故事」。找出你工作中做過的三到五個真實決策 — 你面對了什麼模糊的情境、你有哪些選項、你為什麼選了這個、結果對公司有什麼影響。這些才是 behavioral interview 和 system design interview 的核心。
（如果你不確定怎麼把你的工程經歷轉換成 Hiring Manager 聽得懂的語言，這篇有三個真實案例的 before/after：同一段經歷，兩種寫法：為什麼一個拿到面試、一個石沉大海）
理解你被拒的真正原因。如果你曾經技術沒問題卻被拒，原因很可能不是「你不夠強」，而是「你用了錯誤的語言」。面試官的大腦在前 30 秒就會把你分類為 Worker 或 Architect 而這個分類幾乎完全取決於你說話的角度，不是你說話的內容。
（為什麼技術最強的人反而最容易被低估？這篇有結構性的解釋：為什麼解了 1000 個 Bug 的人，薪水反而最低？）
而在面試之前，還有一個更基本的問題：你的履歷有沒有通過 ATS 的第一關？如果連面試機會都沒拿到，準備再多故事也沒用。（你的履歷在外商 ATS 的第一秒發生了什麼事）
一個簡單的自我檢測
回想你最近一次面試（或模擬面試）。你花了多少時間準備演算法題，又花了多少時間準備你的「判斷力故事」？
如果比例是 80% 演算法、20% 故事 — 你正在把大部分時間花在 Google 自己承認「無法預測任何事情」的環節上。
翻轉這個比例。把 80% 的時間花在整理你的決策經歷、練習用商業語言描述它們。把 20% 留給演算法基本功。
這不是一個激進的建議。這只是把你的準備時間分配到數據告訴我們真正有效的地方。
參考資料
面試系統是有缺陷的——但你還是得通過它。關鍵是：把你的準備時間花在數據告訴我們真正有效的地方。如果你想看到完整的分析 : Hiring Manager 真正在評估的四個維度、工程語言和商業語言的具體差距、以及我們的 E2B 轉譯框架 — 我們把它寫成了一份完整報告。
免費下載《2026 科技菁英錯價報告》→
