最近看了一篇關於企業如何花兩年的時間去面試一個人的Bolg。把企業招聘難的問題分析的很透徹。現在企業決定是否錄用一個人基本就是幾天的時間。甚至不到一個鐘頭。雖然說有的公司搞所謂的“恐怖”的幾輪面試，尤其是好公司，聽說有7-8輪。
第一輪無非就是筆試題，招聘者每年需要絞盡腦汁出新筆試題，以免往年的筆試題早就被人揹熟了。出題很費腦子，要出的不太簡單也不太難，能夠濾掉絕大多數濫竽充數的但又要保證不因題目不公平而濾掉真正有能力的，要考慮審題人的時間成本就只能大多數用選擇題，而選擇題又是可以猜答案的（極少有人會在選了答案之後還敢在空白的地方寫爲什麼選某答案的原因的）。更悲催的是，有些題目出的連公司的員工們自己都會做錯（真的是員工們做錯了嗎？還是題目本身就出錯了？）。
筆試完了之後如果還沒有被鄙視就要進入面試環節，姑且不說筆試題的種種弊端，就說面試環節，短短几個小時的面試，既需要全面考察基本知識，又要考察編程素養，還要考察（也許最重要的）性格心態。再然後還有一項根本沒法考察但卻佔據程序員相當一部分工作時間的：debug能力。面試官不但得找準問題，不因對方一題答對而妄下結論，也不因一題打錯而就扼殺機會，還要以管窺豹，從一朵花看到整個世界，從面試人的舉止言談，分析問題的方式，甚至寫程序的筆跡來觀察這個人的性格，做事的方式和心態，簡直是要面試官具備心理分析師的水準才行。
所以企業想方設法地如何簡單地找到適合企業的真正人才。很多朋友也許注意到一個現象，現在企業對招聘者簡歷的要求也在變得越來越靈活變通，例如ThoughtWorks在招聘的時候就希望招聘者能給出自己的博客地址，博客對IT行業的意義也許勝過其他所有行業，一個積累多年的技術博客比任何簡歷都更能說明問題。臺灣的郭安定也說“爲什麼寫技術博客對新人如此重要”。可惜這個做法也有一個弊端：並不是所有技術牛人都寫博客，有人就是只幹不說型的，而就算寫博客，乃至動手寫過一陣子的，寫一個常年的博客，也遠比你想象的更爲困難，因爲很多時候，寫（說）得靠譜比做得靠譜更難。所以這個過濾器很多時候用不上。
但是這的確表明了一個思考的方向，就是尋找更具鑑別力的過濾器，Stackoverflow Careers 2.0之所以強大，是因爲Joel Spolsky和Jeff Atwood這兩位常年混社區的資深博主創造性地將一個人在社區的活動歷史濃縮成爲一系列的量化數值，由於這個歷史很長期，所以鑑別力非常高。但它同樣也有問題，就是對於應聘者來講相當花費時間，而且並不是花時間（在Stackoverflow上回答問題）就一定能花到點子上。
到底什麼特徵纔是既通用，又能夠有效地鑑別高低應聘者的特徵呢？這個特徵必須不像博客那樣難以實現，同時又必須有足夠的區分度。
有的地方在要求填寫簡歷的時候必須填上平時都訪問哪些技術網站。恩，很不錯的嘗試，可區分度仍然還是不夠，因爲上網站上查東西畢竟只佔現階段大多數應屆生的少數信息來源，特別是當我們看重得更多的是應屆應聘者的系統性的知識基礎的時候，網上的東西雖然豐富，但屬於提高班，也更爲瑣碎，什麼是更系統的知識來源呢？答案其實大家都知道——
書。
我一向認爲，很多時候，是否好好看完一本好書，對一個人的提升往往能達到質的區別。就算不好好看完一本好書，馬馬虎虎看完，只要書是真的好書，也肯定會有很大的提高。我在面試的時候就經常詢問對方看過哪些技術書籍，經常上哪些網站，訂哪些博客。這裏頭尤其數書籍這一項的區分度最高。此外，好書和壞書的差別，從本質上，就是學習效率和大方向的差別。一本爛書可以浪費你半年的時間，但一本好書卻可以爲你帶來真正紮實的基礎和開闊的視野。人們常常用“內功”來形容紮實的基礎，認爲學好了內功以後學什麼都快，其實一點沒錯，好的“內功”書不僅講清楚深刻的原理，而且指明技術的本質，刻畫領域的地圖。好的書抓住不變量，讓人能夠觸類旁通。好的書不僅介紹知識，而且闡釋原則，介紹那些萬變不離其宗的東西。讀爛書浪費時間，但讀好書卻節省時間。
象牙塔內的學生受到視野的限制，往往擇書不慎，事倍功半，爛書不僅浪費時間，還會打擊人的積極性，讓人對知識心生恐懼，認爲很難掌握，殊不知只是作者沒有講好（或者沒有翻譯好）。因此，爲招聘頭疼的公司完全可以給出“應聘俺們公司前必讀的十本書”，也不一定要每個公司都不一樣，在某個技術子領域有影響力的人，或者創始人們，可以來定義具有代表性的書單。
我們姑且把這個計劃叫做“書單計劃”，容易看到“書單計劃”具備以下幾個卓越的優點：
- 清晰、明確。完全可度量。
- 防僞：讀沒讀過，隨便一問便知。而正因爲應聘者也知道這事不像實習經驗可以忽悠，所以也不敢亂往簡歷上捅詞。
- 不在乎是否“泄題”：書單完全公開的，無所謂，本來就是要你去讀的。想背題？背書吧。真能背下來說明認真看了。
- 管你用心不用心讀，只要讀了，讀完了，就有區別。真正的好書，你想不被吸引都難。據我觀察很多人就是不知道該去讀什麼書。
- 不存在“怎麼做”的障礙：所有人都知道怎麼讀書——一頁一頁讀。
- 不需要招聘者投入精力：書單在此，就這麼簡單，您看着辦。
- 評估的負擔很大程度轉移到了應聘者的身上：是不是認真看完了，有沒有心得體會，您自己掂量。沒看完別來找我們。
“書單計劃”能很大程度上起到強鑑別器的作用，看了就是看了，必然能學到東西，沒看就是沒看。知道和不知道，區別是本質的。其實很多企業內部培訓，根本上其實還不就是叫員工去看之前沒看過的書或者資料嘛。最後，除了鑑別作用之外，它還是一個清晰促進的目標，是完全不花精力的培養。
當然，“書單計劃”的背後是另一個悲劇的現實，如果不是因爲這個現實，這個計劃也完全沒有必要，那就是，中國IT大學教育當中要求要學的書，和企業真正需要你去讀的書相比，不是完全不夠用，就是寫的不夠好，或者更悲劇的就是根本用不上，所以在這個大背景下出來的牛人都是自己淘書自己學的。微軟高級開發測試工程師，《Windows用戶態程序高效排錯》作者熊力就在微博上說過：“我當年畢業的時候總結了一個公式：第一份工作的月薪=大學四年買過的技術書籍價格的總和。”
但是光有“書單計劃”還不夠，因爲書籍只能管基礎知識這一塊，一些更難以量化衡量的實戰“能力”又怎麼辦呢？至少目前爲止，除了“練”之外好像還沒有特別好的辦法。可是在象牙塔裏面做的項目，或大作業，真的能起到練的作用嗎？前面說了，學生會知道自己最終要交差的不是僱主，而是老師，於是就以老師能夠評判的標準來默認要求自己了，老師能夠評判編碼素養？代碼風格？文檔？設計？協作？甚至連著名的Joel 12條的第一條“是否用源代碼管理系統”都沒法通過。所以大多數時候，大作業能起到的作用近乎0。
但是如果這一切是由僱主來評判的，這個“作業”是由僱主來給出的，就完全不一樣了。一想到作業是要作爲簡歷的一部分的，能不緊張嘛。能不好好做嘛。能不學到點東西嘛？
可是這事兒能實現嗎？僱主能給學生出大作業嗎？也許一兩個關係好的高校可以，可是中國那麼多學生呢？
爲什麼不能呢？如果像書單那樣，列出各個技術領域“推薦在學校期間嘗試的項目”，至於動不動手做，那是學生自己的問題。做的，自然能夠得到鍛鍊，面試的時候自然能得到更大的優勢。
可問題是，面試的人又怎麼來評估呢？這不又回到了沒法有效評估的怪圈了嗎？答案很簡單，但這個答案，直到最近幾年，才真正成爲現實——
GitHub誕生於08年春天，第一年便產生了4萬6千個公共項目，大約一年半之後用戶就已經達到10萬用戶之巨。而到今年九月份，GitHub已經迎來了百萬級用戶。Host超過兩百萬個項目。
增長的太快了！就像Twitter一樣。這樣瘋了一般的增長只能說明一個事實——人們等待這個產品太久了。
Social Coding。
真實的項目，真實的流程，真實的人名，一切代碼review, check-in, test, build, document, 甚至討論，計劃，brianstorming，流程，一切的一切，都是項目歷史的一部分，都可以像棋局那樣覆盤。有經驗的面試者只要稍稍掃兩眼一個人的GitHub歷史，挑出幾個check-in歷史看一看，便完全能夠迅速判斷這個人是否滿足他的要求。不再需要費勁心機地去想題目，去觀察，去揣測，去花費大量的時間的同時還只能採樣到幾個極爲有限的點。
不像象牙塔裏面大作業，這裏有源代碼管理系統，自動化build，有check-in，有review，有分工，有合作，最重要的是——這是一個集市，一個超出象牙塔的集市，牛人相互吸引，你可以在互聯網上找到和自己擁有共同興趣的一幫人，真正做起一點事情，而不是交差，不需要受限於幾十個人的一個小班級。Here Comes Everybody。
爲什麼我這麼有信心？因爲這事兒已經發生了。這個想法也完全不是我原創的。
正如很多事情一樣，現在在國內發生的事情，往往是美國那頭的歷史。今年7月中旬，紐約一家公司的工程師老大發了一篇博客文章：Github is Your New Resume。指出一個驚人但再合理不過的事實：越來越多的IT公司在招聘的時候要求應聘者給出GitHub賬號。甚至已經有人爲GitHub寫了根據GitHub上的歷史自動生成簡歷的工具。
仔細想想，這是必然的趨勢，沒有比這個再合理的事情了，既然StackOverflow的歷史能夠作爲簡歷，GitHub的歷史不本該就是更好的簡歷嗎：你想要具有實戰經驗，懂check-in懂review懂test和代碼質量的重要性，懂交流和溝通的重要性，你本就應該在一個真實的項目當中去鍛鍊這些東西，而這些在目前已經完全可以辦到。正如鄒欣老師所說，你的工作就是最好的面試。
這件事情放在早幾年，是完全沒法做到的，因爲我們那時候還沒有GitHub。正如沒有Twitter，沒有微博之前，很多事情都不會成爲可能一樣，你有千鈞之力，缺乏一個合適的支點，也沒法撬動一整個社羣。無組織中的組織，具有強大的槓桿效應。
這個事情裏面，我唯一提出的東西就是：在目前國內這個現狀下，苦悶的招聘者應該主動行動，給出一些建議項目，正如前面提到的書單計劃一樣，招聘者需要給出的只是引導和清晰明確的目標，剩下的事情，應聘者自然會去完成，這些項目可以是實驗項目，也可以是完全能做出點賣錢的東西的項目（如果好好做的話），唯一的不可或缺的前提是，項目不能太小，單人就能完成的項目不理想，一兩個月就能完成的項目不理想，最好足夠大到能夠鍛鍊到方方面面，偏大一點倒是無所謂的，因爲一個尚未完成的項目完全可以作爲簡歷。當然，可以想見的是，真到了那個時候，學生們肯定又是不會滿足於僅去做那些已經有許多人做過的項目了。所以這裏企業們一開始所建議的項目只是一個《Nudge》，是滾雪球之前需要的一點初始動能。後面的事情，他們自己會完成。
“GitHub計劃”同樣有一些明顯的、甚至不可替代的優點：
- 清晰、明確，完全可度量。
- 防僞：同樣不擔心“泄題”。你僞造不了GitHub歷史，僞造不了check-in歷史，review comments，文檔，交流記錄…
- 它不但是招聘，也是不花精力的培養。善哉善哉。
- 評估的責任很大程度上交給了應聘者自己。
從你的GitHub旅程開始，你就已經一腳踏進了真正的企業，而企業的面試也已經開始。
書單+GitHub，就相當於一個兩年左右的面試。
沒有什麼面試比持續兩年的面試更具有信息量。
書單，加上項目，已經基本上覆蓋了所需的全部技能。最妙的是，有太多的人在焦急的等待着他們未來的僱主給出明確的信號，他們想投入精力，去學習和實踐，去成爲企業需要的人，但是他們就是不知道往什麼方向走，所謂有動力沒方向。所以，僱主給出了清晰明確的要求，相信對於很多人來說反倒是一個解脫：“終於知道該幹什麼了”。《編程之美》爲什麼常居暢銷榜？因爲它透露了僱主眼中的需求，明確、清晰的需求，可以實現，並且知道怎麼去實現的需求。
你提前兩年就開始面試和培養未來的候選者，而且還不需要你花出一分精力，而且人家還很樂意，沒有比這更完美的面試了。
想一想，以後那些沒見過世面的公司看見你拿出GitHub賬號給他看，該是多麼驚訝同時又覺得多麼合理。
而這一切，只是因爲兩個小小的改變：
- 由需求方（僱主）給出了清晰、明確的目標。
- GitHub這樣的平臺。
那麼，學校/老師在這個事情當中的位置呢？說實話我不知道。沒有哪個行業像IT行業這樣特殊：沒有什麼東西不能夠（應該）在互聯網上學到的。自組織的力量完全大過傳統的教育方式。而且，既然僱主都當了領路人了，我不知道還有中間開發商什麼事兒。（注：這裏說的是軟件開發，並非計算機科學研究，後者另當別論）
那麼，這個改變會發生嗎？多久會發生呢？當然，它在國外已經發生了，所以問這個問題多少有點無趣。但我還是預計很快就會在國內發生，畢竟，不是已經有人要求出示博客，和經常瀏覽的網站了嗎？也許5年左右（4年本科和6年碩士的中間值？））就會深刻改變整個人才培養/招聘的格局。當然，我並不是預言家，所以不要把我的時間估計當真，我能肯定的是，這種方式是必然的大勢所趨。
剛纔我就收到一位同學邀請我上知乎回答一個問題“找工作的首要原則是什麼？”，當然，這個問題的答案是：“弄清僱主的需求到底是什麼”。
列一下我所認爲的，你面試微軟前必須要讀的十本書：
- Code: The Hidden Language of Computer Hardware and Software （《編碼的奧祕》）
- Computer System: A Programmer’s Approach （《深入理解計算機系統》） / Windows via C/C++ （《Windows核心編程》 / 《程序員的自我修養》
- Code Complete 2（《代碼大全》）/ The Pragmatic Programmer （《程序員修煉之道》，我也把這本書稱爲《代碼小全》）
- Programming Pearls （《編程珠璣》） / Algorithms / Algorithm Design / 《編程之美》
- The C Programming Language
- The C++ Programming Language / Programming: Principles and Practice Using C++ / Accelerated C++
- The Structure and Interpretation of Computer Programs （《計算機程序的構造和解釋》）
- Clean Code / Implementation Patterns
- Design Patterns （《設計模式》） / Agile Software Development, Principles, Patterns, and Practices
- Refactoring （《重構》）
（注：1. 以上同一條目下用“/”隔開的表示任選，當然你也可以都讀了，相信我，時間是足夠的。2. 讀這些書並不意味着逐字逐句從第一頁讀到最後一頁——當然你也可以這麼做。怎麼是聰明高效的讀法，可以參考我之前寫的關於如何閱讀和查找/鑑別書籍/資料的博文）
注意：以上是我個人認爲你面試微軟開發職位前必須要讀的10本書，它不代表我的僱主的觀點。它也只是一個初步的書單，肯定會受到我個人經驗和眼界的限制。歡迎大家提意見。
此外，IT不同子領域的必讀書單可能千差萬別，所以在發佈之前我把這篇文章發給了一些朋友，他們給出了自己的書單（你是不是能看到一些有趣的共同點呢）：
雲風（中國遊戲編程先行者，前網易遊戲部門資深程序員，簡悅創始人）：
如果面試，我會挑以下的我自己讀過的書，讓人選擇他也讀過的部分，再瞭解他對這些書的理解。這些書其實本質上就是兩類，對所面對的東西（程序語言也好，操作系統也好，底層設施也好）本身的理解程度。以及另一類：對設計思想和原則的理解：
- C++編程思想
- Effective C++
- 深度探索C++對象模型
- C++語言的設計和演化
- C專家編程
- C陷阱與缺陷
- C語言接口與實現
- Lua程序設計
- Linkers and Loaders
- COM本質論
- Windows核心編程
- 深入解析Windows操作系統
- 程序員修煉之道
- 代碼大全
- UNIX編程藝術
- 設計模式
- 代碼優化：有效使用內存
- 深入理解計算機系統
- 深入理解LINUX內核
- TCP/IP 詳解
馮大輝（丁香園CTO，貝塔咖啡創始人）：
- 軟件隨想錄
- ***與畫家
- 重來
- UNIX編程藝術
- 編程人生
洪強寧（豆瓣技術總監）：
StackOverflow上有一個程序員必讀書單帖子，這裏僅列出top10，更多參考這裏。
- Code Complete 2
- The Mythical Man-Month （《人月神話》）
- Code: The Hidden Language of Computer Hardware and Software （《編碼的奧祕》）
- TAOCP （不解釋）
- The Pragmatic Programmer （《程序員修煉之道》）
- Design Patterns （《設計模式》）
- The Structure and Interpretation of Computer Programs （《計算機程序的構造和解釋》）
- Refactoring （《重構》）
- The C Programming Language
- Introduction to Algorithms （《算法導論》）
張崢（微軟亞洲研究院副院長）：
- Algorithms (by Sanjoy Dasgupta, Christos Papadimitriou and Umesh Vazirani)
- Data Structure and Algorithms
- The C Programming Language
- The Design of the UNIX Operating System
- Compilers （龍書）
- Computer Architecture: A Quantitative Approach
- Flow
- Outliers (why hard work and luck are both important)
讀好書是如此的重要，因爲好書往往帶領你去到更好的書，更大的世界。
最後來個習慣性的總結，針對企業招人難和應聘者難以找到合適的職位問題以及如何解決兩者之間比較大的“鴻溝”。以下幾個Key Point解決了企業招人難的問題，而且簡單，節省了公司的很多人力，物力以及財力。同時也幫應聘者指明瞭方向，也不用像以前那樣迷茫了。
1.企業希望招聘者能給出自己的博客地址，博客對IT行業的意義也許勝過其他所有行業，一個積累多年的技術博客比任何簡歷都更能說明問題。
2.企業要求填上平時都訪問哪些技術網站
3.很多時候，是否好好看完一本好書，對一個人的提升往往能達到質的區別。企業指定針對這個崗位需要讀哪些書，並且招聘人的時候一問便知。
4.真實的項目，真實的流程，真實的人名，一切代碼review, check-in, test, build, document, 甚至討論，計劃，brianstorming，流程，一切的一切，都是項目歷史的一部分，都可以像棋局那樣覆盤。有經驗的面試者只要稍稍掃兩眼一個人的GitHub歷史，挑出幾個check-in歷史看一看，便完全能夠迅速判斷這個人是否滿足他的要求。
企業提前兩年就開始面試和培養未來的候選者，而且還不需要你花出一分精力，而且人家還很樂意，沒有比這更完美的面試了。
原文地址http://hi.baidu.com/xinxinwormbeta/blog/item/33b5b908fb3618880b7b8267.html對此加以修改。