怎樣招聘程式員

在招聘程式員方面，沒有所謂的神奇“銀彈”！但我可以分享一些建議和訣竅，它們經過我的實踐證明是有效。這些方法我多年來一直在用。我把它們總結如下：

1. 首先，要求通過幾個簡單的“Hello World”線上測試。

我知道這聽起來很瘋狂，但有些自稱是程式員的人根本沒寫過代碼。時至今日，還有人常常過來告訴我：他們在面試過程中碰到一些應聘者連最基本的編程測試題目都不會做，真是難以置信！

那也是為什麼要把簡單的編程測試作為任何面試流程的第一步的原因（如果你足夠理智的話）。這些測試應該是線上的，目的不是為了證明應聘者是不是編程天才，而要確認他們最起碼知道編程是怎麼回事。是的，這聽起來有點悲哀，令人沮喪，真的有必要這麼做嗎？然而，如果你不做這種檢查的話，相信我，你一定會後悔的！

有一些網站提供這樣的線上編程測試，比如Interview Zen、codility等。（我相信還有其他更多的網站提供類似的服務，但我目前只瞭解這兩個。）

2. 提出要看看他們的檔案夾。

任何稱職的程式員都應該有一個“檔案夾”，裡面收藏了他曾經做過的東西。這些東西無須奇特。我只是在尋找你在互連網上留下的蛛絲馬跡，以印證你有多了不起。如果你是Stack Overflow的使用者，你可以給我看看你的介紹頁面，讓我知道你是怎樣跟人溝通的，以及你是怎樣去協助別人解決問題的。如果你參與了某個開源項目，那麼給我一個串連到開原始碼庫的地址。或者你有一個專業的部落格？一個微博？在用Twitter？或者其他我從沒聽說過的東西？有這些就太棒了。我們可以一起來看一看。分享一下你設計過的應用程式或者你做過的網站，並指出哪些部分是你做的。

看看應聘者以前做過什麼樣的工作，他在網上展示了什麼樣的作品，這對瞭解這個人是極其有協助的——通過這些，可以去理解他做過的東西，並且判斷出他擅長什麼（或者不擅長什麼）。

3. 只僱用認同公司文化的人。

像GitHub一樣，我發現應聘者對公司文化的認同往往比他們高超的編程技能更重要，前者更能決定我們是否能夠成功。

我們在招聘過程中會談到哲學，我們對此是很認真的。我們想讓任何可能進入GitHub公司的人都知道，他們將在一個怎樣的環境裡工作。我們要確保他們跟我們能夠合得來。為了達到這個目的，我們可能跟他們一起吃午餐，並且談論比如文化、哲學、我們犯過的錯誤、計劃等方面的話題。

在早期，我們曾經單純因為一些人的高超技術而僱用了他們，但忽略了他們怎樣融入到我們公司文化中去的問題，或者他們是否理解我們對人處事的哲學。很自然的結果是，那些人的工作表現不如預期。因此，在我們關注應聘者技能的同時，他們是否能“變成”我們也是一個主要的考量因素。

我意識到，不是每個行業都為他們正在做的事情建有一個社區，但如果你有幸擁有一個社區的話，你應該儘可能從社區裡找出人才來，並且僱用他們。這些人自然已經被扯進了你正在做的事情，他們被你公司的磁場所吸引，而且他們的行為完全是自覺自愿的。這些人能夠適應公司文化的機率超乎尋常地高。他們就是你要找的人！

你發現有些使用者基於你的遊戲開發了令人驚異的衍生版嗎？有人發現了一個暗藏的安全性漏洞，並儘快通知了你嗎？立即把這些人僱用進來！

4. 做一個周詳的結構化電話面試。

上面3件事情一旦做完之後，該給應聘者打個電話了。我得提醒你，電話面試不是為了聊天，重點是要篩選（或者說淘汰）。電話裡談論的應該都是技術方面的問題，而且要以結構化的形式進行。這樣的話，如果你發現應聘者不合適目前的崗位要求，可以馬上結束通話。我們在後面有一節“如何做好電話面試篩選”專門來探討這個問題。這裡只是簡單總結如下：

1.     做一點即興編碼，比如“在一個整型數組裡找出一個最大的整數值。”

2.     做一些基本的設計，比如“設計一個標記法，用於HTML的建模。”

3.     指令碼編程以及Regex，比如“把某個目錄下包含特定格式電話號碼的文字檔都列出來。”

4.     資料結構，比如“在什麼情況下你會使用雜湊表，而不用數組？”

5.     位與位元組，比如“為什麼程式員開玩笑說10月31號跟12月25號是同一天？”

譯者註：10月31號用英語表示為Oct. 31，是萬聖節（也叫“鬼節”）；12月25號用英語表示為Dec.
25，是聖誕節。Oct.本來是October（10月）的意思，而程式員可以把它解釋成Octal（八進位）；Dec.本來是December（12月）的意思，而程式員可以把它解釋成為Decimal（十進位）。於是，八進位的31等於3
x 8 + 1，結果等於十進位的25，也就是Oct. 31 = Dec. 25。

不要期望從電話的另一頭得到完美的答案，也沒這個必要，你需要瞭解的只是這個人解決問題的方式，還有他們是否真的掌握了相關的技術（上下浮動10%）。你的目標是，不要讓一些不合格的人矇混過關，否則到了下一階段會浪費大家更多的時間。因此，你不要心慈手軟，要對電話另一頭保持火力，而當發現有太多疑點之後，提前結束通話。

（提示：我們將在下一節對電話面試進行更為深入、詳盡的分析。）

5. 給他們一個“試鏡”項目。

譯者註：“試鏡”是影視製作領域中的一個術語。用拍攝一段影片的方式，來決定某人是否適合當演員，或者某演員是否適合演出一部影片裡的某個角色。在這裡，作者把這種做法借用到了軟體開發領域。

到這時候，應聘者已經通過了“Hello World”編程測試，他的“檔案夾”裡的東西也很光彩奪目，他融入公司文化沒有絲毫的問題，他也成功通過了電話面試。是時候把他叫過來進行面對面的面試了，對嗎？別這麼急，兄弟！

我見過一些應聘者通過了前面4關，然後加入了公司，結果在實際項目中還是表現不佳。我沒有提醒你嗎？招聘程式員是很難的！

這位候選人會不會是一個成功的聘用呢？如果你還心存疑慮，想要抹去這層陰影的最好辦法，就是給他一個“試鏡”項目。我指的不是那種空泛的、抽象的編程問題，而是現實世界裡、實際項目中你需要馬上做的一塊實實在在的工作。這塊工作你原本是打算讓正式員工做的，只是他們現在都在忙著其他的事情，因此這塊工作暫時還沒分配出去。

這個項目應該以常規的諮詢服務的形式進行，按小時計費，並且清晰地定義好專案工作書。選擇的項目一定要小，理想情況下幾天就能做完，至多1~2周。候選人可以進辦公室來做這個項目，或者也可以遠程登入過來。我知道，不是所有的公司都能提供這種“一口大小”的工作分給公司以外的人來做。（他們拚死了也想把所有的事情都在公司內部做完。）但是，我就想了，如果你費勁腦汁還是想不出一個迷你的“試鏡”項目給一位很不錯的候選人做（你很有可能把這個人招進來哦），也許你在現有員工之間的工作分配方面也存在一些問題，至少不夠結構化。

如果“試鏡”項目做成了，那就太美妙了——你現在得到了一位高度合格的候選人，他的做事能力得到了驗證，而且你還有效地給實際項目完成一些工作。迄今為止，我還沒見過有誰通過了“試鏡”項目的考驗但後來還在實際項目中表現不佳的。我非常依賴“試鏡”項目來考察一個人的能力；做這種項目實際上跟做正常的工作很接近了，就差沒把人家聘用進來了。不過，如果“試鏡”項目失敗了，也不要緊，想想也就浪費一點點諮詢服務費，跟把候選人直接叫進公司、浪費公司的其他4~5位同事的時間去面試他相比，其實還是挺划算的。況且，你還可以把這個“試鏡”項目傳給下一位有潛力的候選人去做。

（利用僱傭合約上的試用期也是可以的，它們在概念上非常相似。雙方可以預先做好約定，先僱用6~8周作為考察期，然後再決定是否正式錄用。）

6. 找個房間面談，並最後定奪。

最後，你應該當面見一見候選人。這是必不可少的，而前面所有的步驟都是為了確保，在應聘者走進面試房間那一刻，你已經有95%的把握：他將是一位很棒的員工。

在面談方面，我絕對不是什麼專家，因為我不夠溫柔。但至少有一點，我不喜歡在面試的時候要人家回答什麼謎題。

關於怎樣面試程式員，其實我自有妙招：我會讓候選人對他們的專業領域做15分鐘的演講和展示。跟傳統的面試相比，我認為我的方法要有效得多，因為你很快就能看出來：

·       這個人對他正在做的事是否有熱情？

·       他能在小組裡有效地溝通嗎？

·       他對他的專業領域是否有很好的認識？

·       你的團隊是否會喜歡跟這個人一起工作？

拿 Steve Yegge的話來說，每個程式員都應該學會做一件事，那就是推銷自己、推銷自己的代碼和項目。我對這個觀點舉雙手贊成！開始吧，沖我來！

7. 上面沒有哪條是保證奏效的。

前面所說的這些你也別太迷信了！雖說這些技巧常常是奏效的，但我也見過偶爾不奏效的。你必鬚根據你的實際情況，保留那些你認為合理的做法，然後把其他的都拋棄（儘管我強烈不建議你跳過第一步）。即使在最理想的條件下，招人仍然是不容易的！工作做不好的原因有很多，有時候完全不受任何人的控制。就跟人們常說的那樣，人這個東西很複雜！

如果你也覺得“工作是在你有生之年每周都要花40小時（甚至更多）的一種重要關係”，那你就應該認真對待這次“約會”。公司和應聘者雙方都應該很真誠，盡各自最大的努力去判斷彼此是否合適。你的目標不應該只是為了得到一份工作，或者隨便找個人來做事，而應該樂在其中，為了一種相同的愛好而彼此靠近、並且走到一起。因此，不要匆匆忙忙做決定，除非你們早已相互傾心。

（順便補充一下，如果你想找到一些方法來吸引程式員，那你千萬不要錯過SamuelMullen的建議。請上網搜尋“Advice on Attracting Good Developers”這篇文章。）