【新聞分享】iOS神人應徵工作之滑鐵盧事件

【新聞分享】iOS神人應徵工作之滑鐵盧事件
應徵軟體開發工作時，就算你是名滿天下的人物，面試時，仍有可能因為無法滿足對方提出的要求，而不被錄取，考題不一定與應徵工作直接相關，甚至看似不合理，為什麼會出現這樣的狀況？

應徵軟體開發工作時，就算你是名滿天下的人物，面試時，仍有可能因為無法滿足對方提出的要求，而不被錄取，考題不一定與應徵工作直接相關，甚至看似不合理，為什麼會出現這樣的狀況？



最近，軟體開發圈子裡發生了一件事。

有位iOS開發者Max Howell在參加了Google的面談時，遭到了失敗，隨即在Twitter寫下了簡單的情況。

他提到：「Google：我們 90％的工程師都使用你所寫的軟體（Homebrew），不過，因為你不能反轉白板上的二元樹（binary tree），所以，我們沒辦法用你。」

Homebrew是個Mac OS X上著名的套件管理程式，而且可以說是相當的受到工程師的歡迎。而Max Howell正是其作者，不僅如此，Max Howell還是著名網路音樂電臺服務 Last.fm，以及 Twitter客戶端應用程式 TweetDeck的首席開發者，在OS X及iOS領域享有大名。

可想而知，當Max Howell無法如Google面談人員所願，完成這個二元樹的反轉題目時，其心中的情緒究竟會如何了。當Max Howell在Twitter藉由發文宣洩情緒時，也不少開發者共襄盛舉、加以聲援。

面試時，為何徵才者會提出爭議性考題？

一時之間，可以看到各種開發者在面談時，所遭遇到的各種題目及種種請求。有人甚至宣稱，Google當年面談他時，還要求當場重寫TCP協定。

照Max Howell的說法，他當時是去應徵一個和iOS有關的職務，但是Google的HR人員，沒有詢問到任何關於iOS有關的問題，而他自認是這個領域的專家而感到納悶。關於開發者在面談中會遭遇到的各種問題，似乎是我看過各種職業當中，爭議最多的。你很少看到其他領域，在應徵工作時，對於自己面談時被提出的問題，有這麼多意見的。我想，這可能和我們要究竟要如何衡量開發者的能力有關。

尋找聰明人與專業的程式寫手

有些公司宣稱他們只找聰明人，先姑且不論找所謂的「聰明人」是否就能找到合適的開發者，我想光是論斷什麼樣的人才是「聰明人」，可能就有很多爭議了。第一流名校畢業的就都是聰明人、在校成績優異的就是聰明人……反之，則就不是聰明人？再者，聰明有很多面向，適合考試、唸書是一種聰明，在這之外還有別的形式的聰明。當然，這也不代表會考試唸書的人，他們在其他面向上做不好，我只是想強調，這很難是唯一的指標。

所以，你會看到有些公司還有所謂「智力測驗」或「腦筋急轉彎」型的考題，或許就是在學歷之外，企圖尋找「聰明人」的替代方案。但這一類的測驗方式，往往也是遭受到開發者批評最多的一種，因為對於開發者來說，這種評量方式表面上來看，幾乎沒有什麼參考價值。

除了智力測驗型的題目之外，還有什麼問題是開發者在面談中會覺得有爭議的？首先，像是要求開發者手寫程式碼，但是卻期待所寫出來的程式碼是可以百分之百無誤通過編譯器編譯的。應徵一個程式設計的工作，會寫程式當然是基本的條件，但是，你我都寫過程式，可能都沒辦法打包票自己所寫下的程式碼，可以百分之百通過編譯器的檢查。要求寫下程式碼的目的應該是觀察其解題思維，而不是把重點放在是否語法完全無誤。畢竟實務工作裡，還是會有編譯器自動化的協助。

再來是若是關於解題方法的問題，通常解決一個問題有很多方法，最怕的是出題者已經先預設立場，認為只能用特定的手法來解決，而不能接受其他的方式。

面試最終目的，是協助你找到較合適的人

不過其實我真正想說的是，我們透過面談這個程序，想確認的真正事物，並不是被面談者是否能百分之百正確地回答出你想要的答案，因為這樣最終就會走向考試的型式。但以招募的角度來看，我們真正的目的是要找到可以用的人，因此，我們會希望透過高互動的面談程序，來進一步確認被面談者是否是符合開發團隊需求的人。

懂得演算法和資料結構的運用，當然是程式設計者的基本必備條件，但是，被面談者或許記不住一些資料結構或演算法的細節，如果面談的重點放在細節必須完全無誤，而這些細節是翻書或網上就隨時可以查到的，那麼，因為被面談者無法正確回答出這些細節，就刷掉一個有潛力的程式設計者，其實是很可惜的一件事。

從我的看法來看，做為一名負責在招募新人時的面談者，心裡想的，不應該是要提出艱難的問題、以「過濾」的角度來看待面談這件事。

也就是說，以一個夠難的問題，找出一些理由，來過濾掉那些「不能夠完全答對就是不合格的人」。而應該是從面談的互動過程中，探尋坐在你面前這位參與面談的應徵者，他是否具備適合加入開發團隊的知識、能力、以及性格，還有他適不適合融入此團隊的文化。

具備足夠的實戰經驗，比「會考試」更可取

在過去，我們可能會透過類似「考試」的方式來評量應徵者是否具備能力，因為，我們找不到更好的方式。這些都是間接的指標，就像我們可能推論比較「聰明」的人就比較適合這份工作一樣。但對程式設計者工作來說，真正的最值得參考的，就是過去的參與及產出。

現在有很多程式設計者在應徵工作時會附上自己的GitHub帳號，因為這麼一來，提供職務的公司就可以透過 GitHub 的機制，了解這些程式設計者在GitHub上的活動，包括他們參與過那些專案、甚至是他們的實際產出，都可以一覽無遺。

只要是內行的程式設計者，參照這些GitHub的記錄，可以很快的了解到對方的技術表現及實力。即使沒有 GitHub 的記錄，透過討論過去所做的工作內容，以及相關的心路歷程，也很容易可以明白。

需注意！單靠面試過程來評估對方，可能有主觀判斷的盲點

另一方面，我也可以理解對於大型的公司來說，缺乏客觀的指標，只單憑人為主觀的能力認定，在制度上會有其困難。因此在制度上多半會設計成，必須通過若干測驗，才能取得一定基本資格，才可以減低人為因素的干擾。

曾經有個笑話提到，有家公司收到應徵者的履歷時，會先用電風扇吹掉其中的一半予以淘汰，這個作法的目的是「先淘汰掉運氣不夠好」的那些人。當然這應該是個笑話而已，而或許有些制度會錯失一些好的人，但是，對某些公司來說，反正好的人源源不絕，錯失一些其實差別也不大了。但對小型的開發團隊來說，能有一個應徵者上門可能就是件不錯的事情，應該要避免做出錯誤判斷的機會。

可藉面試觀察人格特質，評估能否融入開發團隊的文化

最後我想說的是，除了技術實力之外，還有一些其他的應徵者特質，同樣是我們在面談中應該要探尋出來的，因為這些特質在軟體開發中也很重要，例如他的人格特質。人格特質在團隊開發中會扮演重要的角色，技術能力隨著時間還有進步的空間，但人格特質卻不容易。找一個不好相處、不易溝通的人進到團隊裡，通常也會帶來不少麻煩。

每個公司、開發團隊的規模、政策、文化不同，通常在取才上就會有不同的價值觀。即使程式設計的工作的應徵一直有這麼多的爭議，但是無論如何，還是希望每個團隊都能找到更好的方法、找到更好的人、打造更好的團隊，最後做出更好的產品及服務。

網址來源：http://www.ithome.com.tw/voice/97188