Joel Spolsky曾經感嘆：招聘難，難於上青天（此處筆者稍加演繹:)）。他有兩個辛辣但不乏洞察力的斷言：真正的牛人也許一輩子就投大概4次簡歷，這些傢伙一畢業就被好公司搶走了，並且他們的僱主會給他們不賴的待遇，所以他們也不想挪窩。（剛剛去世的Dennis Ritchie就是這樣一個人）而“人才”市場上能找到的大多都不是什麼人才。招到這幫人輕則費錢重則把你公司搞掛。
誠然，也許沒有哪個行業像IT行業這樣，無形資產佔據公司的絕大多數資產。拒坊間傳言比爾·蓋茨就曾經說過類似這樣的話：只要允許我帶走100個人我可以再造一個微軟。這話沒搜到原版出處，但是從一個側面反映了IT公司當中智力資產所佔的比例之重。
所以一個自然的推論就是，招聘也許是一個公司決策當中最最重要的一個環節。Joel Spolsky把他在這方面的觀察，體會和洞見集結成了一本小冊子《Smart and Gets Things Done》，開篇就挑戰“產品是公司成敗的關鍵”這個傳統觀念，他認為創造最適合工程師生活的環境，留下最優秀的人才才是最先最重要的一步，接下來好的產品是水到渠成的事情。國內iapp4me.com創始人郝培強正是這個理念，所以他在微博上說：
我們是小公司，工資開的不高，也不招太多的人，但是電腦都是iMac27，iMac21，Macbook pro15，基本上比很多大公司都好多了。軟體沒盜版，剛才photoshop的正版我也收了。中午管飯，公司備傘。哈哈。節日假正常放，從不加班，早晨11點上班，下午6點下班。我是有資格說某些大公司的員工苦逼的。
事實上，米國找個人尚且難成這樣，搞得Joel還費心費力寫本書語重心長地勸企業們要善待好工程師，國內找個人更是難上加難，問答社群知乎創始人周源就曾經在知乎上分享他嘔心瀝血的招人歷程，看完真是讓人慨嘆這年頭找個靠譜的人多不容易（這條知乎問答還有很多精彩的跟帖）：
其實從 08 年到現在，我一直想這事能不能有點竅門，或者是實用的方法，結論是幾乎沒有。我用過的大家都用的方法：
- 在水木上發貼子（有點效果）
- 在藍色理想上發貼子（無效）
- 在技術郵件組裡發貼子（無效）
- 買 51job/智聯 最便宜的服務（有點效果）
- 給所有可以想到的人打電話，請他們推薦（無效）
- 給所有和你討論過創業，喝過點小酒的人打電話（無效）
- 約前同事私下談（有效）
我用過的大家可能沒有用的方法：
- 上 twitter，看 XXX 的 follower，一個一個看，看他們的 twitter，部落格，Google Reader 分享，想辦法搞到郵件，聯絡，半夜電話騷擾。
- 上豆瓣，前端後端挑幾本重量級的書，去找想看，看過，正在看這本書的人，一個一個看，看他們的活動，部落格，Google Reader 分享，想辦法搞到郵件，聯絡，半夜電話騷擾。
- 找同事，問他們都看什麼技術部落格，想辦法搞到郵件，聯絡，半夜電話騷擾。
正是這樣的不容易，才有不少公司走內部培養的辦法，這裡的邏輯是：一上來就招到靠譜的人太難了，但找一塊靠譜的璞玉然後雕琢雕琢相對就簡單很多。這倒是個辦法，但這樣做的人難免就陷入了糾結：培養好了，人跑了怎麼辦。這也不能怪招聘的公司，的確是人之常情。其實解決的辦法也很簡單，培養的時候進行適當引導，讓員工發揮自己的主動學習能力，這樣不但人得到更多成長，公司也不會覺得投入太多患得患失。所謂師傅領進門修行在個人。
但是，這仍然還是沒有解決根本的問題，就是招聘真的很困難。應聘者固然覺得自己是在“海投”，大海撈針一般。而招聘者何嘗不也是這種大海撈針的感覺。這就好比兩個人談戀愛，都想和對方好上，但是偏偏就聊不到一塊去。
招聘真的很困難。以至於招聘者每年需要絞盡腦汁出新筆試題，以免往年的筆試題早就被人揹熟了。出題很費腦子，要出的不太簡單也不太難，能夠濾掉絕大多數濫竽充數的但又要保證不因題目不公平而濾掉真正有能力的，要考慮審題人的時間成本就只能大多數用選擇題，而選擇題又是可以猜答案的（極少有人會在選了答案之後還敢在空白的地方寫為什麼選某答案的原因的）。更悲催的是，有些題目出的連公司的員工們自己都會做錯（真的是員工們做錯了嗎？還是題目本身就出錯了？）
筆試完了之後如果還沒有被鄙視就要進入面試環節，姑且不說筆試題的種種弊端，就說面試環節，短短几個小時的面試（大多數公司也許連幾個小時的面試時間都沒有），既需要全面考察基本知識，又要考察程式設計素養，還要考察（也許最重要的）性格心態。再然後還有一項根本沒法考察但卻佔據程式設計師相當一部分工作時間的：debug能力。面試官不但得找準問題，不因對方一題答對而妄下結論，也不因一題打錯而就扼殺機會，還要以管窺豹，從一朵花看到整個世界，從面試人的舉止言談，分析問題的方式，甚至寫程式的筆跡來觀察這個人的性格，做事的方式和心態，簡直是要面試官具備心理分析師的水準才行。
這廂要招人的僱主苦不堪言，那邊找工作的人也是一團亂麻。絕大多數應屆生直到畢業也不清楚他們想要去的公司到底需要什麼樣的能力，或者說，他們到底需要具備什麼樣的能力才能在應聘季節擁有自己的選擇權。中國雖然本科教育環境差，但是同樣有很多的人在本科希望整點東西出來，他們有一腔的激情和抱負，有強大的動力，但就是不知道自己需要掌握哪些技能才能滿足僱主的要求，求告無門，整年整年苦悶的像沒頭蒼蠅一樣亂撞（我就收到過很多次這樣的來信，他們往往很想學點東西，但又不知道哪些重要哪些不重要，到底該學到什麼程度，不知道導致不確定，不確定導致決策癱瘓，乾脆嘛也不動，荒廢時間）。
什麼叫熟練？什麼又叫精通？那麼紮實呢？兩年的YY經驗又意味著什麼？能這麼簡單的量化嗎？同樣是兩年的“實踐”有的人能真的學到點東西，有的人也許近似一無所得。那麼實習呢？很多人都一定要在簡歷上弄個實習經驗，這個又能說明多少問題呢？大作業呢？得獎呢？有一次我面試一位同學，據簡歷說編譯原理課的大作業得了一等獎，可我一問什麼是遞迴下降，就傻眼了。
這個現實的結果就是，現在絕大多數應屆簡歷而言，也許最具資訊量的部分不是“精通XXX，熟悉YYY，掌握ZZZ”，不是“在UUU實習過”，也不是這個專案那個作業，反倒是越來越被認為不重要的一項：畢業學校。畢業學校本不應該是最具資訊量的，它之所以最具資訊量只是源於一個悲劇的事實：簡歷上其他條目實在資訊量太少了。所以靠譜的面試者往往學會了無視簡歷上華而不實的內容，只相信面試的時候親眼所見，掃兩眼簡歷也就罷了，最後還得自己捋起袖子慢慢面。而應聘者也許也知道招聘的也不會細細糾簡歷上的條目，所以什麼詞也都敢往上捅，反正先過了HR篩簡歷這關再說。從經濟學角度來講，應聘者的這種策略是正確的，沒有代價（因為目前似乎沒有公司會去給已經申請過的人做一個誠信資料庫），但至少有可能會帶來巨大的收益。應聘成了博彩。而博彩式的應聘給招聘公司帶來了巨大的篩選壓力。簡歷成了擺設。
那麼招聘這個關係裡面的第三者——學校——所處的位置呢？學校更關心的是畢業率和就業率，這似乎是件好事，有這個為目標，那麼老師們似乎應該努力讓自己的學生多學點東西。可惜就業的質量似乎不是最重要的指標，此其一。其二老師本身大多數沒有豐富的業界經驗，根本不知道企業整整需要的人才是什麼樣的，可能花了精力，但卻培養不出僱主真正需要的人。另一方面，老師所起的作用很多時候甚至是一個負面的作用，例如佈置大作業表面上看上去是培養學生的能力，我們姑且不說抄襲，假設每個人都做了，那麼大作業本身能夠衡量多少東西呢？能否衡量程式碼質量，能否衡量團隊協作能力？能否衡量交流能力？考慮到大作業用到的東西往往都是書裡面現成的，大作業甚至不能衡量學習能力。而學習能力簡直算是這個行業最重要的能力沒有之一了。
所以，簡而言之，如果把人才培養/招聘這件事情本身類比做一個專案，那麼這整個專案迄今為止就是一個巨大的失敗。為什麼這麼說呢：
- 和需求嚴重脫節：作為人才需求方的僱主的需求到底是什麼？絕大多數應聘者都沒搞清。更嚴重的是，這卻一點都不是應聘者的錯。因為僱主是stakeholder，是僱主自己的責任得去說清楚需求是什麼。結果應聘者實現的不是僱主想要的，僱主想要的應聘者沒有實現。
- 應聘者僱來培訓自己的人根本不管事：學生交了學費，就相當於僱老師來培訓自己，可培訓者根本也不瞭解（或不關心）他的客戶們的需求。這裡，學生是需求方，老師則是實現方。弄清需求的職責在後者，可後者也弄不清。
- 學生自己也弄不清：學生自己既是需求方（需要特定技能），也是實現方。可他們自己也弄不清需求到底是什麼。
以上三點還不是最嚴重的，最嚴重的在下面：
- 明白需求是什麼的也不知道怎麼實現：怎麼去培養現代IT企業真正需要的人才？特別地，實戰能力怎麼培養？程式碼素養怎麼培養？協作溝通能力怎麼培養？學習能力怎麼培養？就算這些都知道怎麼培養，又怎麼給在象牙塔裡頭，離催命之日還遙遙無期的學生提供足夠的動力呢？而學生自己就算知道該學哪些技能，又怎麼知道具體怎麼著手？什麼是最有效率的學習方法？又如何讓自己保持學習的熱情？
以上這些問題，就是當下人才培養/招聘的慘淡現狀。簡而言之，在僱主和學生之間，橫梗著一條巨大的鴻溝，兩頭都很著急，兩頭都有動力，但就是沒有方法，君住長江頭妾住長江尾。像微軟谷歌這樣的，乾脆和高校合作，直接插手本科或碩士的教育，從而保證到時有足夠強的候選，某種程度上，這的確是根本解決之道，可一來這代價太大了，非一般企業承受得起，二來這影響面也太小了。
這一切，也許將在未來的5年發生根本的變化。
《Switch: How to Change Things When Change Is Hard》（中譯《瞬變》）裡面指出，表面上看來非常困難的改變，也許是因為根本就沒有抓住要害。在書中作者通過大量案例分析和心理學研究，雄辯地指出以下幾點促成改變的關鍵之處：
- 觸動內心的大象：要改變的人必須要有情感層面的動力。有一些特定的方法能夠比另一些方法更能對人的情感產生觸動。
- 給出清晰、明確的目標：目標一定不能含糊，模稜兩口的目標讓人無所適從，導致決策癱瘓。例如最近我們組在招實習生，我在微博上發了一條招聘資訊，其中提到“紮實”的系統底層知識，有同學就寫信來問，怎麼叫“紮實”。我傻眼了。比爾·蓋茨就以目標清晰明確著稱，不僅在戰略制定上，“每個人桌面上都有一臺PC”，而且居然還體現在招聘上——“如果你讀完了TAOCP，那麼就給我投簡歷吧”。多麼清晰，明確的目標啊——雖然高了點，也許這就是比爾·蓋茨至今還沒被應聘郵件淹沒的原因:)
- 給前進的道路掃清障礙：人是懶惰的，只要有藉口就會不想往前。如果既有明確的目標，同時道路又直直指向目標，一覽無餘，只等你開始往前走，那麼便沒有藉口，一往無前。
那麼讓我們對照上面看看，可以做什麼？
首先，內心的大象不需要觸動，中國有足夠多的人足夠早就開始焦慮就業的事情，只是不知道往哪使勁，這部分人如果把勁頭用到正確的事情上面也許足以滿足現在的IT企業人才飢渴了。至於其他人，好吧，也許身邊的人開始動起來他們也會被觸動。
然後是清晰、明確的目標。這一點上目前僱主們的做法可謂好壞參半，好的一點是大家都強調要有實踐經驗，要有團隊協作精神，壞的一點就在基礎知識和技能的要求方面，可謂再含糊不過了：“精通XX語言”，“紮實的XX功底”，“熟悉XX技術”，甚至看上去最具量化感的描述“X年YY經驗”其實都根本說明不了多少東西，在資訊量方面還不如我家門口菜市場上一家賣酥油餅的店門口掛的橫幅——“三天不硬、至少六層！”。
很多朋友也許注意到一個現象，現在企業對招聘者簡歷的要求也在變得越來越靈活變通，例如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 《C程式設計語言》
- The C++ Programming Language 《C++程式設計語言》 / Programming: Principles and Practice Using C++ 《 C++程式設計原理與實踐 》 / Accelerated C++
- The Structure and Interpretation of Computer Programs （《計算機程式的構造和解釋》）MIT的這門課程視訊地址
- 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 詳解（卷1:協議、 卷2：實現 ）
馮大輝（丁香園CTO，貝塔咖啡創始人）：
洪強寧（豆瓣技術總監）：
StackOverflow上有一個程式設計師必讀書單帖子，這裡僅列出top10。
- Code Complete 2 《程式碼大全》
- The Mythical Man-Month （《人月神話》）
- Code: The Hidden Language of Computer Hardware and Software （《編碼的奧祕》）
- The Art of Computer Programming（《計算機程式設計藝術 卷一 & 卷二》不解釋）
- The Pragmatic Programmer （《程式設計師修煉之道》）
- Design Patterns （《設計模式》）
- The Structure and Interpretation of Computer Programs （《計算機程式的構造和解釋》）MIT的這門課程視訊地址
- Refactoring （《重構》）
- The C Programming Language 《C程式設計語言》
- Introduction to Algorithms （《演算法導論》）
張崢（微軟亞洲研究院副院長）：
- Algorithms 《演算法概論》(by Sanjoy Dasgupta, Christos Papadimitriou and Umesh Vazirani)
- Data Structure and Algorithms 《資料結構和演算法：C++語言描述》
- The C Programming Language 《C程式設計語言》
- The Design of the UNIX Operating System 《Unix作業系統設計》
- 編譯原理（龍書）
- Computer Architecture: A Quantitative Approach《計算機系統結構(量化研究方法)》
- Flow: The Psychology of Optimal Experience
- Outliers (why hard work and luck are both important)《 異類:不一樣的成功啟示錄 》
讀好書是如此的重要，因為好書往往帶領你去到更好的書，更大的世界。