Amazon 面試有多難？
作者 Aaron Cao · 更新於
難度來自結構,而不是題目本身。每一輪都會同時考核你的 Leadership Principles 表現與專業能力,回答會被記錄下來並在面試官之間比對,而團隊之外的 Bar Raiser 可以否決團隊想要的候選人。
真正的難點是什麼?
如果你一直在刷演算法題目,卻還是覺得沒準備好,這種直覺是對的。本節要說明額外的難度究竟來自哪裡——因為它不在題目本身,多刷題也解決不了這個問題。
Amazon 採用結構化面試流程。每位面試官會被分配特定的 Leadership Principles 去考察,在對話過程中詳細記錄,事後再把筆記拿來比對。由此產生兩個後果:一個在現場聽起來還不錯的故事,如果沒有決策、沒有結果,寫在紙面上就會顯得單薄;同一個故事在兩輪裡講出不同細節,筆記一比對就會立刻曝光。
另一個難點在於,行為面試的門檻在技術輪裡同樣適用。一位候選人即便乾淨俐落地解出了程式題,卻說不出一次與經理意見不合的經歷,也算是沒通過一個純技術面試根本不會考核的環節。
Bar Raiser 到底在做什麼?
Bar Raiser 是一位來自招募團隊之外、經過專門訓練的面試官,任務是判斷你能否拉高該層級現有員工的平均水準。他們不考慮團隊這一季是否缺人手,也可以否決招募經理想要的候選人。
這在實際上意味著,決定你結果的人在這個職位是否招滿上沒有任何利益關係。招募的急迫性幫不了你,和經理的私交也幫不了你。真正有用的,是那些即便被寫下來、被一個從未見過你的人讀到,依然站得住腳的證據。
你通常無法分辨哪一位是 Bar Raiser,其實也無所謂。把每一輪都當作日後會被一個陌生人讀到來作答,因為事實正是如此。
合理的準備量應該是多少?
把準備工作拆開來看。技術那一半是大家熟悉的部分:資料結構、演算法,中階及以上職位還要加上系統設計。大多數失敗的候選人,並不是敗在這一半。
行為面試那一半,需要準備八到十二個涵蓋各項 Leadership Principles 的故事,每個都要講清楚情境、你本人做出的決定,以及可衡量的結果。一個專案往往能從不同角度講出兩到三個故事。只要有數字結果就寫下來,因為追問環節通常正是在要這個數字。
接著要大聲演練。一位有九年經驗的後端工程師,筆記寫得很出色,第一次實戰演練卻還是卡住,因為讀懂一個故事和在追問下講出來是兩種不同的能力。在 /mock-interview 上進行兩週的口頭演練,帶來的提升比再多讀一個月筆記要大得多。整個流程逐輪拆解的全景圖在 /answers/topic/company-interviews。
候選人通常在哪裡丟掉 offer?
大多數情況可以歸結為四種模式,而這些都與智力無關。
- 故事裡沒有決策。講的是團隊做了什麼,而不是你自己選擇了什麼。筆記裡最終沒有留下任何能歸到你名下的證據。
- 沒有結果。故事講到專案上線就結束了,卻沒說清楚它是否真的奏效。
- 素材用盡。同一個專案在四輪裡反覆使用,即便每位面試官單獨看不出來,彙整討論時也會一目了然。
- 悶頭解題。做程式題時不把思路說出來,讓面試官沒有任何東西可以記錄。
同樣值得說清楚的是,有能力的工程師在這裡被拒,原因常常與能力毫無關係,包括團隊契合度、當天面試小組的組成等因素。準備工作能改變勝算,卻無法決定結果,被拒並不是對你能力的定論。