True Talents Read Codes
之前寫「不用LeetCode，只要Show me the code時，我以為我的方法已經蠻高效了，這篇看完後我想我應該會在下次的面試中，加入更多「讀碼」的元素試試。
How to Freaking Find Great Developers By Having Them Read Code
當我們要招募開發者時，自然有許多特質是我們要關注的。其中「原形開發能力(raw coding ability)」的能力是一個看起來很簡單，而實際上是很重要的一項能力。儘管我們可在訓練時把領域知識導入給新人，但這種能力通常只會在立志要擴展或深入自己能力領域的人才能顯現出來。有些方法，可以很有效率的找到具有這個天分的人才。
一個典型的面試法是這樣的。面試官會請考生嘗試寫一支函式，能在一個字串中翻轉所有字元的順序。然後經過了半個多小時，考生在白板上嘗試”畫”出答案來(如果有線上文件是比較幸運的)。這種方式對於找到人才是非常低效的，原因是：
- 這些考古題，早就被考生練習過許多遍，答案早就背的滾瓜爛熟。你是想測考生背答案的能力？還是想瞭解他擁有的技能？
- 這種考題本身就是個問題，真正有洞見的人才，他們的天分很少是在面試的時間點下，能展示得出來的。
- 考試的本身，對考生就是一個無形的壓力，誰喜歡自己只能臨時發想的產品，展示給面試官看呢？更何況這是個能決定我未來幾年職涯發展的人。
- “寫”這種考題，基本上就是很過時，很不自然，也很耗時的測驗法。大家寫程式並不是在白板或記事本中”寫”程式，大家其實是在IDE中開發，而且會不斷的搭配Google搜尋。
與其要求考生現場寫出程式，不如考慮讓他們來”讀”一段現有的源碼，說說這段碼在做什麼，怎麼做的。這個方法有幾個很強大的好處：
- 表達源碼的目的和流程，可以探出身為一個開發者最重要的能力：閱讀。閱讀可能最高可佔去開發者95%的時間，不論他們是要寫新的碼，修問題，或是寫文件，他們一定要先能透過閱讀，理解源碼表達的涵義。讀碼的過程將揭露出2個職能所需的重要能力是：
- 記住變數和堆疊的位置：僅管現代的IDE已經解決了這個問題，但這仍是下一個能力的重要基礎。
- 組織出語意碼(Pseudo Code)：這可被理解為我們是否能用自然語言(母語)，重新解譯出這份源碼的能力。 也許我可以記下考古題的題目和答案，但我卻不能為這種無法預測的讀碼題(因為這可能會是面試公司的私有源碼)提前準備。我就像是突然被丟進陌生的國度，馬上就要被測試及考驗看看，我的觀察及人際溝通能力，能派上多少用場。這種能力不是刷考古題可以惡補得出來的。
- 讀碼再怎麼說也比寫碼有效率多了。經驗豐富的開發者，就可以在5分鐘左右的時間，告訴你從這份源碼讀到的東西，而你也能馬上確定他說的對不對，深度有多少。跟用寫的相比，完全不是同一量級的輸出。所以等考生寫出東西來的時間，你幾乎可以面試一打新人。
- 讀碼對考生來說，心理壓力會少上許多。而心理壓力對面試官來說其實也是大忌。在高壓的環境中，因緊張而腎上腺素激增的情況下，考生的理解能力通常都會表現的較低。我們甚至有可能會因為這種舊方法，而miss掉真正的人才。他用讀的，我們用問的，也很容易因應考生的背景或資歷，動態調整想問的題目，更為靈活。
如果我們打算試試看，以下是幾個建議。
- 一開始可先準備一些很基本的問題，型式都是「預期輸出(predict-the-output)」題型。這些問題會像是一些基本的函式呼叫，多層嵌套的函式呼叫，遞迴，副作用等這類的問題。這些問題基本上都是”假裝”成考題的，真正的目標除了讓考生讀起來輕鬆，容易成功，獲得一點自信心，對我們而言也是一些線索，讓我們能調整後續的面試會怎麼進行及安排。接下來當然就可以放一些進階的考題，包括一些我們過去曾寫過的東西，像是抽象化的設計，或是非同步通訊的操作等。有些沒特別註記的源碼，會有一些重要的算法，像是排序或遍歷樹，就很適合請考生閱讀後，從實際的輸出中找出源碼中的問題是什麼。
- 在真的開始對考生發問前，我們可做一些校正或調整。針對他們的經歷和對他們的期望所調整的問題，可讓我們更客觀的評估，他們職能的水平是什麼程度。很多時候在調校的過程，我們也會因此受惠，會從這些問題中萃取出精華，或是篩掉一些會讓考生混淆的部分。
這裡舉個例子，實際上”對話”起來會是長這個樣子：
- 面試的一開始，我會說明：
- 我不會考語法，你可以把我視為一個描述問題的AI驅動的Google機器人，只是為了要把考題的環境告訴你。
- 我不會苛求你要全部做完，也沒人真的做到，我們就是考20分鐘就結束。
- 我不會認為你的答案都必須要是對的。如果你的答案錯了，我會很樂意看看你怎麼回頭去找到問題。這個過程的本身，會和面試的其他資訊一樣重要。
- 面試中會像這樣：
- 我會秀出命令列上的命令，但不執行，這些命令應該是會呼叫函式，傳回內容，輸出到畫面上。
- 請考生讀碼，然後說說當我執行後，他預期會發生什麼事。
- 我執行源碼，然後看看結果。
- 如果結果和他預期的不同，請他回頭看看，跟我解釋為什麼。
- 20分鐘內看我們能進行到什麼程度。在面試的報告中，我會寫下他們考到哪裡，他們的優勢和弱勢有哪些。
很顯然的，這種”特殊”的開發技能(讀碼)並不是面試中唯一可被探出來的，領域知識和開發素養也很重要。這種讀碼能力的篩選過程，往往會幫我們篩掉了許多在真正開發實務中，可能不那麼合適的對象，這是最重要的好處。例如，很多喜歡重製輪子(Reinventing the wheel)的工程師，就是因為讀不懂別人的code，才會有「非我所創(Not Invented Here)」症候群，覺得這份碼不好，而自己又重做一份。
若今天我們是求職者，要怎麼應付得了這種面試？我想答案很簡單：就是「儘量寫」，沒有捷徑。那要怎麼練？最簡單的方法就是透過參與或實際開發，那些你真的會是用戶的專案。可能是一個遊戲，一個網站，一個app，每週花上4-8小時投入實際開發，就是要把它做到可以拿來炫耀。當然，如果你把這些副專案丟上GitHub，將來你的新老板會看到你在這個專案的活躍程度，就會很容易理解你的程度和水平。