如何輕鬆通過 ArcBlock 的招募流程

作者：Robert Mao (ArcBlock 執行長兼首席架構師)

ArcBlock 成立並發展至今已有數年，我們從未停止過招募。不同階段的差異可能僅在於職缺數量和節奏。我們的團隊建設原則是「質優於量」，嚴格的招募考核讓 ArcBlock 始終保持著一支小而精悍的團隊。同時，我們在大量的面試中投入了大量的時間和精力，偶爾會有一些應徵者對 ArcBlock 的招募流程略有微詞。以下內容旨在幫助對 ArcBlock 感興趣的應徵者更深入地了解我們的招募流程，並更輕鬆地通過我們的面試。

ArcBlock 的招募流程

ArcBlock 目前的招募流程是對微軟招募流程的優化。

微軟各個部門的流程略有不同，但總體來說都非常嚴格。每家招聘公司都需要投入大量的人力和時間。我曾經工作的微軟研究院（Microsoft Research Institute）便以其極其嚴格的面試流程而聞名。

在面試當天，通常如果有兩輪「不錄用（no hire）」，面試就不會繼續，後續的所有面試都會被取消。因此，如果應徵者接到 HR 通知有 5 輪面試計畫，但最後沒有面完所有輪次，基本上就意味著「不錄用」。相反地，通常能走到最後一輪面試，就意味著有很大的錄用機率。

微軟的面試在每輪之間會交換意見，這意味著下一位面試官知道前一輪的結果，以及前一輪建議下一輪應重點關注哪些問題。ArcBlock 也遵循這一做法。據說 Google 採用不同的方式，每一輪面試都是獨立的，然後由委員會進行集體評估。

ArcBlock 目前的招募流程：

我們的流程與之相似，但總時間顯著縮短。另一個特點是我們的 Coding Test 環節要求較高，但也提供了更多的時間，讓應徵者能更充分地展示自己的能力。

ArcBlock 程式測試 (Code Test)

無論是在微軟還是在新創公司，我都會遇到一些不太認同我們招募面試方法的人。例如我們的 Coding Test，在我們看來，這是最重要的部分，因為它涉及在放鬆、無壓力且有足夠自由度的環境中解決一個定義明確的小問題。當然，對某些人來說，這種「自由」正是「目標不明確」——其實兩種觀點都是正確的，但我們模擬的是我們團隊的工作方式。偏好非常詳細任務定義的個人，在其他團隊中可能是非常有價值的資源，但不一定適合 ArcBlock 團隊。

過去我在某大公司工作時，曾遇到一位應徵者拒絕回答系統設計問題，聲稱除非我們與他簽署保密協議或雇用他，否則他不會分享他「精闢」的想法；也有應徵者認為要求 Coding Test 是我們推廣技術的一種手段，甚至有人公開撰寫文章批評我們的方法。這些看似負面，但實際上充分證明了這種篩選流程的有效性。這些應徵者可能確實擁有非凡的想法和個性，但至少說明了他們的價值觀和認知與我們不同。及早識別並終止，不因雇用不合適的候選人而浪費彼此的時間，是對雙方最大的收穫。

ArcBlock 的面試：無需刷題

除了 Coding Test，我們還會要求應徵者在每一輪面試中撰寫一些「簡單」的程式碼。現在科技公司的程式面試已經非常普遍，所以大家可能已經比較習慣了。

在過去的十年裡，許多科技公司喜歡在面試中提出一些「高難度」且燒腦的演算法問題，導致「刷題」趨勢日益嚴重。然而，最近人們普遍開始停止這些可以透過刷題來應付的程式測試，ArcBlock 也不例外。無論是上述的程式測試還是面試中的測試（基本上每一輪面試都不可避免地要寫一些程式碼），我們都力求以相對簡單直接的問題進行面試，即使在演算法程式測試中，我們也盡量避免那些如果不先「複習」就無法回答的問題。

舉一個我在面試中用過的例子：實作一個將整數字串轉換為整數的函數（相當於 C 語言中的 itoa），這是一個非常簡單的問題，即使沒有演算法知識也應該能實作。但實際上，我發現以前超過 80% 的面試者都無法完整地寫對這段程式碼，主要是因為對一些邊界條件考慮不足（例如處理有號整數、處理極大的整數等）。

我們另一種類型的問題是答案「開放式」的問題，通常從一個非常簡單的程式開始，逐漸增加難度，直到變成一個非常困難的問題。例如，在實際面試中，我會使用 T9 輸入法來實作，從最簡單的版本開始，逐漸要求實作預測輸入，並考慮各種優化版本。這類開放式面試題沒有標準答案，而且會變得越來越難，可以充分考驗一個人的綜合能力。

面試是雙向選擇的過程

面試不僅是公司面試求職者，也是求職者面試公司。

通常在 IT 產業，招募方和求職方是相當平等的。作為一名求職者，毫無疑問，你希望能透過面試獲得 Offer。也許這是一份你非常喜歡的工作，或者團隊中有你嚮往已久的技術氛圍和同事，因此心情迫切是可以理解的。事實上，作為招募方的公司同樣迫切，有許多任務需要人力來完成或探索，渴望能立即找到合適的人選。在招募過程中，公司會盡力了解應徵者。應徵者也應利用這個機會多了解公司，判斷這裡是否適合自己。

在面試過程中，我們可能會問應徵者「你有什麼問題嗎？」這是一個提問的好時機。通常在 60 分鐘的面試中，我會先聊 2 到 3 分鐘，然後花 30 到 50 分鐘在程式撰寫和設計相關的問題上，剩餘的時間則留給回答提問。

面試不是「考試」，而是日常工作的縮影

在面試過程中，如果遇到困難卡住了怎麼辦？請記住，面試不是考試，而是實際工作的濃縮版。當你卡在某個問題上時，你可以嘗試自己解決或尋求幫助。通常面試官在面試過程中是很願意幫助你的。

因此，在面試時，請務必說出你的想法，而不是保持沉默思考或立即開始寫程式。即使你很有信心，也可以先簡要說明你對題目的理解、解決問題的思路，然後再開始寫程式；如果在回答時遇到困難，你可以讓面試官知道你卡在哪裡以及面臨什麼問題，通常面試官會給你提示。想像這就像平時工作一樣——你和同事合作解決一個問題，作為一個團隊，你絕對應該告訴同事你打算怎麼做，遇到問題時尋求幫助，並與他們討論。

幾乎所有的面試官其實都希望你能通過，而不是為你設置障礙。這實際上是公司面試的一個「秘密」。對於每一個來面試的人，我心底都真誠地希望你能順利通過，所以面試官的心態不是要為難你，而是由衷希望你能表現出色並通過面試。如果你能順利通過，我們就能迅速填補職缺，而不用再花更多時間面試更多人。特別是對於某些職位，可能已經面試了很多人，耗費了大量的時間和精力，這種願望會更加真誠。

ArcBlock 內部如何評估面試？

對於高科技公司來說，人才最重要資產。招錯人對公司來說可能是巨大的損失，有時這種損失是無法估量的，因此嚴格把關招募過程非常重要。

我們的招募面試評估只有兩個選擇：Yes 或 No。可以是 Strong hire（強烈建議錄用），或者是 Strong No hire（如果是 Strong No hire，結論肯定是不錄用）。我們不允許模稜兩可的判斷，或者把不確定性留給別人去判斷。

在我第一次參加微軟招募培訓時，給我留下深刻印象的原則是：「每當猶豫不決時，就不錄用（Whenever in doubt, No hire）。」這一原則也被 ArcBlock 繼承了，所以只要面試感覺不確定，或者覺得哪裡不對勁，那就是 No hire。

如此嚴格的要求，是因為我們只尋找「完美無瑕」的人嗎？其實不然。事實上，我們會雇用那些在面試中明顯暴露出問題的人——沒有人是完美的，我們不會僅僅因為你在面試中偶爾出錯演算法就拒絕你。很多時候這是可以理解的。但舉例來說，如果一位應徵者表現出極強的溝通能力，在過去的許多部落格和文章中展現了良好的理解水平，但在我們的程式測試和演算法測試中多次表現不佳，那麼我們就會產生懷疑——一旦產生懷疑，我們通常會選擇不錄用。

沒被錄用並不代表你的能力有問題

求職者未被錄用並不代表其能力有問題，僅僅代表其與該工作職位或公司團隊不匹配。我對所有未通過我們或其他公司面試的同學的建議是：不要糾結於此，信心不要受挫，只需轉移重心，專注於尋找其他更適合你的職位。

對於那些不喜歡我們招募流程的人，特別是對我們的 Coding Test 方法有意見，並且覺得每一輪面試都要寫非常簡單的程式碼與其豐富經驗不符的人，這正好說明我們的工作方式和風格與你不匹配，你可以及時退出以節省大家的時間。不認同我們的做法並不代表你的觀點是錯的，只是代表我們的工作風格不一致。

ArcBlock 的招募流程是務實主義和經驗主義的產物，是我們從過去工作中累積的自認最佳實踐，並將在未來的實踐中不斷調整和迭代。我們的目標是找到雙方都覺得適合共同發展的人才。

如果你剛剛加入 ArcBlock，我猜你已經經歷了上述流程，恭喜你！未來，你將有很多機會在 ArcBlock 團隊中再次經歷這個流程，但身分將換成另一個：招募者。

說明：這篇關於 ArcBlock 招募和面試培訓的文章既面向大眾，也面向我們的內部團隊。在新的 IT 時代，我們將在內部團隊建設中逐漸採取開放透明的策略，培訓內容和課程將不再區分對內和對外，並會逐步整理和公開過去內部培訓的資料和影片。