By 劉未鵬– November 4, 2011
Posted in: 學習方法, 未分類, 程式設計
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
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)
讀好書是如此的重要，因為好書往往帶領你去到更好的書，更大的世界。 FROM：http://mindhacks.cn/2011/11/04/how-to-interview-a-person-for-two-years/
轉載于:https://www.cnblogs.com/iplus/archive/2011/11/20/4467439.html
![Java經典面試題詳解：帶你手撸紅黑樹總結[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)