怎樣招聘程序員

在招聘程序員方面，沒有所謂的神奇「銀彈」！但我能夠分享一些建議和訣竅，它們通過個人實踐證實是有效的。這些方法我多年來一直在用。我把它們總結以下：

1. 首先，要求經過幾個簡單的「Hello World」在線測試。

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

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

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

2. 提出要看看他們的文件夾。

任何稱職的程序員都應該有一個「文件夾」，裏面收藏了他曾經作過的東西。這些東西無須奇特。我只是在尋找你在互聯網上留下的蛛絲馬跡，以印證你有多了不得。若是你是Stack Overflow的用戶，你能夠給我看看你的介紹頁面，讓我知道你是怎樣跟人溝通的，以及你是怎樣去幫助別人解決問題的。若是你參與了某個開源項目，那麼給我一個鏈接到開源代碼庫的地址。或者你有一個專業的博客？一個微博？在用Twitter？或者其餘我從沒據說過的東西？有這些就太棒了。咱們能夠一塊兒來看一看。分享一下你設計過的應用程序或者你作過的網站，並指出哪些部分是你作的。

看看應聘者之前作過什麼樣的工做，他在網上展現了什麼樣的做品，這對了解這我的是極其有幫助的——經過這些，能夠去理解他作過的東西，而且判斷出他擅長什麼（或者不擅長什麼）。

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

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

咱們在招聘過程當中會談到哲學，咱們對此是很認真的。咱們想讓任何可能進入GitHub公司的人都知道，他們將在一個怎樣的環境裏工做。咱們要確保他們跟咱們可以合得來。爲了達到這個目的，咱們可能跟他們一塊兒吃午飯，而且談論好比文化、哲學、咱們犯過的錯誤、計劃等方面的話題。

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

我意識到，不是每一個行業都爲他們正在作的事情建有一個社區，但若是你有幸擁有一個社區的話，你應該儘量從社區裏找出人才來，而且僱用他們。這些人天然已經被扯進了你正在作的事情，他們被你公司的磁場所吸引，並且他們的行爲徹底是自覺自願的。這些人可以適應公司文化的機率超乎尋常地高。他們就是你要找的人！

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

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

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

1.     作一點即興編碼，好比「在一個整型數組裏找出一個最大的整數值。」

2.     作一些基本的設計，好比「設計一個表示法，用於HTML的建模。」

3.     腳本編程以及正則表達式，好比「把某個目錄下包含特定格式電話號碼的文本文件都列出來。」

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」這篇文章。）

http://samuelmullen.com/2012/02/advice-on-attracting-good-developers/