加州求職記

演算法基礎

眾所周知，灣區的公司在面試時非常注重實際編碼能力，要求直接線上或在紙上、白板上寫程式碼，並且要求是可編譯的零bug程式碼，因此有ACM背景的應聘者會非常佔優。當然，不同公司在嚴格程度上也不盡相同，比如Amazon對無傷大雅的手誤或API細節記不清等情況相對寬容，Facebook次之，Google最嚴格。反觀國內的網際網路公司，雖然面試時也會問演算法問題（尤其是對應屆生），但一般不太會要求手寫達到可編譯執行質量的程式碼（要求寫偽碼的居多）；同時考量的知識面也會更廣、更開放一些。一開始我覺得灣區的這種面試方法並不科學——畢竟實際工作中沒人會要求你在不借助偵錯程式等工具的情況下一次性編碼成功。而且，競賽類演算法題的程式碼和工業界的程式碼完全就是兩種套路（在工業界幹過幾年的前ACM選手們應該非常清楚）。但反過來一想，自己周圍能夠達到這個水準的，無一不是牛人。而且這個方法高度統一，易於判定，在大規模面試中更利於統一面試官的評判標準，從而達到嚴格把關面試質量的目的。總而言之，這種面試手段跟高考有點類似——它可能不是最為合理的選拔手段，但對於大公司來說，為了保證更大範圍內的公平性和質量，似乎也沒有更為合理的手段，因此就現階段而言它也就是最為合理的手段了。

就我個人而言，在校時頂多也就參加過ACM校賽；無論刷題速度還是數學和演算法基礎都遠遜於專業選手，純粹是玩兒票水準。工作六年多更是基本告別基礎演算法，頂多也就是算個時空複雜度，偶爾用一次微積分都會感慨萬千原來這玩意兒還真有用得上的時候。再者就是平時寫程式的習慣。經過嚴格訓練的ACM選手可以做到解題時從頭至尾一氣呵成，當年ZJU校隊神人們直接在提交框裡寫碼提交一次AC的傳說屢見不鮮。我平時自知是個粗心鬼，寫程式一定是先搭架子後填肉，邊填邊調；要是妄圖一次成功，那最後多半是錯得沒邊兒。所以，演算法基本功以及編碼不夠快、準、狠，就是我最大的弱項。

為了彌補這些不足，我最早採用的方式是啃Algorithms、The Algorithm Design Manual等大部頭。然而實踐證明這個方法收效甚微。當然不是書不好，而是心態問題。這些大部頭行文嚴謹，事無鉅細悉數記錄在案，最適合用作教材或是當作手冊日常翻閱。對於目標主要是查漏補缺的我來說，從頭到尾看一遍太慢，而且一不小心就陷入細節或是一些事後證明完全沒有必要鑽的難點；跳著看又不知道到底哪裡是自己缺漏之處，無的放矢。

要想搞清楚缺漏之處究竟在哪，最有效的辦法還是實際做題。做不出來的自然就是缺漏，重點補習；做得出來的則儘量爭取一次到位，追求程式設計速度。在這條路上先後嘗試了CareerCup、ZOJ、TopCoder和LeetCode。四個站點的優缺點對比如下：

• CareerCup

  作為全世界碼農應聘者交流面試經驗和真題的集散地，其優點自然就是真題豐富。缺點也很明顯：很多題目描述不嚴謹，邊界情況模糊；沒有OJ，自己的程式碼正確與否難以得到客觀準確的判斷；參考答案僅限於使用者貼出的程式碼和思考，而且CareerCup論壇的程式碼排版效果噁心得令人難以置信，你幾乎不可能貼出一份縮排正確的程式碼！

• ZOJ、TopCoder

  ZOJ實在是太熟悉了，本科時閒來無事就在ZOJ上切題。TopCoder互動比較複雜，但流程基本上差不多。二者都是OJ，因此自己的程式碼正確與否、效率如何，都可以迅速判定。TopCoder相對於ZOJ的一個優點是可以檢索指定難度和類別的題目。缺點則是這二者都是競技平臺，當OJ判定程式碼錯誤時不會輸出額外的診斷資訊，一旦陷入難以想到的邊界情況就會花費大量時間。

  此外，就這次的經驗來看，ZOJ的題和TopCoder 500分以上的題在平均難度上比實際的面試題要高不少。與其在難題上耗費過多時間，多切一些簡單題提高寫程式碼的熟練程度可能更有幫助。

• LeetCode

  LeetCode可以說是結合了CareerCup和ZOJ、TopCoder的優點：既有真題，又有OJ。而且當OJ判定程式碼錯誤時，會同時輸出對應的測試用例，大大方便了除錯。在面試準備的後期，我完全轉向了LeetCode，訓練效果顯著。對了，目前LeetCode後臺的C++編譯器已升級到g++ 4.7.2，支援大部分C++11特性（尚不支援lambda），寫起C++來舒心不少 :-) 就這次的經驗來看，實際面試題的難度跟LeetCode的平均難度相差無幾。缺點則是題量較少，目前僅有100多題，覆蓋面較窄（例如二叉樹的題有一大堆，而圖論題則幾乎沒有）。

這裡引用Cat在他的Facebook面經中說的一段話：

 讓我「大開眼界」的是面試題，原來真正好的面試題並不在於它有多難，而在於它有多簡單，簡單到熟悉這個領域的人一下子就明白到你在說什麼以及想問什麼。能夠進入 Facebook 的人應該都覺得面試不難，至少跟中國的面試對比起來如此，那是因為 Facebook 把覺得面試有點難的人都過濾掉了，而中國那些很難的面試反而沒什麼區分度。

就我自己的經歷來看，的確如此。從難度上說，至少在電面階段，Google、Amazon、Facebook的演算法類面試題都是入門級的題目。給我的感覺有點像是考研——題不在難，而在區分度，考的是基礎是否足夠紮實。題目拿到手會做的話立馬就能下手，即便不會做也會覺得這道題很眼熟。Facebook onsite面試題的難度基本上也在這個水準。Google和Amazon兩家都沒有進行到最後階段，不知道後續的難度是否會有提升。從別的面經上來看，Google的演算法題在難度上要更勝一籌，Amazon則會有一些物件導向類的系統設計題。

英語溝通

雖然對自己的英語還算有信心，但此次面試前基本上沒有跟老外面對面溝通過，所以第一次英語電話面試的時候緊張得語無倫次，經常聽不清面試官在說啥，好在從第二次開始就完全無壓力了，竅門很簡單：提前打招呼讓面試官說慢點……說的時候不需要擔心語法錯誤之類，正如某篇面經所說，人腦的糾錯能力還是很強悍的，就算一個詞一個詞往外蹦，老外一般也能夠理解。

跑題說一說口語練習，這方面好像沒法短期突擊，只能靠平時多磨刀。英語口語，一是口音，二是流利程度。口音的問題，我是中學的時候靠聽英語歌並極力模仿歌手的發音解決的。至於流利程度，自然是靠多說。但周圍沒有說英語的人咋辦呢？我的辦法比較偏門——自言自語。以前在學校和公司裡的時候，出於種種原因經常需要做技術分享，必須確切明白地把事物講清楚。久而久之逐漸發現判斷自己有沒有把一個概念搞明白，最直接的辦法就是看能不能把這個概念跟新手講清楚，於是日常學習的時候也經常在腦袋裡做模擬。就這樣，漸漸染上了自言自語的毛病，即面對假想的聽眾把自己的思路講出來，一邊講一邊揣摩聽眾可能的反應並反覆調整說辭，直至表述準確易懂為止。再加上近年來看的文獻基本上都是英語，很多術語根本找不到合適的中文翻譯，腦子裡兩個locale切來切去太麻煩，漸漸就養成了用英語自言自語的習慣，無意間變相練習了口語。當然了，這種手段只能鍛鍊到專業技術方面的內容，日常溝通是覆蓋不到的。不過對於面試來說，剛好夠用。

Google

Google的面試機會是師兄推薦得到的。事後來看當時完全沒有準備好，實在是浪費了一次大好機會，對不住師兄。被推薦後不久，Google北京的HR聯絡我。電話聊了大概半個多鐘頭，瞭解了一些背景情況，然後便著手幫我安排電話面試和onsite面試。

電話面試的面試官是美國的華人工程師，全程說的是中文。由於時差，面試時間是北京時間早上八點（對方的下午四點）。簡單問了一些之前的工作背景就開始做題，大致是寫一個類，模擬TCP棧的收包邏輯。寫完之後又要求改為多執行緒版本，類似於一個生產者消費者模型。Google電話面試時是在Google Docs上線上寫程式碼的。頭一回寫，動作比較慢，總體上超時比較多，而且第一次給出的解法雖然沒有錯但並不高效。多執行緒版本快寫完的時候SSH隧道竟然斷了（Google Docs直接訪問不穩定，保險起見是翻牆訪問的）！由於面試已經超過預訂時間，面試官就說算了，面試結束後發到他郵箱好了。最後是例行的問答時間，不記得當時自己問的是什麼問題了。

雖然面試官讓我把最後一個問題的程式碼用郵件發過去，他卻沒有給我留郵箱，事後是通過HR轉發給面試官的。此外面試結束後發現面試官給出的多執行緒的條件有誤，會導致系統死鎖。於是寫了封長郵件，解釋了會導致死鎖的時序，給出了兩種可能的解決方案，並附上了詳盡的測試用例，順便優化了一開始效率不夠高的資料結構。當然，過程中沒有查閱其他資料，完全是獨立思考的。

約莫一週之後，HR幫忙敲定了位於五道口的onsite面試。兩輪面試各45分鐘，都是演算法題，要求在紙上寫程式碼，面試後紙張由面試官回收，似乎是要謄寫到面試反饋中去。第一輪的題目很經典，簡單到現在根本不好意思說自己曾經做不出來……如果是一個月後的我的話，毫無疑問可以秒殺，但當時卻嚴重卡殼。第二輪的題目稍有一些縱深，DFS搜尋加字典樹加介面設計，也不是很難；面試官持續要求優化，最後一個優化點我在最後一分鐘才想出來。面試末尾仍然是例行的問答環節，由於之前做了幾年即時通訊，我便問了一下Google在實時網際網路應用方面有沒有什麼規劃，但由於面試官不是這一領域，無法給出什麼實質性的內容，相互嗟嘆了一下Google Wave之後面試結束。

兩輪onsite下來，自我感覺非常不好，事實上這也是我這段面試經歷中表現最差的兩輪——沒有一道題能夠在規定時間內給出完整、無錯的程式碼。回想起來，這個結果跟我當時的複習策略有很大關係：當時我還處在看演算法大部頭，輔以ZOJ/TopCoder做題的階段，基本上是什麼題難做什麼題，後果就是每道題都鑽很久，解題時間很長，完全沒有達到訓練程式設計熟練程度的目的。再加上紙上寫程式碼一塗改就亂七八糟一團，越寫越緊張……就面試中寫程式碼的方式來說，我覺得用CollabEdit或Google Docs線上程式設計最輕鬆，因為跟平時寫程式差不多（當然如果是平時被VS/VA、Eclipse寵壞了那就兩說了）；白板上寫程式碼次之，因為寫錯的、不滿意的地方可以隨時擦掉，保持整體整潔；紙上寫程式碼最難，一不小心就塗塗改改搞得一團亂麻，既影響自己的情緒也影響面試評價。

雖然Google的面試只進行到第二輪onsite，但可以看出Google的面試要求還是比較高的。面試官在關注程式碼的正確性的同時，也會關注程式設計風格甚至介面的註釋。此外，Google的HR工作做得很到位，面試前給我發了詳盡的準備材料，郵件回覆也很及時。最後電話通知面試結果的時候HR先是問了我自己的感覺，然後結合面試官的評價委婉地給出了結論。

Amazon

Amazon的面試機會是同學推薦得到的。和HR全程郵件聯絡，反饋速度極慢，一個來回至少一週。和我聯絡的HR的工作時間跟Amazon總部差了幾個小時，不知道是不是外包。

Amazon的第一輪電面是我第一次跟老外電話溝通，起先覺得沒啥，但臨到面試時卻緊張得一塌糊塗——面試官語速太快，聽不明白啊……由於溝通不是很順暢，之前的工作背景介紹得比較失敗（之前有準備過，但是一緊張全忘了）。面試官的態度雖然很nice，但聽語氣似乎比較失望。之後，面試官對我申請的AWS組做了一個簡要介紹，然後便用CollabEdit線上做了兩道字串的題，過程還算順利。面試完畢之後review自己的程式碼，發現有兩處小錯誤，再加上一開始溝通不順，沮喪地想應該是沒戲了。

沒想到過了大概兩週多，在接到Facebook的onsite面試通知之後，Amazon的HR發郵件過來說打算再進行一輪電話面試，向我徵詢可用時間。回覆之後又過了大約一週，才總算敲定了面試時間。

這個時候我已經有了Facebook三輪電話面試的經驗，LeetCode也切了不少題，紙上寫程式碼雖然還欠，但在CollabEdit這樣的線上編輯器上幾分鐘切一道簡單題對付電話面試已經完全沒有問題（早點知道LeetCode就好了）。於是第二輪電面異常順利。一上來面試官問我選資料結構的題還是演算法的題，我選了資料結構題，半小時多一點切完兩道。做第二道題時我把一個條件理解錯了，面試官指出後向我道歉說是自己描述不夠清楚，好在演算法整體上差異不大。做第三道時，面試官鼓勵說能做到第三題的候選人不多，因為時間所剩無幾，就不要求寫程式碼了，給出思路即可。第三題討論完畢還剩幾分鐘，愉快地進入問答環節。末了，面試官給了很正面的評價，大致是說不太會有負面反饋，HR後續應該會安排到Seattle的onsite面試，當然他並沒有把話說死。

然而，接下來的情節發展就比較坑爹了。

Amazon第二輪電面結束之時，去Menlo Park參加Facebook onsite面試用的B1簽證已經搞定，但具體行程還未確定。本想如果Amazon的HR能夠及時跟進後續安排的話，就一次搞定兩家的onsite。然而Amazon的HR遲遲不見回覆。由於是第一次出國，擔心忙中出錯，便決定Facebook面試完畢後立即回國，大不了Amazon的安排下來之後再跑一趟。於是跟Facebook安排的旅行社溝通，將行程定為面試後第二天回國。又過了大約一週，Amazon的HR來信說對不起，經過比較我們選擇了其他的候選人云雲，具體原因則完全沒有提及。這麼莫名其妙地掛掉實在是令人惱火，但當時對Facebook抱的期望還比較大，並沒有太在意，心不在焉地回了封thank you了事。現在想來應該進一步追問一下被拒的原因的。總之，Amazon的面試官給我的感覺很好，但HR的跟進速度和質量實在無法讓人滿意。

Facebook

Facebook的面試機會同樣是同學推薦獲得的，這也是這次求職經歷中走得最遠的一次。正如Cat在他的面經中所述，Facebook的HR郵件回覆非常及時，而且經常在非工作時間回覆，整個過程中非常認真負責，不得不讚一下。Facebook的第一輪電話面試是由HR進行的，時間是Amazon第一輪電話面試的第二天早上，而Amazon第二輪電話面試那天，Facebook方面已經進行到委託旅行社替我安排onsite行程的階段了，其工作效率可見一斑。