行為面試模擬題庫

範圍 — 二十五道經典行為面試題，供模擬練習使用。每題都附上入門級（L3／應屆畢業生）的完整範例回答、面試官可能的追問，以及這個回答為什麼得分。評分標準、回答模式與故事庫的建立方法放在兩份公司指南裡；這份文件是練習題組。 另見：googleyness.md — Google 這一輪評什麼，以及「釐清 → 選項 → 決定 → 追蹤」的回答模式；amazon_leadership_principles.md — 每道題對應的十六條原則。

1. 如何進行一場模擬面試

1. 挑三到五題，從下方索引中選，並混合不同主題。真實的一輪面試會在 45 分鐘內問四到六題。
2. 請夥伴把題目唸出來，或自己唸完後開始計時。先不要看範例回答。
3. 用兩到三分鐘回答，講你自己的故事。超過三分鐘，代表情境講太長了。
4. 接受追問。 夥伴從該題的追問清單中挑兩題，並一直問「為什麼？」，直到故事講不出更多細節。
5. 評分，用下面的表格；然後再讀範例回答，記下一件它做到、而你沒做到的事。

重點 — 範例回答示範的是結構，不是要你背下來的故事。面試官會追問只有親身經歷才會知道的細節，所以借來的故事在第二個「為什麼？」就會垮掉。

2. 題目索引

3. 開場題

大多數面試以這幾題開場。它們不太針對某項特質評分，而是建立面試官的第一印象，並給他們可以追問的話題。

Q1. 請介紹你自己

考察 — Google：動機 · Amazon：不直接對應；它為後面的題目埋下話題

範例回答

我是資訊工程系大四學生。我做過的東西大多在後端：去年暑假我在一個支付團隊實習，把一份對帳報表從每晚批次改成每小時執行，讓財務等數字的時間從一天縮短到一小時。在那之前，我當了兩學期資料結構課的助教，在那裡學會用三種不同方式解釋同一個概念，直到對方聽懂為止。課外我參與一個開源的 Python linter，有六個 pull request 被合併，大多是新的規則和它們的測試。接下來我想找一個團隊，能做很多人依賴的系統，並且固定得到比我更強的工程師的 code review。

要演練的追問

• 對帳報表那次修改，最難的部分是什麼？
• 為什麼選後端而不是前端？
• 當助教讓你寫程式的方式有什麼改變？

為什麼得分 — 九十秒內講完，現在 → 過去 → 未來，每一句都是面試官可以接著追問的鉤子。講的是成果，不是職稱。

Q2. 為什麼想來這間公司？

考察 — Google：動機 · Amazon：Customer Obsession

範例回答

兩個理由，都和工作本身有關。第一是規模：實習時我最喜歡的問題，是那些因為要跑幾百萬次、所以小小的低效率也很重要的問題，而在這裡那是常態而不是例外。第二是我從外面看到的工程文化——設計文件、每個變更都有 code review，以及不究責地寫事故報告的習慣。我讀過去年一次儲存系統中斷的公開事後檢討，那是我第一次看到一個團隊把失敗解釋得那麼坦白。我想在職涯早期就在這樣的環境裡學習，而我習慣為自己的修改寫測試和文件，應該很適合這裡。

要演練的追問

• 你最想加入哪個團隊或產品？為什麼？
• 什麼情況會讓你一年後離開？
• 關於我們怎麼開發軟體，有什麼是你知道而大多數候選人不知道的？

為什麼得分 — 理由具體、和工作相關，並連結到候選人已經做過的事。完全沒提福利、名聲或品牌。

Q3. 請說說一個讓你自豪的專案

考察 — Google：動機 · Amazon：Deliver Results、Ownership

範例回答

Situation（情境） — 在作業系統課上，三人一組要做一個小型檔案系統。大多數組別通過測試就停了。

Task（任務） — 我負責區塊配置器和當機復原路徑，這是大多數組別略過的部分，因為測試幾乎沒涵蓋到。

Action（行動） — 我寫了一個測試工具，在寫入過程中的隨機時間點砍掉程序，再檢查磁碟映像是否一致。第一次執行時，200 次試驗中有 14 次映像損毀。我追查到原因是先寫 inode 再寫資料區塊，於是調換寫入順序，並為 metadata 加了一個簡單的日誌（journal）。每次修改後我都重跑測試工具，並在 README 裡維護一張失敗次數表，讓隊友看得到趨勢。

Result（結果） — 最終版本通過了全部 1,000 次試驗。教授把我們的測試工具當作下一屆課程的參考。我自豪是因為沒人要求我做：成績不取決於它，而且那是我第一次針對失敗而不是針對功能做測試。

要演練的追問

• 為什麼先寫 inode 會讓映像損毀？
• 現在重做的話，你會做什麼不同的事？
• 你和兩位隊友怎麼分工？

為什麼得分 — 展現了超越成績的當責、可量測的前後對比，以及面試官可以深挖的技術深度。候選人也說出為什麼自豪，那才是這題真正在問的。

4. 協作與衝突

Q4. 請說說你曾經和主管意見不合的經驗

考察 — Google：挑戰現狀 · Amazon：Have Backbone; Disagree and Commit

範例回答

Situation（情境） — 實習時，主管要我的專案（一個內部管理頁面）加一個 CSV 匯出按鈕，把資料表的每一列都拉出來。

Task（任務） — 這個功能由我開發，而我認為資料表變大後，拉出所有資料列會逾時。

Action（行動） — 我沒有空泛地爭論，而是去量測。我把一份正式環境資料的副本載入 staging，測量查詢時間：目前 200 萬列要 40 秒，而請求上限是 30 秒。我在一對一會議中帶著數字和兩個選項：分頁匯出，或用背景工作把檔案寄出。主管點出一件我沒想到的事——使用者只需要最近 30 天的資料。所以我們決定做依日期篩選的匯出，比我的兩個選項都簡單。

Result（結果） — 一週內上線，回應時間在兩秒以內。我學到在意見分歧時，要同時帶著資料和一個開放的問題；主管有我不知道的脈絡，最好的答案來自兩者的結合。

要演練的追問

• 如果主管說「照原樣上線」，你會怎麼做？
• 你怎麼提出來，又不讓它聽起來像是在拒絕？
• 有什麼是你判斷錯的嗎？

為什麼得分 — 異議有量測數據支持，提出時帶著選項而不是直接否決，而且候選人把更好的點子歸功於主管。這是有骨氣但不自負。

Q5. 請說說你曾經和難相處的人共事的經驗

考察 — Google：協作 · Amazon：Earn Trust

範例回答

Situation（情境） — 在一門為期一學期的軟體工程專題中，有位隊友會拒絕我們大多數人開的 pull request，常常只留一句「我不會這樣寫」。

Task（任務） — 我是開最多 pull request 的人，而我們的速度已經掉到一週只合併兩個變更。

Action（行動） — 我沒有在 review 討論串裡回覆，而是約他喝咖啡。原來他在之前的課上曾因為建置壞掉被責怪，很怕再發生一次。我提議把他在意的標準寫下來——每個新函式都要有測試、handler 不能直接呼叫資料庫——做成 repo 裡的一份簡短檢查清單，並加一個在每個 pull request 上跑測試的 CI 工作。我也請他在下一個功能和我結對程式設計，讓他看到我的工作方式。

Result（結果） — review 意見從「我不會這樣寫」變成對照清單的具體評論，下一週我們合併了九個變更。他成了我們最有幫助的審查者。我學到「難相處」的行為通常有原因，當面問清楚比在留言裡對抗快得多。

要演練的追問

• 如果喝咖啡沒用，你會怎麼做？
• 你有找老師或其他人介入嗎？
• 你自己的 pull request 需要改變什麼？

為什麼得分 — 候選人先找對方的理由，把個人摩擦轉成共同的流程，並交代了之後的關係。對方不是故事裡的反派。

Q6. 請說說你曾經遇到隊友沒有盡到本分的經驗

考察 — Google：協作 · Amazon：Ownership、Earn Trust

範例回答

Situation（情境） — 在一個為期四週、類似黑客松的課程專案中，我們四人裡有一位到第二週結束都還沒推過任何程式碼。

Task（任務） — 我負責協調看板，而他負責的通知服務卡住了我們的展示。

Action（行動） — 我私下傳訊息給他，而不是在站立會議上提出來。他說他每週要打工二十小時，低估了這個任務。我們重新分工：他保留電子郵件範本，可以用零碎時間完成；我接手需要長時間專注的佇列邏輯。我更新了看板讓團隊看到新的分工，但沒有向大家解釋他的個人狀況。我也把我們的進度確認改到晚上，配合他有空的時間。

Result（結果） — 服務在展示前三天完成，並由他上台展示。我學到在假設是不夠努力之前，先問是什麼擋住了對方，然後修正計畫而不是修理人。

要演練的追問

• 到什麼程度你會去找老師？
• 你多承擔工作，其他隊友有什麼感覺？
• 如果他完全沒回應，你會怎麼做？

為什麼得分 — 先私下再公開、具體的重新規劃、對隊友狀況保持謹慎，並且對結果負責而不是追究責任。

5. 失敗、錯誤與回饋

Q7. 請說說你曾經失敗的經驗

考察 — Google：回饋與成長 · Amazon：Learn and Be Curious、Earn Trust

範例回答

Situation（情境） — 大二時，我帶一個三人小組參加校內 app 競賽，做一個讀書會配對 app。

Task（任務） — 範圍和時程是我定的，所以計畫是我的。

Action（行動） — 我規劃了八個功能，結果八週中的前五週，我們把每個功能都做到一半。直到第六週，我都沒請任何一位學生試用過。等到我們終於測試時，五位受試學生只在乎一件事——找到同一個課程班級的人——而那個功能是完成度最低的。

Result（結果） — 我們沒有進前十名，評審的回饋和學生的一樣：做太多，沒有一個做完。我改變的是：之後的每個專案，我都在第二週結束前把東西放到使用者面前，並把範圍砍到他們會用的部分。實習時，我在第六天就把第一版管理頁面展示給兩位使用者，其中一則意見讓整個畫面從計畫中刪掉。

要演練的追問

• 為什麼沒有更早找使用者測試？
• 隊友對結果有什麼反應？
• 回頭看，你會砍掉什麼？

為什麼得分 — 真實的失敗、真實的代價，由候選人承擔而不是怪環境，還有之後的例子證明教訓有內化。它不是包裝過的優點。

Q8. 請說說一個影響到其他人的錯誤

考察 — Google：做對的事 · Amazon：Earn Trust、Ownership

範例回答

Situation（情境） — 實習時，我寫了一個資料庫 migration，新增一個帶預設值的欄位。

Task（任務） — 這個變更是我的，而且已經通過 code review。

Action（行動） — 它在 staging 執行時鎖住資料表四分鐘，另一個團隊的整合測試在那段時間內失敗了。我看到他們的頻道一片紅，發現時間和我的 migration 吻合。十分鐘內我就在他們的頻道發文：我跑了什麼、什麼時候跑的，以及這就是原因。我先回滾，再把它改寫成三個步驟——先新增不帶預設值的欄位、分批回填資料、最後才設定預設值——並請團隊的資料庫專家審查。我也在 migration 檢查清單裡加了一行，關於大型資料表上的預設值。

Result（結果） — 改寫後的 migration 在正式環境執行時沒有鎖表。另一個團隊感謝我在他們花時間除錯前就告訴他們。我學到快速承認錯誤，對所有人來說都比爭論是誰的錯成本更低。

要演練的追問

• 為什麼 code review 沒抓到？
• 在別的團隊頻道發文，你有什麼感覺？
• 檢查清單上那一行寫了什麼？

為什麼得分 — 快速而具體的揭露、修正加上防止重演的機制，而且沒有把責任推給核准的審查者。

Q9. 請說說你收過最嚴厲的回饋

考察 — Google：重視回饋 · Amazon：Earn Trust、Learn and Be Curious

範例回答

Situation（情境） — 實習進行到一半時，我的 mentor 說我的 pull request 很難審：平均大約 600 行，而且把重構和新行為混在一起。

Task（任務） — 我希望我的 review 能很快，而他每個都要花一小時。

Action（行動） — 我的第一個反應是這些修改本來就屬於一起，但我請他給我看一個他認為應該拆開的例子。從他的角度看，問題很明顯：他分不出哪幾行改變了行為。從那之後，我把每個變更拆成只做重構的 pull request 和改變行為的 pull request，每個都控制在大約 200 行以內。我也開始在每個描述的開頭寫兩行「請看這裡」的說明。

Result（結果） — 我的 review 週轉時間從大約兩天變成當天完成，實習結束時，mentor 說可審查性是我進步最多的地方。到現在每個專案我都還是把重構和行為變更分開。

要演練的追問

• 老實說，你的第一個反應是什麼？
• 你有收過你不同意的回饋嗎？
• 你現在怎麼請別人給你回饋？

為什麼得分 — 回饋具體而且有點刺痛，候選人承認自己的第一反應，改變具體且有量測。最後以這個習慣仍在使用作結。

Q10. 請說說你曾經錯過期限的經驗

考察 — Google：做對的事 · Amazon：Deliver Results、Earn Trust

範例回答

Situation（情境） — 實習時，我有兩週時間為一個內部文件工具加入搜尋功能。

Task（任務） — 估計是我做的，而且我說過兩週很充裕。

Action（行動） — 第一週結束時，我知道需要三週：搜尋函式庫不支援這個工具的存取控制，所以我得自己過濾結果。我當天就告訴主管，而不是等到期限，並附上原因和兩個選項——兩週內上線不含受限頁面的搜尋，或三週內上線完整搜尋。我們選了第一個，讓使用者準時拿到大部分的價值。我把受限頁面的部分開成後續工作，並在第三週完成。

Result（結果） — 搜尋在原定日期上線，涵蓋 90% 的頁面，其餘一週後補上。我沒達成自己的估計，但沒有人因此感到意外。從那之後，我會在進行到一半時用實際狀況檢查估計，一旦有變動就當天說出來。

要演練的追問

• 為什麼估計會錯？
• 主管有什麼反應？
• 你現在怎麼做才能估得更準？

為什麼得分 — 及早預警、提出選項而不是藉口、部分交付仍服務了使用者，而且改變了習慣。候選人承擔了估計的責任。

6. 模糊情境與決策

Q11. 請說說你曾經遇到需求不明確的經驗

考察 — Google：在模糊中前進 · Amazon：Bias for Action、Customer Obsession

範例回答

Situation（情境） — 擔任助教時，教授請我「做個東西幫學生練習遞迴」。

Task（任務） — 需求就只有這樣，而距離遞迴單元開始還有三週。

Action（行動） — 我寫下三件我不知道的事：誰在苦戰、他們卡在哪裡、他們會用什麼形式。前兩件用我手上已有的資料回答——去年的考試成績顯示終止條件（base case）的題目最弱。第三件我在 office hours 問了五位學生，其中四位說想要有即時回饋的短練習，而不是影片。所以我先做最小的版本：十題自動批改的終止條件練習，一週後就寄給教授確認方向，再繼續做更多。

Result（結果） — 教授把這組練習加進課程，我把它擴充到 30 題。期中考終止條件題的答對率從 58% 升到 71%。我學到把一個模糊的請求轉成一張未知清單，並先解決最重要的那一項。

要演練的追問

• 為什麼一週後就確認，而不是三週後？
• 如果教授不喜歡這個方向，你會怎麼做？
• 你怎麼知道進步是這些練習造成的？

為什麼得分 — 點出未知、用資料和使用者降低不確定性、先交付小版本，並及早確認。最後一個追問考驗你對因果關係是否誠實，要先準備好。

Q12. 請說說你在資料不足時做出的決定

考察 — Google：崇尚行動 · Amazon：Are Right, A Lot、Bias for Action

範例回答

Situation（情境） — 一次週末黑客松，進行到第六小時，我們得為原型在託管資料庫和本機資料庫之間做選擇。

Task（任務） — 後端是我負責的，所以由我決定，而我們只剩 18 小時。

Action（行動） — 我不知道託管服務的免費方案在展示時撐不撐得住，也沒時間做負載測試。我問自己：哪個選擇比較容易反悔？本機儲存之後可以透過一個介面換成託管服務；反過來則要重寫查詢。所以我選擇本機儲存並包在一層薄介面後面，並把假設告訴團隊：只有展示需要多台裝置時才切換。

Result（結果） — 展示在一台筆電上執行，從來不需要切換，我們省下大約三小時的設定時間，投入到評審稱讚的那個功能上。現在只要資料不足、時間又緊，我都會問「哪個選擇最容易反悔？」

要演練的追問

• 什麼情況會讓你選擇託管服務？
• 什麼時候等更多資料才是對的選擇？
• 你怎麼溝通這個假設？

為什麼得分 — 用有理據的框架（可逆性）而不是猜測、把假設說出來，而且結果和決定有直接關聯。

Q13. 請說說你曾經面對互相衝突的優先順序的經驗

考察 — Google：在模糊中前進 · Amazon：Deliver Results

範例回答

Situation（情境） — 實習的最後一個月，主管要我完成主要專案，而另一個團隊的負責人請我幫他們修一個 bug，出在我先前改過的函式庫裡。

Task（任務） — 兩個請求都合理，而我無法在同一週把兩件事都做完整。

Action（行動） — 我不想默默地自己選，所以寫下每個請求需要什麼和它的期限。另一個團隊的 bug 會在四天後卡住他們的發布；我的專案三週後到期。我估計那個 bug 要一天。我把兩件事都帶去找主管，提議先花一天修 bug，再回到我的專案，並問他是否有不同看法。他同意了，並親自告知另一位負責人。

Result（結果） — bug 修正花了一天半上線，他們的發布準時出去；我的專案在實習結束前兩天完成。我學到要把取捨攤給擁有優先順序決定權的人看，而不是自己一個人決定。

要演練的追問

• 如果主管說不行呢？
• 沒有人可以問的時候，你怎麼排優先順序？
• 多出來的半天讓你付出了什麼代價？

為什麼得分 — 標準清楚（緊急程度、成本）、提出提案而不是丟出沒有答案的問題，並由對的人做決定。候選人也承認估計多了半天。

Q14. 請說說你曾經必須快速學會某件事的經驗

考察 — Google：回饋與成長 · Amazon：Learn and Be Curious

範例回答

Situation（情境） — 實習第二天，我被要求修一個用 Go 寫的服務裡的慢頁面。我從沒寫過 Go。

Task（任務） — 預期一週內完成修正。

Action（行動） — 我沒有試圖先學完整個語言。我花一個晚上讀官方教學，只讀到 goroutine 為止。接著我把那個頁面在服務中的程式路徑從頭讀到尾，把每個不熟悉的寫法記成一個問題。我把問題集中起來，用一次十五分鐘的時間請教 mentor，而不是整天打擾他。結果慢的原因是一個迴圈對每個項目都呼叫一次資料庫，所以我把它改寫成一次批次查詢，並加了一個效能基準測試。

Result（結果） — 頁面從 3.2 秒降到 0.4 秒，修正在第五天上線。實習後期學 Terraform 時，我也用同樣的方法——只學夠用的、讀真實的程式碼、把問題集中起來問。

要演練的追問

• 你怎麼判斷學到什麼程度算「夠用」？
• 你一開始弄錯了什麼？
• 哪個 Go 慣用寫法最讓你意外？

為什麼得分 — 有意識的學習策略、尊重 mentor 的時間、有量測的結果，以及這個方法可以轉移的證據。

7. 當責與成果

Q15. 請說說你曾經承擔職責以外工作的經驗

考察 — Google：自發型領導 · Amazon：Ownership

範例回答

Situation（情境） — 實習期間，新來的實習生頭兩天大多花在讓開發環境能建置成功；設定指南已經過時一年了。

Task（任務） — 這份指南沒有人負責。我剛走過一遍，所以知道每一個壞掉的步驟。

Action（行動） — 因為這不是我的專案，我先問主管能不能花一天處理。我根據自己的筆記重寫指南，用一個設定腳本取代六個手動步驟，並請下週加入的兩位實習生照著做，我在旁邊看但不幫忙。兩人都卡在同一個步驟，我把它修好。接著我把腳本加進 CI，讓設定一旦壞掉就會失敗，並找到一位正職工程師同意在我離開後接手。

Result（結果） — 下一梯實習生的設定時間從大約兩天降到兩小時以內。交接和腳本一樣重要：這份指南到現在還有人維護。

要演練的追問

• 為什麼要先徵求同意？
• 你怎麼找到接手的人？
• 有什麼是你沒做到的？

為什麼得分 — 看到缺口，在主管支持下行動，用真實使用者測試，用 CI 守住成果，然後交接出去。當責也包含交接。

Q16. 請說說你追查過最難的 bug

考察 — Google：崇尚行動 · Amazon：Dive Deep

範例回答

Situation（情境） — 在我參與的開源 linter 中，有位使用者回報某條規則在他們的程式碼庫裡大約每 50 個檔案就會當掉一次，但他們不能分享程式碼。

Task（任務） — 那條規則是我寫的，所以我接下了這個 issue。

Action（行動） — 我在我們所有的測試檔案上都重現不出來。我請使用者用除錯旗標執行 linter，只傳堆疊追蹤給我，結果指向這條規則處理 decorator 的部分。我寫了一個小型 fuzzer，隨機產生帶 decorator 的函式並逐一執行規則；十分鐘內就找到一個當機案例：decorator 本身是一個帶關鍵字參數的呼叫。我的程式碼假設每個 decorator 都是一個名稱。我修好它，把 fuzzer 找到的失敗案例加成回歸測試，並對修正版跑了一小時的 fuzzer。

Result（結果） — 使用者確認他們所有檔案都不再當掉。維護者把這個 fuzzer 用在另外兩條規則上，又找到一個 bug。我學到看不到輸入時，可以自己產生輸入。

要演練的追問

• 在用 fuzzer 之前你試過什麼？
• 沒有對方的程式碼，你怎麼讓使用者持續配合？
• 為什麼原本的測試沒抓到？

為什麼得分 — 從症狀到根因有條理的路徑、在真實限制下有創意的技巧、回歸測試，以及超出這一個 bug 的影響。

Q17. 請說說你曾經在緊迫期限下交付的經驗

考察 — Google：崇尚行動 · Amazon：Deliver Results、Bias for Action

範例回答

Situation（情境） — 畢業專題要向外部贊助者展示的前兩天，我們使用的第三方地圖 API 更改了免費方案，我們的地圖載入不出來。

Task（任務） — 前端是我負責的，而地圖是展示的核心。

Action（行動） — 我列出贊助者真正需要看到的東西：三個地點之間的路線，而不是一個完全互動的地圖。這讓問題少了一半。我花兩小時用我們的資料測試兩個開源地圖函式庫，選了能正確畫出路線的那個，並告訴團隊我會在隔天晚上前讓地圖能運作，額外功能——搜尋、縮放預設值——則看時間允許。我先完成核心路徑，再在展示當天早上和團隊做一次完整彩排。

Result（結果） — 展示用新地圖順利進行；搜尋功能沒趕上，我們也照實說了。贊助者決定再合作一學期。我學到在延長工時之前，先砍到觀眾需要的部分。

要演練的追問

• 你怎麼決定要砍什麼？
• 用新的函式庫你承擔了什麼風險？
• 團隊怎麼分配剩下的工作？

為什麼得分 — 依使用者需求砍範圍、限時評估、誠實的承諾，並坦白說出沒上線的部分。

Q18. 請說說你曾經不接受「夠好就好」的經驗

考察 — Google：做對的事 · Amazon：Insist on the Highest Standards

範例回答

Situation（情境） — 實習時，我完成了一個功能，通過所有測試和審查，但我注意到我們的測試只涵蓋它所用的貨幣轉換的正常路徑。

Task（任務） — 依團隊的定義，這個功能已經完成，而我還有另一個任務在等。

Action（行動） — 我花了半天寫邊界情況的測試：零金額、負數退款，以及沒有輔幣單位的貨幣，例如日圓。日圓的測試失敗了：我們對每種貨幣都乘以 100，所以一筆 ¥1,000 的退款會被記成 ¥100,000。我修正轉換邏輯，改從一張表讀取每種貨幣的輔幣位數，並告訴主管另一個任務為什麼會晚半天。

Result（結果） — 修正在功能開放給日本使用者之前上線。主管請我把邊界情況清單整理成範本，供其他處理金額的程式使用。我給自己的標準是：測試應該試圖弄壞程式，而不只是確認它能動。

要演練的追問

• 你怎麼判斷額外的測試值不值得花時間？
• 什麼時候你接受了「夠好就好」，而且是對的？
• 審查者有什麼反應？

為什麼得分 — 具體地把標準拉高到團隊的完成定義之上、找到代價明確的真實缺陷，並產出可重用的成果。要準備第二個追問：高標準也包括知道什麼時候該停。

Q19. 請說說你曾經簡化流程的經驗

考察 — Google：挑戰現狀 · Amazon：Invent and Simplify、Frugality

範例回答

Situation（情境） — 擔任助教時，批改 120 位學生的程式作業，四位助教每週要花大約 12 小時，大多是手動執行每一份作業。

Task（任務） — 沒有人要我改變它，但我就是花那些時間的四個人之一。

Action（行動） — 我向助教長提議做一個自動批改工具，先在單一作業上試行一週，這樣就算失敗代價也很小。我寫了一個腳本，在容器裡用我們的測試案例執行每份作業並產生分數表，同時保留一個手動步驟處理程式風格和評語，因為那是測試判斷不了的。我把第一次的輸出給其他助教看，問他們缺什麼；他們希望附上失敗測試的輸入，讓學生知道為什麼錯。

Result（結果） — 我們四人每週的批改時間降到大約 4 小時，學生拿到成績的時間從七天變成兩天。之後每學期這門課都使用這個自動批改工具。我學到提議改變時，要以低成本的試行提出，而不是一次大轉換。

要演練的追問

• 你刻意保留了哪些手動步驟？
• 你怎麼說服助教長？
• 試行時出了什麼問題？

為什麼得分 — 它減少工作而不是增加流程，從低成本、可逆的試行開始，在重要的地方保留人的判斷，並量化了節省的時間。

8. 使用者與誠信

Q20. 請說說你曾經為使用者多做一步的經驗

考察 — Google：使用者優先 · Amazon：Customer Obsession

範例回答

Situation（情境） — 在學校圖書館做 IT 支援的打工時，好幾位學生抱怨在手機和筆電之間切換時，研究室預約網站會把他們登出。

Task（任務） — 我的工作是登錄工單和重設密碼，不是修預約網站。

Action（行動） — 我注意到抱怨集中在考試週，那時大家會用好幾台裝置預約。我用一份共享試算表追蹤了兩週——31 張工單——發現它們全都來自在幾分鐘內用兩台裝置預約的使用者。我把這些寫成報告給圖書館的開發者，附上重現步驟和試算表；同時在預約頁面上加了一則簡短說明，請學生在同一台裝置上完成預約。

Result（結果） — 開發者找到 session 衝突，在下一個考試期之前修好；相關工單降到零。我學到只要有人把支援工單當成整體來讀，它就是使用者研究。

要演練的追問

• 你怎麼引起開發者的注意？
• 為什麼先加臨時說明，而不是等修正？
• 如果開發者拒絕，你會怎麼做？

為什麼得分 — 說得出使用者是誰，用候選人手上已有的資料量化問題，現在給使用者權宜之計、之後有正式修正，而且超出職責但沒有越權。

Q21. 請說說你曾經必須在準時上線和把事做對之間抉擇的經驗

考察 — Google：做對的事 · Amazon：Insist on the Highest Standards、Earn Trust

範例回答

Situation（情境） — 一個內部工具上線的前一天，我發現只要拿掉某個查詢參數，它的匯出端點就會回傳所有團隊的資料，而不只是使用者自己團隊的。

Task（任務） — 那個端點不是我寫的，也沒有其他人注意到，而上線消息已經公告給 200 位使用者。

Action（行動） — 我重現了兩次確認無誤，然後在一小時內同時告訴主管和端點的作者，附上能顯示資料外洩的確切請求。我沒有把它貼到公開頻道。我提出兩個選項：延後一天上線，或上線時先停用匯出按鈕。作者當天下午就修好了權限檢查，我寫了一個不帶該參數發送請求的測試。我們先停用匯出上線，隔天早上測試通過後再開啟。

Result（結果） — 工具準時上線，沒有任何資料外洩。主管請我把這個測試加進團隊每個新端點的審查清單。我學到安靜而快速地提出問題、並帶著解法，能讓大家很容易做對的事。

要演練的追問

• 為什麼不自己修？
• 為什麼不告訴整個團隊？
• 如果主管說照原樣上線呢？

為什麼得分 — 及早向對的人提出令人不舒服的事實，附上重現方式和選項。結果同時保護了使用者和上線時程，候選人也把修正歸功於作者。

9. 領導與培養他人

Q22. 請說說你曾經在不是負責人的情況下帶領團隊的經驗

考察 — Google：自發型領導 · Amazon：Earn Trust、Ownership

範例回答

Situation（情境） — 我們五人的畢業專題小組有一位名義上的組長，技術很強但很少主持會議；三週後我們還沒有共同的計畫，兩個人做出了重複的登入頁面。

Task（任務） — 我不是組長，也不想削弱他的角色。

Action（行動） — 我先找他談，提議由我主持一場規劃會議，由他報告架構。他同意了。會議中我請每個人列出自己正在做的事，放到同一個看板上，結果找到重複的部分，以及兩個沒有人負責的功能。我建議每週兩次、每次十五分鐘的站立會議，自願主持前兩次，之後輪流主持。

Result（結果） — 我們砍掉重複的工作，在期限前一週完成所有規劃的功能，第一個月之後組長就自己主持站立會議了。我學到沒有職權的領導，往往是把舞台讓給別人，同時補上他們留下的空缺。

要演練的追問

• 為什麼先去找組長？
• 有人抗拒站立會議時你怎麼做？
• 如果組長拒絕，你會怎麼做？

為什麼得分 — 領導是補上缺口，在正式負責人的支持下進行而不是繞過他，最後再交還出去。這正是 L3 標準要求的自發型領導訊號。

Q23. 請說說你曾經幫助別人成功的經驗

考察 — Google：自發型領導、協作 · Amazon：Hire and Develop the Best

範例回答

Situation（情境） — 實習時，一位新實習生在我之後三週加入，被分派到一個 bug，出在我剛學會的那部分程式碼。

Task（任務） — 我不是她的 mentor，但我熟悉那段程式碼，而她的 mentor 那週在休假。

Action（行動） — 她報到第一天下午，我主動撥出一小時。我沒有直接告訴她怎麼修，而是帶她走一遍我會怎麼找：log 在哪裡、怎麼在本機執行服務、我怎麼追蹤請求的路徑。然後我讓她自己操作、我在旁邊看，只有在她卡住超過十分鐘時才介入。我也分享了我為自己寫的程式碼筆記。

Result（結果） — 她兩天內自己修好了 bug，並在那週開出她的第一個 pull request。兩週後，她用同一份筆記回答下一位實習生的問題。我學到教人怎麼找答案，比直接給答案影響得更遠。

要演練的追問

• 你怎麼和自己的工作取得平衡？
• 當對方只想要答案、不想要方法時，你怎麼做？
• 你怎麼知道是你的幫忙造成了差別？

為什麼得分 — 沒人要求就主動幫忙、有意識的教學方式，以及幫助產生倍增效果的證據。功勞留給真正做事的人。

10. 假設情境題

Google 比 Amazon 更常問這類題目。使用 Google 指南中的模式：釐清、選項、決定、追蹤——如果有真實故事，最後再用它來佐證。

Q24. 如果主管要你上線一個你認為還沒準備好的東西，你會怎麼做？

考察 — Google：做對的事 · Amazon：Have Backbone; Disagree and Commit

範例回答

Clarify（釐清） — 我會先問在這個情況下「還沒準備好」是什麼意思，因為答案會因此不同。它是對使用者的風險——資料遺失、資安、核心流程壞掉——還是品質上的落差，例如細節不夠精緻或測試覆蓋不足？還有，推動這個日期的是什麼：對客戶的承諾，還是內部目標？

Options（選項） — 如果是對使用者的風險，我會帶著證據直說，並提出能安全趕上日期的做法：用 feature flag 先開放給一小群人、砍掉有風險的部分，或延後幾天。如果是品質落差，我會記錄下來，開好後續工作並指派負責人，然後上線。

Decide（決定） — 決定權在主管，但他們應該在掌握事實的情況下做決定。我會用兩三句話把風險寫下來，目的是讓事情清楚，而不是保護自己。

Follow through（追蹤） — 如果我們上線，我就全力投入：上線後盯著指標和錯誤，並第一個回應。實習時我曾在上線前一天提出一個資料外洩的 bug；我們停用匯出功能準時上線，隔天再開啟。

要演練的追問

• 如果主管還是說要上線，而你認為使用者會受到傷害呢？
• 你怎麼表達反對又不傷害關係？
• 什麼時候你會越過主管往上呈報？

為什麼得分 — 它把風險和個人偏好分開，提出尊重日期的選項，決定後全力投入，最後以真實故事作結。要準備第一個追問：你會在哪裡劃下往上呈報的界線，也是答案的一部分。

Q25. 如果兩位資深工程師給你互相衝突的指示，你會怎麼做？

考察 — Google：在模糊中前進、協作 · Amazon：Earn Trust

範例回答

Clarify（釐清） — 我會先確認自己正確理解了兩人的意思，因為衝突常常出在我的轉述，而不是他們的本意。我也會問誰擁有這個決定權——技術主管、我的主管，還是他們其中一位。

Options（選項） — 我可以自己挑一個方向、分別回去找兩人，或把兩種觀點並列、請他們一起決定。自己挑一個有之後白做的風險；分別去找往往只會重演衝突。

Decide（決定） — 我會寫一份簡短的說明，列出兩種做法、我理解的各自取捨，以及我傾向哪一個和原因，在同一個討論串裡寄給兩人，並副本給有決定權的人。這讓分歧變成關於做法本身，而不是我聽哪位資深工程師的。

Follow through（追蹤） — 在他們決定的期間，我會先做兩種做法共通的部分，這樣我不會被卡住。決定之後，我會把它記在設計文件裡，避免再被翻案。實習時我遇過類似的情況，是關於命名慣例，一份五行的比較在一則回覆內就解決了。

要演練的追問

• 如果他們還是無法達成共識呢？
• 如果有決定權的人選了你認為比較差的選項呢？
• 你怎麼避免看起來像在選邊站？

為什麼得分 — 它把衝突當成資訊問題處理，把它交給決策者，等待期間候選人保持產出，並把決定記錄下來。

11. 模擬面試之後

• 數一數「我們」。 任何一個「我們」比「我」多的回答，都要重寫行動那一段。
• 找出數字。 每個結果都應該有一個：節省的時間、錯誤率、使用者數、成績、天數。
• 檢查教訓。 每個故事都應該以你改變了什麼、以及之後某次用上它作結。
• 對應你的故事。 回答完全部 25 題後，你總共應該用了六到十個故事。如果一個故事回答了超過四題，面試會察覺；如果有題目沒有故事可講，那就是要補的缺口。
• 一週後重練表現弱的題目，換一位夥伴，因為熟悉的聽眾會不再問難的追問。