在上一篇文章〈建立軟體研發團隊的策略三問〉中，我談到了可以運用「問自己三個問題」的方法，來簡易、快速地制定軟體研發團隊的建立策略，也就是團隊的組成架構，以及團隊分階段組成的時機與節奏。這個打帶跑的戰略，接下來還需要戰術的支援，也就是「如何招聘」。
關於招聘，坊間的書籍和網路文章多得不勝枚舉。在這裡，我想跟各位分享的是個人在實務上的經驗與心得。在近二十年的主管工作經歷當中，我所受過關於招聘和面試的教育訓練，說實在的，真的是非常有限。我的招聘經驗，多半是經由大量的搜尋、閱讀、篩選履歷，以及大量的面談，再藉由實際錄取人員的績效驗證所建立起來的。
這期間，我找到過許多非常優秀的軟體人才（當然也有看走眼而踩到地雷，交交學費的經驗）。如果你問我，要將這二十年來的軟體工程師招聘經驗濃縮成為最簡單的兩個原則是什麼，我會告訴你，要先抓住「職能」和「熱情」這兩個重點。
您也許會說，這不是廢話嗎？世上哪個工作不需要考量這兩點啊！但重點是，每一種工作「職能的要求」和「熱情的呈現方式」是大不同的。這裡要談的就是，如何能在短短的幾十分鐘面試時間之內，就能快速、精準地界定、考核軟體工程師求職者的職能，同時還能探測求職者對此工作的熱情程度。這，就需要兩個看起來簡單，做起來卻又不太簡單的心法：「問對問題」，以及「用對工具」了。
問對問題
招聘這件事，首先當然是蒐集、篩選履歷，可能的話，接著做個簡短的電話面談。不過，這裡我們要先跳過這個部分，以後再另闢專文分享心得。就讓我們直接進入面試現場吧！
在大公司，求職者所接觸的第一個關卡通常會是人資的同仁。人資會讓求職者填寫一些資料、做一些通用型的測驗，例如英文能力、性向測驗等，然後才會請用人單位主管派員來面試求職者。而在小型或是新創公司，常常會是用人單位主管自己直接把上述的事情都做完。接下來，才會是用人單位主管與求職者之間的諜對諜遊戲的開始。
在跟求職者寒暄招呼，建立輕鬆的氣氛之後，我會馬上藉著這個輕鬆氣氛，直接開始探測求職者對這份工作的熱情程度。因為，人在輕鬆的時候，比較容易透露實情。
我常問的第一個問題是：「平常或假日沒事的時候都在幹嘛？」
這個時候，大多數的求職者都會說一些無關痛癢的興趣或是嗜好，諸如，看電影啦、打球啦、聽音樂啦、跑步啦、閱讀啊、上網啊、玩Game啊等等。到這裡，有發現什麼部分是您應該繼續追問下去的？那追問這些問題，到底是想要探測求職者的什麼東西？
如果你追問的是娛樂類的（打球、聽音樂、看電影...），那您只是在跟求職者繼續哈拉話家常而已。但您若是追問「閱讀」，那你可能就問對方向了。我通常會繼續問：「那您都讀哪些類別的書？有沒有您最推薦的書？為什麼？」若是追問「上網」，方向也可能是對的。我會續問：「都上哪方面的網？目的是什麼？」
熱情
上述兩類問題，我常會聽到一些讓我眼睛為之一亮的回答。譬如，「上網找資料、找開源程式碼、到社團提問...」或是「讀Design Pattern、APP開發的書、物件導向程式設計的書...」
這類的答案都是屬於非常正面積極的訊號。為了確認求職者是真的在讀這些書、或上網學習，我都會再繼續追問下去，請求職者一、兩分鐘簡短說明該書或網站學習的心得重點。
經過這樣不斷地「打破砂鍋問到底」的過程，我通常可以很篤定地判斷，這位求職者對於軟體開發這件事情，是否具備有高度的熱忱。沒有高度熱忱的人，通常不太可能會去自我主動學習這個領域的東西。
程式設計這種工作，需要有極大的熱情。因為，很少有人能夠一次就把架構設計完美、寫對程式碼 （編譯成功）、可以被成功執行、並且產生正確的預期結果。這個從無到有的過程，其實是一種創作的過程。而這個過程，往往包含許多必經的磨難，最後才能看到對的、滿意的成果。這些磨難包括，解決自己製造的bug （隨興寫code偷懶的代價或是頭腦不清楚時的產出），解決他人製造的bug （除錯好幾天後才發現真兇），想破頭、試到爆都無法重製的bug（就是找不到root cause），想專心設計、除錯，卻又不斷被老闆、同事、專案經理打擾中斷...等等。
擁有熱情，軟體工程師才能夠忘我地coding以及debugging，「享受」這個過程，而不會覺得它是件苦差事。如果你曾經看過某個軟體工程師突然拍桌大叫，或是突然大聲鼓掌叫好，通常，你應該是看到了一個有熱情的軟體工程師又通過了某個磨難過程，又解決了一個重大障礙，再度看到了美好的成果，又往目標靠近了一步！
求職者到底是為了你公司的名氣而來的？還是為了高薪和福利而來的？是對產品的願景認同？還是就愛寫程式？哪一種求職者才能跟你的團隊合得來？通過這段面談的技巧，應該可以輕鬆順利地都探測出來。
職能
探測完求職者的熱情程度之後，再來決定要不要繼續深入了解該求職者的職能部分。
過去我經常遇到聲稱「懂」或是「會」C程式設計語言的求職者。對於一個聲稱「懂」或是「會」C程式設計語言的求職者而言，能純熟無誤地運用C語言中最關鍵的「指標 (pointer)」這個觀念和技術，是必要的條件。
為了考核求職者這方面的能力，我通常會設計幾個簡單、但包含重要「指標」觀念在內的考題，來測驗應試者的功力。例如，「請在5分鐘內，在白板上寫一個C語言程式，內含一個名稱為Reverse的副程式，這個副程式可以接受一個內容為 "abcd" 的字串參數來當作輸入，而這個字串參數經過副程式的處理過後，其內容會被更改為 "dcba"。」
用對工具
各位有發現嗎？為什麼要讓求職者在白板上寫，而不用事先印好的考卷呢？其實，這樣做有非常多的好處。
首先，用白板，求職者通常會覺得我比較隨興。這樣可以稍稍減少求職者的緊張程度，盡量讓求職者的表現不要失常。
其次，用白板，我可以從頭到尾，清楚、同步地看著求職者是如何一步一步地構思、撰寫出他的程式。邏輯是什麼？習慣是什麼？是先寫出整個程式的架構、訂出副程式的呼叫介面與參數之後才開始填寫其細節？還是沒頭沒腦地依序寫，想到哪裡，寫到哪裡。
第三，用白板，也可以觀察求職者在撰寫完程式之後，是如何驗算、檢驗程式的。他會在哪些地方發現有誤？是多快能發現自己的疏漏、錯誤？如何修正這些疏漏與錯誤？又有多快速修正它們？
第四，用白板比用紙本更能方便地與應試者討論、互動、修改程式。當應試者在白板上寫著程式的時候，我可不是閒著沒事，滑我的手機。我必須比應試者更專注，用心地觀察上述三點所提及的種種細節，並且詳細記錄。當應試者聲明寫完程式之後，我會根據這些觀察，向求職者一一提問，直接在白板上比手畫腳，指三道四的。有時候也會讓應試者在白板上直接修改程式，以更臻完美，讓應試者發揮到極致，看看應試者的能耐底線在哪裏。
必要的話，我也會引導應試者去找到錯誤的地方，看看他是否只是一時的失察，還是，真的不夠熟悉C語言的基本觀念。
如此，我可以同時發掘許多求職者在程式設計方面的深度和廣度。像是，思維邏輯的細膩度、程式的穩固性（Robustness）、程式的效能（Performance）、程式的撰寫風格與習慣（Readability）、易不易於有利他人維護...等等。你想得到的，幾乎都可以用這種方式觀察出來。
第五，在與應試者這樣的一種互動討論過程當中，其實你還可以順便了解應試者的溝通和表達能力，以及團隊合作的能力（例如，是否會堅持己見，冥頑不靈？能否接納他人建議，朝好的方向修正程式？等等）。
用白板，絕對是一舉數得，簡單又好用，值得您一試！
經過這樣的招聘大考驗之後，求職者對此工作的熱情程度，以及其職能是否有到位，將逐一現形，無所隱遁。有了這些依據之後，我相信您一定能夠做出正確而有信心的錄用與否決定。
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
