拿到 Google & Amazon Offer 的面試之旅（二）
拿到 Google & Amazon Offer 的面試之旅（一）
這是上篇的延續，有興趣的可以先去看前情提要與 Google 面試經驗分享。這篇就要接著聊聊 Amazon 跨國面試經驗，雖然一樣因為 NDA 不能洩題，但可以分享經驗跟想法，還有針對 Behavior Question 的體悟與反思，廢話不多說直接開始吧！
Amazon AWS (Seattle)
Amazon 面的是美國西雅圖的 Team，由於沒身份也沒簽證，談的方案是要先去加拿大待一年再內轉。面試流程是先選 Team，第一關就是該團隊主管 Phone Interview，通過後就是 Onsite 五輪，暴力一點可以排一整天解決，所以流程要快可以很快的，極限壓時間或許可以一個月內從 Hello 到 Offer，但我有多拖了一下時間來好好準備。
面試特色是非常、非常、非常愛考 BQ （Behavior Question），每關 Tech Interview 60 分鐘，一律先用掉 20~30 分鐘的時間問 BQ，剩下的才是技術問題，然後還有一場 60 分鐘全是 BQ，可以說是 Amazon 的重中之重。
開始之前：
是說，Recruiter 從一開始就很奇葩，先是寄信給我 OA，但我還沒來得及做，另一人又來一封信要約 Phone Interview 時間，我回給時間的同時問他 OA 還有需要做嗎？對方也沒回應。總而言之 Phone Interview 時間就這樣確定了（問號？）。網路上查一下似乎是他們判斷能力夠的人可以跳過 OA，但不解釋一下讓人疑惑很久。
第 1 關（Phone interview)：
我面的是 Dynamo DB 相關的 Team， Manager 是一個很和善的中國女主管，給我印象很不錯，先閒聊履歷與技能跟問了幾題 BQ，之後只考了個 Easy 題就輕鬆過了，讓我有點驚訝，或許是我的過往技能有讓她滿意（笑）。
之後就約 Virtual Onsite，我和他們約了兩個月後，讓我可以有充裕時間準備不是很熟的 System Design 題型，直到 Onsite 開始前一週才恢復聯繫。
此時來了個 解說員視訊和我聊 Onsite 面試的重點（基本跟網路上查到的差不多），有趣的來了，他和我說可以找他 Mock Interview，但此時離面試僅剩一週，且我後續寄信和他約時間居然直接被無聲卡…。
如果有興趣面 Amazon 的人可以提早詢問這個環節，或許有機會約到內部人幫你免費 Mock Interview，很划算，外面專家模擬面試一場好幾千台幣。
總之我只好忽視他，時間到直接上了。為了配合西雅圖時間，面試是連續兩天的凌晨 1:00am~4:00am ，加上正職工作，那三天總共睡不到 4 hr，可說完全靠意志力撐。
第 2 關：（Virtual onsite interview round 1)
很和善的印度人，先一輪 BQ，之後接一題很常見的 Leetcode Graph BFS (Medium)，快速秒殺後也沒有 follow up 了，就讓我隨意發問，閒聊了應該有 20 多分鐘，因為是熟悉的題型所以打字速度就挺快的，面試官一直說我是 quick coder。
第 3 關：（Virtual onsite interview round 2)
一樣 BQ 後稍特別的 Tree Traversal (Medium)，其實有印象看過這題，是某 Leetcode 原題完全沒改過，但早就忘了，只好當下重想。過程跟上一輪類似，很意外的是解完就都沒有 follow up，直接進入超過 20min 的長時間閒聊模式，這種題目難度如果在 Google 一定還會預期有 follow up 的
由於面試官也不是我未來的 team ，所以聊得有點尬，只能問一些較空泛的問題，例如 How is your day in Amazon，但對方人很好所以還算愉快。
第 4 關：（Virtual onsite interview round 3)
滿滿的 60 分鐘 BQ，面試官最資深（Amazon 年資10 多年）也最嚴肅，是整場下來給人壓迫感最大的一輪，或許是傳說中的 bar raiser，很多地方不停追問細節或請我重講，有時被問到我都覺得是不是我英文不夠好，用字不夠精確。總之我覺得表現不算太好。
最後被說雖然我 Tech 相關表現評價極高，但這關差了一點點沒達標可惜了，不然可以再上去一個 Level。
第 5 關：（Virtual onsite interview round 4)
BQ 後接 OOP 考題，這是滿特別的題型，但我覺得是好的題型。有點類似 System Design 要你設計一個系統，但主要是寫 code 並要用 OOP 的概念去做設計，例如叫你做一個停車場系統，你就會定義停車場物件、車物件、客戶物件…等等，並把各種互動的 function 寫出來。主要考核寫 code 是否乾淨漂亮易擴充好修改高內聚低耦合…等等那些基本素養，跟面試官的討論過程真的很像在做真實的專案。對已經工作過幾年的人來說，應該算相對輕鬆的環節，所以網路上討論度也很低，但還是建議花時間找個一兩題練習寫一下，以免搞不清楚面試官到底想看什麼。
第 6 關：（Virtual onsite interview round 5)
當初 Phone interview 見過的女主管，BQ 後接 System Design，運氣很好出了個我曾經稍微看過的題型，感恩的心。這關對有開發過分散式系統，處理過 scaling 議題的人來說，我覺得會是很愉快好玩的一關，但沒有的話準備起來會比較吃力，可以看我後續的面試準備篇有我推薦的教材。
最終感覺每一輪的技術相關考題，都沒遭遇到什麼特別壓力，算是我的運氣很好吧，反倒是 BQ 問題讓我感到困難的多。
面試結果
最後經過一兩週等待，最奇葩的來了！Recruiter （先前說可以 Mock Interview 但卻已讀不回我的那位）先是來一封信說 no hire, sorry blabla…，但一兩小時後又來一封說抱歉搞錯了，是 hire, congratulation。還好兩封信都是半夜來的，所以我一早起來是兩封同時看到，不然豈不被第一封信嚇死？
然後後續談 package 時又歷經換手兩、三個人拖了一週沒約成，終於聯繫上後說要 24 hr 給我 Offer Detail，卻又再拖了整整一週多才好不容易看到 Offer Letter 與 Initial Package。由於此前聽說 Google HC 流程很長，所以我先和 Google 那邊說 Amazon 要和我談 Offer 了希望加速，結果真的神速過關後，反過來變成 Amazon 遲遲沒消息，導致這段時間搞得我很心煩，看網路上有些大神可以同時拿到 3、4 家 FAANG Offer 在那邊 Compete，真不知道他們如何控制到差不多時間內同時取得 Offer 的，每個環節都非常不可控啊。
綜合心得感想
整體來說 Amazon 面試稍嫌混亂，聯絡的人時常更換或臨時代班。相比 Google 從頭到尾都是同一個聯繫窗口，有問題就找她，舒適度有點差距。
不過這僅就流程而言我覺得不甚理想，但只要是有聯繫上的人，基本上印象都不差，HR 大多都很客氣，而團隊主管與面試官更是讓我留下很好的印象，專業且和善，非常專注於面試者，也樂於討論溝通想法，分享的環節也非常大方。
最後拒絕的時候其實是非常掙扎的，一來是有出國的機會，二來是我也算是 AWS 的重度使用者，有機會能從使用者變成開發者會是非常有趣的體驗，但諸多考量下最後還是先選了 Google Taiwan，或許未來時機更成熟的話，可以重新考慮。
考題方面， Amazon 的 Leetcode 類考題比 Google 的簡單些（大概是 Easy ~ 中間難度的 Medium)，但一樣需要扎實的基本功，而 BQ 份量非常重，全部下來會被問 10～15 個 BQ 題，由於會說儘量不要用到重複的故事，所以準備起來不輕鬆。
若照網路上的建議，每個 Amazon Leadership Principle 延伸出來的常見題目都要想 3～5 個故事出來才安全，但這等於要想出約 200~300 個不重複的完整 STAR 模式的故事，實在太恐怖了。我最終只準備到一個 Principle 延伸 2~3 個問題各想一個故事而已（總共約 30 多個故事），面試也確實有一個故事不得不重複使用（聽說這樣會被扣分）。或許因為這樣最終沒拿到更高的管理級別 Level 可惜了些。
所以有志挑戰 Amazon 的人，Leetcode 練習可以適度就好，稍微看一下 OOP 題型，System Design 則是 L5 以上需要，最重要的是要努力想出無數個精彩的 BQ 故事，說真的我也不知道他們要怎樣審核這些故事的真實性，但我自己是不敢說謊就是，全部從真實發生過的事情努力去發想。雖然最後是有 Background Check 的流程，但要說真的去確認這些故事我認為仍然有難度。
Behavior Question 的意義？
最後一些針對 BQ 的小感想，我以前其實一直是瞧不起這個環節的，覺得 BQ 根本就是 Bullshit （對如果你覺得演算法考試已經很 Bullshit，那 BQ 就更是 Double Bullshit ），畢竟故事誰不會講，甚至真實性都不可考，無法理解 Amazon 為何看這麼重。
但這樣很認真的硬着頭皮準備一輪後，不斷嘔心瀝血反芻自己職涯上曾經發生過的管理與溝通經驗，開始有了不同的體悟。有時還真的突然感受到 Amazon Leadership Principle 隱含的價值與智慧。有些情境回頭檢討，會覺得當時如果能照著某個 Principle 的心態去處理，或許真的會不一樣。對於管理經驗確實不是很豐富的我來說，先入為主的對面試方式妄下評斷，確實有點太自己為是了。
如果拿任何單一條目單獨看，當然就只是漂亮的屁話，但如果套入實際情境回想，會發現當時的自己或 Manager 若能在某個時刻展現出某個 Princple 描述的特質，我確實也會很欣賞這樣的人。所以一個優秀的 Team Lead 或 Manager，大概就是能充分掌握這些 Principle 並靈活運用的人吧，而 Amazon 花時間問這麼多 BQ 就是盡力在排除說謊跟只會講漂亮話的人，篩出有領導力特質的人。當然也聽過較負面的說法是其用意在於挑出這種願意接受公司文化洗腦好管理的奴工 (?)，到底是什麼就讓大家自行判斷了。
相比之下 Google 確實更強調他們員工的聰明與靈活度，BQ 等個人特質的問題比重就低很多，Team Match 時不斷聽到主管強調公司信仰就是把一群聰明的人找進來，他們自己會找到想做的事與適合的位置，並貢獻產出，內轉跳 Team 很常見。但雖然聽起來美好，Blind 上也有大神跳出來分享這樣的結果就是大家都只想做 Creative 的那塊，一直開新專案做到堪用就會拿到好評，但後續真正痛苦的長期維護與細節調整沒人要做，因此僅完成 Prototype 後就被放爛的專案堆的到處都是。
不過不管是 Google 還是 Amazon，如果你目標在較高的職級（L6 以上)，關卡也同樣都是卡在 BQ 上，因為技術問題的難度就是那樣了，跟低階職位並沒有差太多，但 Behavior 能不能答到讓他們滿意差很多。
只能說不同的公司風格會有不同的優缺點，但能成長到這種等級，他的方式絕對有值得學習之處，沒有絕對的好與壞。
大公司面試實戰經驗的故事就先寫到這，希望這些故事與想法能帶給大家幫助。至於面試的事前準備部分，我另外寫了以下兩篇，有興趣的人可以參考。
