FAANG 面試流程：哪些共通，哪些不同

拿掉公司名稱，這些流程看起來幾乎一模一樣：先是履歷篩選，接著是招募方的電話溝通，然後是一到兩輪在共用編輯器裡即時寫程式的技術篩選，最後是由四到五場面試組成的終面輪次，涵蓋寫程式、面向中階以上候選人的系統設計，以及行為評估。錄取決定來自對書面回饋的結構化討論，而不是某一位面試官的個人印象，整個流程通常要花上數週而不是幾天。

這套共同的骨架之所以存在，是因為這些公司都面對同一個問題：如何在大規模招募的同時維持穩定的品質。對候選人來說，這是好消息——準備工作可以複用：附口述講解的寫程式練習、每個你接觸過的系統對應一份紮實的設計敘述，再加上一個行為面試故事庫，幾乎能用在本頁提到的所有流程上。

各公司的分階段詳細拆解，見各公司面試流程專題頁。

既然骨架相同，為什麼準備建議會因公司而異？因為評分標準不同，而你的回答正是依這套標準打分的。這一節就是一張地圖。Amazon 把行為面試對應到自己的 Leadership Principles，並在每一輪終面安排一位 Bar Raiser——一位專門把關招募標準的外部面試官。Meta 依每個環節明確的信號項評分，寫程式環節出了名地高強度，四十五分鐘內出兩道題很常見。Microsoft 用它的成長型思維文化來檢視行為面試表現，通常會安排一位視情況而定的資深面試官來收尾。Apple 按團隊逐一招募，所以你在專業領域的深度和產品判斷力，比任何統一標準都更重要。Google 的流程本站另有專門頁面涵蓋，它更依賴結構化面試和委員會審查。

後勤安排也各歸各管：Amazon 的面試跑在 Amazon Chime 上，Microsoft 用的是 Microsoft Teams，其他公司則使用主流視訊平台加共用程式碼編輯器。這些差異不會改變你會的東西，只會改變你呈現它的方式——這也是為什麼在某家公司的終面前，花一個晚上讀一讀它的專題頁是值得的。

並行推進多個流程是常態，而不是例外，訣竅在於把通用準備和公司專屬表述分開。通用的工作只做一次：計時的附口述寫程式練習、設計敘述，以及一個依 STAR 結構寫得有血有肉的故事庫。然後針對每家公司再做一輪表述調整——在終面前那一週，把同樣的故事分別對應到 Amazon 的原則、Meta 的信號項，或 Microsoft 的成長型思維視角。

一位全端工程師在三週內先後經歷 Amazon 和 Microsoft 的終面輪次，是很典型的例子。同一個「搶救失敗上線」的故事在兩邊都用上了：在 Bar Raiser 面前包裝成 Ownership 和 Dive Deep，在 Microsoft 那邊則重新包裝成「靠回饋驅動的成長」。她的技術準備內容完全沒變，變的只是措辭。不論是在 Chime 上還是在 Teams 上進行的即時環節中，她的本地逐字稿和故事庫都一直放在一眼能瞥到的地方。

可以用模擬面試工具把每家公司的表述方式大聲練出來，同時記住誠實的邊界：有監考的測驗、錄影環節和共用螢幕，在本頁提到的每一家公司都不在輔助工具的適用範圍內，詳見可偵測性專題。