Googleyness 與領導力面試
範圍 — Google 的行為面試輪：評分什麼、面試官如何解讀回答、依每題所考察的特質分組的經典題目，以及「請說說你曾經…」與「如果…你會怎麼做」兩類題目的回答模式。 另見：amazon_leadership_principles.md — Amazon 的面試流程，用十六條具名原則問同樣的故事；mock_question_bank.md — 二十五道附範例回答的經典題目，供模擬練習使用。
1. 這一輪的概況
| 名稱 | Googleyness & Leadership（G&L），有時直接叫「行為面試輪」 |
| 長度 | 45 分鐘，通常是現場面試（onsite）中的一輪 |
| 題型 | 過往行為題（「請說說你曾經…」）以及假設情境題（「如果…你會怎麼做」） |
| 面試官 | 受過 G&L 評分標準訓練的 Google 工程師或主管，不一定來自你未來的團隊 |
| 結果去向 | 書面回饋與評分會放進你的面試資料包（packet）；沒見過你的招聘委員會會把它和你的程式面試輪放在一起看 |
Google 對每位候選人評估四項特質：一般認知能力（general cognitive ability）、職務相關知識（role-related knowledge）、領導力（leadership）與 Googleyness。程式面試輪負責前兩項，這一輪負責後兩項，而且是唯一以這兩項為主題的一輪。
對 L3（入門級）而言，標準不是「帶過團隊」，而是自發型領導（emergent leadership）：你看到有事需要做，沒人要求就主動承擔，帶著別人一起前進，並在別人更適合時退一步。課堂專案、實習、開源修正或社團經驗都算數。
2. 面試官在評什麼
Google 沒有公布一份固定清單，但面試官與招募人員描述的特質相當一致。這一輪的每道題都針對其中一到兩項。
| 特質 | 意思 | 強訊號 | 警訊 |
|---|---|---|---|
| 在模糊中前進 | 問題、負責人或需求不清楚時，你仍能推進 | 你點出未知數，選定降低不確定性的方法，然後行動 | 等別人告訴你，或沒確認就衝 |
| 崇尚行動 | 依合理的計畫行動，而不是等待完美計畫 | 先跨出小而可逆的一步，再迭代 | 只分析不決定，或押一個不可逆的大賭注 |
| 協作 | 讓身邊的人更有效率 | 你歸功他人、分享脈絡、替隊友排除障礙 | 團隊的成果說成「我」，或什麼都說「我們」 |
| 重視回饋 | 主動尋求回饋，不帶防衛地接受，並做出改變 | 一則具體回饋，以及你之後做了什麼不同的事 | 「我其實沒收到什麼負面回饋」 |
| 挑戰現狀 | 尊重且有憑有據地質疑做事方式 | 你提出改變、用資料說服別人，並且傾聽 | 只抱怨不提案，或強壓別人 |
| 使用者優先 | 決策能追溯到使用者的需求 | 你說得出使用者是誰，結果如何幫到他們 | 為技術而技術 |
| 做對的事 | 在有代價時仍保持誠信 | 你及早提出令人不舒服的問題 | 隱瞞錯誤，或怪罪別人 |
| 自發型領導 | 需要時，在沒有職權的情況下領導 | 你組織、決策或指導，然後讓別人接手負責 | 等待頭銜，或非得當主導者 |
重點 — 每項特質都依你做了什麼來評分，而不是你相信什麼。「我重視回饋」得不到分數；「審查者說我的 PR 太大，所以我把下一個拆成四個」才能證明這項特質。
3. 回答模式
過往行為題：STAR
使用 STAR——Situation（情境）、Task（任務）、Action（行動）、Result（結果）——把時間花在會得分的地方。
| 部分 | 佔回答的比例 | 要說什麼 |
|---|---|---|
| Situation（情境） | 約 15% | 一兩句話：團隊、專案、利害關係 |
| Task（任務） | 約 10% | 你負責什麼，難在哪裡 |
| Action（行動） | 約 55% | 你採取的步驟、權衡過的選項、為什麼選其中一個 |
| Result（結果） | 約 20% | 結果（有數字就給數字），以及你學到什麼 |
- 第一輪回答控制在 2–3 分鐘。面試官會追問，留空間給他們。
- 自己的行動說**「我」，團隊的行動說「我們」**。面試官評的是你，不是團隊。
- 以學到的教訓以及之後如何應用它作結。反思本身就是訊號的一部分。
假設情境題：釐清、選項、決定、追蹤
Google 比 Amazon 更常問「如果…你會怎麼做」。不要直接跳到答案：
- 釐清 — 針對情境問一兩個問題（有多緊急、影響到誰、試過什麼）。
- 選項 — 說出兩三種處理方式，以及各自的取捨。
- 決定 — 根據已知資訊選一個，並說明理由。
- 追蹤 — 你會如何確認它有效，以及無效時怎麼辦。
接著，如果有的話，用經驗佐證：「我遇過類似的情況，當時…」。真實的故事永遠勝過假設性的回答。
4. 面試官的視角
- 他們會幾乎逐字記下你說的話。 招聘委員會讀的是筆記，不是對你個人魅力的總結。具體細節會留下來，形容詞不會。
- 他們會追問，找出你的貢獻。 預期會聽到「你做了什麼？」「為什麼選那個方案？」「重來一次你會怎麼做？」「對方的反應如何？」。一個在第二個「為什麼」就崩解的故事，得分會低於一個規模較小但站得住腳的故事。
- 他們會把每個回答對應到一項特質。 如果回答中沒有任何可評分的特質，他們會再問一題，而這一輪的時間就會不夠用。
- 他們在找自我覺察。 一次你承認並從中學習的失敗，比一連串的成功更有說服力。
- 他們不是在評規模大小。 一個行動清楚、反思誠實的學校專案，勝過一個你的角色模糊不清的產品上線故事。
實務上區分各評分等級的關鍵：
| 評分 | 筆記通常呈現 |
|---|---|
| Strong hire / hire（強烈錄取／錄取） | 具體的行動、清楚的取捨、可衡量的結果，以及之後實際應用的教訓 |
| Leaning hire（傾向錄取） | 直覺不錯，但行動描述單薄，或結果只是「進行得很順利」 |
| Leaning no hire（傾向不錄取） | 大多是「我們」、用假設回答過往行為題，或缺乏反思 |
| No hire（不錄取） | 怪罪他人、輕視回饋，或故事在追問下自相矛盾 |
5. 依特質分類的經典題目
模糊情境與崇尚行動
- 請說說你曾經在需求不明確的情況下推進工作的經驗。
- 請說說你在資訊不完整時做出的一個決定。
- 如果你接到一個專案，卻沒有人能告訴你成功的樣子，你會怎麼做？
他們想知道 — 你是否會自己降低不確定性（找對的人問、做原型、寫下假設），還是等它自行消失。
回答模式 — 說出未知數、你如何降低其中最重要的一個、你跨出的第一個小步驟，以及得知更多資訊後你如何調整。
協作與衝突
- 請說說你曾經和隊友意見不合的經驗。你們如何解決？
- 請說說你曾經和難以共事的人合作的經驗。
- 如果有位隊友一再錯過共同期限中屬於他的部分，你會怎麼做？
他們想知道 — 你能否就事論事地反對，而不損害彼此的關係，以及你是否先了解對方的理由，再提出自己的。
回答模式 — 公平地陳述雙方立場，說明你如何理解對方的立場、如何做決定（資料、快速測試、決勝標準），以及事後關係如何。避免選擇「對方就是錯了」的故事。
回饋與成長
- 請說說你收過最有用的回饋。
- 請說說你曾經失敗的經驗。你學到了什麼？
- 請說說你曾經必須快速學會新東西的經驗。
他們想知道 — 你能否聽進批評、承認錯誤，並因此改變行為。
回答模式 — 一次有真實代價的真實失敗、你做錯了什麼（不是環境因素）、你改變了什麼，以及後來這個改變發揮作用的例子。不要選偽裝成缺點的優點（「我太努力工作」）。
挑戰現狀
- 請說說你曾經主動改善一個沒人要求你改的流程。
- 請說說你曾經反對某個決定的經驗。
- 如果你認為團隊的做法是錯的，但團隊負責人不同意，你會怎麼做？
他們想知道 — 你是否帶著證據與提案而來，以及當決定與你的意見相反時，你能否全力投入。
回答模式 — 你注意到的問題、蒐集的資料、如何說服別人、拉了誰一起，以及結果。如果你沒說服成功，說明你仍如何全力投入。
使用者優先與做對的事
- 請說說你曾經依據使用者需求做出決定的經驗。
- 請說說你曾經必須在準時上線與把事情做對之間做選擇的經驗。
- 如果你發現一個會延後上線、但其他人都沒注意到的 bug，你會怎麼做？
他們想知道 — 你能否說出使用者是誰，以及你是否會及早提出令人不舒服的事實，而不是期望沒人發現。
回答模式 — 使用者是誰、他們需要什麼、你面對的取捨、你在何時告訴了誰，以及結果如何服務了使用者。
沒有職權的領導
- 請說說你曾經在不是正式負責人的情況下帶領專案或團隊的經驗。
- 請說說你曾經幫助隊友成長的經驗。
- 請說說你曾經必須讓團隊以外的人去做某件事的經驗。
他們想知道 — 你能否為他人帶來清晰的方向與動能，並把功勞分給別人。
回答模式 — 缺少的是什麼（方向、決定、計畫）、你如何補上、如何取得共識而非下命令，以及最後其他人負責了哪些部分。
動機
- 為什麼想來 Google？
- 請說說一個讓你自豪的專案。
- 你第一年想做什麼？
他們想知道 — 你的理由是否具體、是否關於工作本身，而非品牌。
回答模式 — 一兩個具體理由，連結到某個產品、某個問題或某種工作方式，並與你已經做過的事相呼應。
6. 完整範例
題目 — 「請說說你曾經和隊友意見不合的經驗。」
Situation（情境） — 在大四的畢業專題中，我們四個人在做一個排課網頁應用程式。展示前兩週，負責後端的隊友想用一套新的 ORM 重寫資料層。
Task（任務） — 我負責 API 和展示計畫，所以如果重寫延誤，展示就會失敗。
Action（行動） — 我先請他說明原因。他的理由是成立的：我們手寫的 SQL 那週造成了兩個 bug。我提議先做一個限時的技術驗證（spike）：他花一天移植一個端點，我列出完整重寫會動到的所有端點。驗證成功了，但也顯示需要修改十一個端點。我們同意展示時保留舊的資料層，用測試修好那兩個容易出錯的查詢，並把重寫排在展示之後。我把這個決定寫進專案文件，讓其他隊友知道原因。
Result（結果） — 我們準時展示，沒有任何資料相關的 bug，而他在下個月主導了重寫。我學到在反駁一個提案之前，要先問清楚提案背後的理由；現在只要意見分歧是源於未知，我都會建議先做限時的技術驗證。
為什麼這個回答得分：對雙方立場都公平、行動具體且確實是候選人自己的、決定有證據支持、結果具體，而且教訓有明確說出並再次應用。
7. 建立故事庫
準備六到八個故事，每個都用 STAR 講述，並把每個故事對應到它能展現的特質。好故事大多能涵蓋兩三項特質，所以一個小小的故事庫就足以應付整輪面試。
| 故事類型 | 通常涵蓋的特質 |
|---|---|
| 一個目標不明確、但你推動前進的專案 | 模糊情境、崇尚行動、領導力 |
| 一次你化解的意見分歧 | 協作、挑戰現狀 |
| 一次你承擔的失敗或錯誤 | 回饋與成長、做對的事 |
| 一則改變你工作方式的回饋 | 回饋與成長 |
| 一個你主動改善的流程或工具 | 挑戰現狀、崇尚行動 |
| 一個為使用者做出的決定 | 使用者優先 |
| 一次你幫助別人成功的經驗 | 協作、領導力 |
| 一個需要取捨的緊迫期限 | 崇尚行動、做對的事 |
- 使用最近兩三年的故事，細節比較容易回想。
- 每個故事都先寫下來，再計時大聲講一遍。刪減情境的部分，直到行動成為最長的一段。
- 為每個故事準備好追問的答案：重來一次你會怎麼做、對方怎麼想、數字是多少。
8. 面試前檢查清單
- 六到八個故事，每個都對應到兩三項特質。
- 每個結果都有數字或具體成果，每個故事都有教訓。
- 至少一次真實的失敗，以及一次真實的意見分歧。
- 準備好假設情境題的回答模式：釐清、選項、決定、追蹤。
- 對「為什麼想來 Google？」有具體的答案。
- 準備兩個問面試官的問題，關於他們團隊如何運作，而不是福利。