不需過早招聘太多員工 慢慢加人迅速發展
初期後期都並不一定要壯大隊伍。即使你接觸過100個頂級人才，一口氣把他們全招來也並不是什麼好主意。沒有辦法能讓這麼多人迅速的融入到統一的企業文化中去。你將遭遇令人頭痛的人員培訓、性格不和、溝通不暢、發展方向不同等諸多麻煩。
所以不要隨便招人。真的。不要招人，另想辦法。讓你陷入煩惱的這件事是真正必要的嗎？你不做又會如何呢？能不能用某種軟體或者改變做事方法來解決呢？
ge前執行總裁Jack Welch每次裁掉一個人之後並不會馬上招人來頂替他的位置。他想看看在那個職位和人員空缺的情況下能支撐多久。我們當然不主張用裁人來驗證這個理論，但是我們的確認為Jack的做法有一定道理：你並不需要你考慮中的那麼多人手。
如果沒別的辦法再考慮招人。但是你應該清楚知道你需要什麼樣的人，怎麼向他介紹工作任務，以及具體要他負責解決什麼樣的棘手問題。
Brooks的原則
給延期的軟體開發專案新增人手只會更加拖延進度。
—Fred Brooks
程式設計與莫扎特的安魂曲
一個優秀的程式設計師在完成單個工作任務時不存在因溝通和分工而產生的額外開銷。而五個程式設計師坐到一起完成同一個任務的時候必須分工合作，那將花費很多 時間……用很多一般的程式設計師而不是幾個足夠好的程式設計師將產生的真正問題在於：無論讓他們幹上多久，也絕對沒有優秀程式設計師幹得出色。五個Antonio Salieris也永遠寫不出莫扎特的安魂曲，哪怕給他們100年的時間。
—Joel Spolsky， Fog Creek Software的軟體開發人員 （摘自Hitting the High Notes）
摸底
先和候選員工在測試專案中協作
看作品、簡歷、例程、工作經歷是一碼事，和他在一起工作是另外一碼事。只要有條件，應該和準團隊成員一起去“試試車”。
在聘用人之前，我們會給他們一個小專案琢磨琢磨。我們能從中看出他們怎麼管理這個專案，他們怎樣進行溝通，他們具體怎麼做等等。和他們一起設計或者編寫幾屏程式碼能看出很多東西。你能迅速摸清和他們是否心有靈犀。
這種事規劃起來比較難，但即使只能拿出20或者40小時來做也比沒有強。適合不適合都能看得很清楚。如果不適合，先摸清情況能給雙方避免很多麻煩和風險。
小處著手
從分派一個小的測試任務開始。不要一股腦把你的工作任務都拿出來。給你的新虛擬助理一兩個測試專案來做，看看化學作用如何發生。開始的時候，大家很容易在和和氣氣的氛圍中忽略掉潛在的問題。記住這只是在試車。
—Suzanne Falter-Barns， 作家和創意專家
（摘自How To Find And Keep The Perfect VA）
行勝於言
根據對開源社群的貢獻選擇潛在的技術人才
典型的透過學歷、簡歷等方式來招聘技術人員在很多方面都是很愚蠢的。應聘者畢業於什麼學校、學習成績如何真的那麼重要嗎？一份簡歷或介紹信真能信得過嗎？
開源社群是為那些需要招聘技術人員的人準備的禮物。透過開源社群，你可以在很長的時間跨度裡跟蹤某人的成果和貢獻，無論好壞。
這意味著你能以他做過什麼而不是說過什麼來判斷他是否合適。你可以透過考察真正重要的方面來做決定：
工作質量
很多程式設計師說的時候口若懸河，實際去做的時候卻錯漏百出。透過開源社群，你可以直觀的瞭解這個人的程式設計技巧和素養。
文化視角
程式設計就是做判斷。很多很多的判斷。判斷力遵循於這個人的文化水平、價值觀和觀念。考察候選人在編碼、測試和社群討論（爭吵）中作出的具體決定，看看他在文化上是否和你有共同點。如果沒有共同點，每個決定都將引發一場爭論。
熱情程度
根據定義，參與到開源專案至少是需要一些熱情的。不然為什麼他要在螢幕前浪費業餘時間？對開源專案的投入程度就能看出候選人對程式設計的熱衷程度。
執行力
如果完不成任務，再聰明的頭腦、再合適的文化傾向和再高的熱情也帶不來有價值的軟體。不幸的是，很多程式設計師都做不到這點。應該去找那些熱忱工作的人。要做比買賣的時候，需要有這樣的人——這個人要把貨帶出門，而且他也願意去做。
社會經驗
和人一起共事很長時間，一起經歷過緊張和悠閒，一起經歷過起起落落，才能看出他們的真實性格。如果他缺乏教養，沒有社交技巧，把他排除掉。
說到程式設計師，我們只聘用透過開源社群認識的人。我們認為其他任何方式都是不負責任的。我們聘用Jamis是因為我們關注過他在Ruby社群的參與程度和釋出成果。他在前文所述的各個方面都做得很好。不需要次要原因，我們只評判真正重要的——他的工作質量。
不用擔心團隊成員“課外活動”的活躍度帶走他們的注意力和工作熱情。有句老話是這麼講的：如果你想做好一件事，去找你所認識的最忙的人。Jamis 和David兩個都是對Rails 社群有重大貢獻的人，同時，他倆還駕馭著37signals的技術部門。熱愛程式設計並且能幹活的人就是你真正需要的團隊成員。
對開源社群的熱情
你最希望從新員工身上看到的就是他對自己工作任務的熱情，而最能看出這點的辦法就是在開源專案中去追溯他的提交記錄。
—Jarkko Laine， 軟體開發人員
（from Reduce the risk， hire from open source）
尋找全面發展的人
選擇能快速學習的多面手，而不是專攻一面的專家。
我們從來不會用一個資訊架構師。那實在太狹隘了。對於我們這樣的小團隊，招技術層面那麼窄的人沒用。
小團隊需要能扮演不同角色的人。你需要會程式設計的設計師。你需要懂設計的程式設計師。每個人都應該對怎麼構建資訊（無論它指的是什麼）有自己的想法。每個人都應該思路清晰。每個人都需要能和客戶打交道。
而且每個人都需要能”在路上換檔“。要記住小團隊經常需要迅速改變前進方向。你需要有人能持續的調整和學習，而不是固步自封，只會幹一件事。
熱情是裝不出來的
選擇快樂的和技術水平中等的，而不是令人不滿的專家
熱情，是無法偽裝的。招人的時候，不要認為你需要一個技術大師或者技術名流。他們往往自以為是。一個水平說得過去的快樂員工勝過於愁眉苦臉的專家。
尋找充滿熱情的人；尋找你信任他可以獨立完成任務的人；尋找在發展緩慢的大公司受過折磨，並且渴望新環境的人；尋找為一起去建造你正在建造的東西而感到激動的人；尋找對你所厭惡的事物同樣感到厭惡的人；尋找為入你的夥而感到興奮不已的人。
為提問加分
留意候選人是否對你的專案提出很多疑問。熱心的程式設計師總是想盡量去理解存在很多疑點的問題並快速提出可能的解決辦法和改進方案。闡明問題能產生一種 認識：專案的做法很多，但基本上取決於你對你的Web應用如何運作的想象。當你深入到細節，你能感覺到這個人是否在文化水平上符合。
—Eric Stephens， BuildV1。com
煉字師
招文字功底好的人
如果你在琢磨從幾個人選中挑出哪一個來填補空缺，選文字功底好的那位。無論他是設計師、程式設計師、市場人員、銷售人員還是其他，寫作技巧都很有用。簡潔高效的寫作和文字編輯能力可以帶來簡潔高效的程式碼、設計、郵件、即時資訊以及更多。
這是因為要當好寫手並不只是堆砌詞藻。好寫手懂得溝通的技巧，他們讓事情易於理解，他們能站在別人的立場考慮問題，他們知道什麼是可以忽略的，他們思路清晰。而這正是你需要的才能。
條理清晰的頭腦
好的寫作風格是頭腦清晰的指示器，清晰的頭腦能有條絮地梳理資訊和論點，還能幫助（而不是逼著）其他人去理解。這種技巧能滲透到程式碼的編寫、口頭表達、即時通訊（對於那些遠端協作的人來說），甚至更深層次的職業素養和可靠性等領域。
—Dustin J。 Mitchell， 開發人員 （摘自Signal vs。 Noise）
有清晰的文字才有清晰的思路
清晰的文字能帶來清晰的思路。表達它的時候你才知道你對它瞭解些什麼。好的寫作風格也從一定程度上反映出人的性格。讓讀者省事，而不是給自己省事。
—Michael A。 Covington， 佐治亞州立大學計算機科學教授
（摘自How to Write More Clearly， Think More Clearly， and Learn Complex Material More Easily
