Amazon 面試問題
作者 Aaron Cao · 更新於
Amazon 面試圍繞其16項領導力原則展開。幾乎每個問題都是行為題，以「講一件你……的經驗」這樣的形式提出，並要求以STAR架構、搭配具體數字來回答。技術類職缺還會加入寫程式和系統設計環節，這些環節同樣會在考核程式能力的同時考核領導力原則。
16項領導力原則到底在考核什麼？
你已經讀過領導力原則的清單，它聽起來大概像掛在牆上的標語。這一節要說明面試官實際上是怎麼運用它們的，這比措辭本身要具體得多。你面試流程裡的每位面試官都會被分配一組原則子集，並且必須帶著能證明你展現過這些原則的書面證據離開房間。
正是這種分配方式，讓同一輪面試可能顯得重複。一位面試官在挖掘Customer Obsession和Ownership，另一位在挖掘Dive Deep和Bias for Action，於是你會被要求就大致相似的領域講不同的故事。準備六到八個各不相同的故事，而不是只準備一個你最喜歡的，並且清楚每個故事能對應哪些原則。
- Customer Obsession。一個從客戶出發、而不是從路線圖出發做出的決定。
- Ownership。一件不在你職責範圍內、但因為它出了問題而被你主動接手的事。
- Dive Deep。一個你深入原始數據、並發現了摘要所掩蓋內容的問題。
- Have Backbone; Disagree and Commit。一次你據理力爭、最終沒有說服對方，卻仍然全力執行的經驗。
最常出現的行為面試問題有哪些？
措辭會因面試官而異，但題型在不同輪次和職級之間會反覆出現。
- 講一件你承擔了職責範圍之外的重要事情的經驗。
- 說說一次你與主管或同事意見不合的經驗。你當時是怎麼做的？
- 講一件你處理過的最複雜的問題。你是如何找到根本原因的？
- 舉一個你必須在數據不完整的情況下做決定的例子。
- 講一件你失敗或錯過截止日期的經驗。之後發生了什麼改變？
- 說說一次你在不損害品質的前提下簡化流程或削減成本的經驗。
比起問題本身，更要為追問做好準備。講完故事後，面試官會問你具體貢獻了什麼、前後的數字分別是多少、如果重來你會怎麼做，以及你的同事會怎麼評價這件事。一個經不起四輪追問的故事，聽起來就像是借來的。
怎樣建構一個經得起深挖的回答？
使用STAR架構，但要按 Amazon 的權重來分配：簡短的情境、一句話的任務，大部分時間用第一人稱講行動，再加上帶數字的結果。「我們改善了延遲」這種說法會失敗。「我透過加入讀穿透快取，把p99延遲從800ms降到210ms，並在Prime流量高峰期依然維持住了這個水準」這種說法才能過關。
設想一位正在面試資深職位的供應鏈分析師。她講了一個預測修復的故事，隨後被依序追問：她自己具體改動了模型的哪個部分、為什麼在兩種替代方案中選擇了這種做法、之前的錯誤率是多少，以及流量翻三倍時最先出問題的是什麼。她掌握這些數字，所以這個故事站得住腳。她的第二個故事沒有數字，面試官在一分鐘之內就轉向了別處。
把這些大聲練習出來，是大多數候選人會跳過的一步。你可以在/mock-interview頁面上，針對AI面試官練習應對追問的壓力，這正是書面故事和口頭講述之間差異顯現出來的地方。
即時助手在Amazon面試流程中扮演什麼角色？
在口頭視訊面試環節中，SubcueAI會轉錄面試官的問題，並在你這一側呈現一個建議的架構——可以是macOS和Windows上的桌面浮動視窗，也可以是Chromium瀏覽器擴充功能的側邊面板。沒有任何會議機器人加入通話，也沒有任何內容被注入到會議頁面中。對於行為面試環節，真正有用的輸出是提醒你哪一個自己的故事適合當下被追問的原則，而不是一份現成的腳本；數字仍然必須是你自己的。
有兩條誠實的限制。如果技術面試環節轉到了有螢幕監控或監考的寫程式平台上，即時協助就不在適用範圍內，你應該把那一輪當作只靠自己的能力應對。如果你被要求分享螢幕，那麼螢幕上的一切都會被看到。關於各大雇主如何安排面試流程的更多內容，見公司面試主題，各職缺專屬的題庫則收錄在題庫主題下。