求才者應如何面試程式人員
今天有人在「Java Spring framework 開發人員面試題」留下一則回應。 我看了回應之後，想到了求才者應該如何面試程式人員的事。
我分成兩部份來看。分別是「觀念或語法」，「方法或答案」。
觀念或語法
首先，以 Java Spring 框架的事為例。我在「Java Spring framework 開發人員面試題」出了三道問題。我問的是基礎觀念，而不是程式人員的記憶力。所以我期望的答案是概念性的解釋。我希望程式人員回答的內容，就像這篇「 程式設計師小心別被框架給「框」住了...」的原作者所期望的內容。我要的答案是「Concept」不是「Syntax」。
出這三道題目時，我會在旁觀察解答者。前兩題就算有些關鍵字或語法記不起來也無妨，那不重要。真正重要的只有第三道問題的答案，那才是真正的基礎觀念。
我列的那三道問題，涵蓋了 Spring 框架「正、反、合」的三種觀念層次。第一道問題是 Spring 框架如何重複使用既有的舊類別，而不需要修改舊類別的程式碼；將 POJO 對應到 Spring 框架的 Bean ，這是「正」。第二道問題則是在 Spring Bean 已經設計好之後，如何實作新類別抽換舊類別；方向和第一道問題相反，故是「反」。第三道問題則是 Spring 框架如何實現以上兩項目標的基礎，故為「合」。
第三道問題的觀念至為基礎，而答案異常簡單。若是跳過前兩題，直接看第三題的參考答案，我相信沒有人會覺得這四行程式碼有什麼難以理解的地方。這基礎觀念簡單到理解之後，我可以順手就用 PHP 寫一個簡化版，詳見「PHP 實作 IoC/DI 設計模式」。
喔，用 PHP 實作 IoC 模式還需要對 PHP 語言有足夠的熟悉度才行。但是了解觀念的人，自己創造工具只是時間早晚的問題。而不懂觀念的人，則永遠也踏不進這個領域。 連基礎觀念都沒有建立的人，充其量是看書打字的打字員。
附帶一提，關於資料結構與演算法的題目。我不是資訊科班出身的，不曾為了學期考試而去記過那些演算法公式或程式碼。在我看來，那些演算法的數學公式或實作程式，都是形式答案。面試時問這些東西只是在考記憶力。要問基礎觀念的話，我認為排序只需問氣泡，搜尋只需問二分。
方法或答案
我唸 MBA 研究所時，有一門課叫「研究方法」。這門課的內容就是在教我們「找答案的方法」。 因為在科學研究的領域，很多事還沒有答案存在，甚至我們還要習慣巔覆已存在的答案。 所以我們必須學習與熟悉找答案的方法。
在軟體設計的領域中也是如此。工具與技巧不斷推陳出新，而使用者的需求也一再改變。已經存在的答案總是不能滿足我們。所以熟記答案不如熟悉找答案的方法。
我個人學習的態度一向秉持「直讀原本」的態度。在國學領域中，直讀原本尚有原本考據的難度。但在軟體設計領域，直讀原本基本上沒有來源取得的問題。軟體設計領域要讀的「原本」就是許許多多的規格書或參考手冊。要學 HTML DOM，我首先會看 W3C 的 HTML Spec；要學 PHP 則必看 PHP Manual」；要懂 JavaScript 則必讀 EMCA-262。這就是最基本的「找答案方法」。
那要怎麼知道面試者是否熟悉找答案的方法？很簡單，就是在旁邊看他找啊。
以 PHP 為例，我特別喜歡問「echo "Hello " . $name;」和「echo "Hello ", $name;」有什麼不同。這牽涉到一個指令與兩個運算子的意義，而大多數的 PHP 程式人員不會去記這種事。不知道答案是正常的，而那也正是我想要的狀況。這樣我就可以丟一台筆電給他，請他找答案。
在搜尋引擎的幫助下，他通常會用 google ，然後我會引導他搜尋 php 和 echo 這兩個關鍵字。馬上他就會靠近我的陷阱。我會觀察他如何選擇搜尋結果。不過呢，這問題在我眼中只有一個選擇是正確的。只要他點下的連結不是搜尋結果的第一筆，也就是 PHP Manual 那一筆，我就準備說「謝謝再聯絡」了。
PHP Manual 這麼正式的參考文件都不先看，而跑去看那些不知真偽的論壇或部落格文章，這不是找答案的方法。對了，就算他點下的部落格叫「石頭閒語」，我也判定不合格。
我習慣提那些簡單而正式參考文件通常在 Google 搜尋結果第一頁的問題，然後觀察他們找答案的過程。只要他們查看的網頁離答案愈來愈遠，那麼合格也會離他們愈來愈遠。
我過去求職時面試過的資訊軟體公司，幾乎無一例外，全是先丟一份考卷給求職者寫。寫完後，助理再收回去給負責的人對答案。很遺憾，這種作法測不出求職者會不會找答案。找答案的方法永遠比答案重要。而他是否熟悉找答案的方法這件事，顯現在他找答案的過程中，而不是答案紙上的最終結果。
在旁邊觀察對方找答案與寫答案的過程，其實很快就能看出對方懂不懂觀念、會不會找答案。這花不了多少時間。
樂多舊回應