談談如何在面試中發掘程序猿的核心競爭力
早兩天看了知乎日報的這篇文章《什么是程序員的核心競爭力？》，caoz講的幾點是讓我感同身受。這讓我聯想起了給程序猿的面試，其實也就是通過短暫的接觸來發掘程序猿的核心競爭力。接下來我就談談我是怎么給程序猿面試的，當然每個公司每個面試官都有自己一套方法，如果覺得我說的有什么不好的，歡迎在評論中跟我討論。
簡歷中的核心競爭力
簡歷是讓面試官對你有一個初步印象的介質，每個面試者都應該花點時間研究如何讓自己的簡歷成為一塊敲門的金磚。
要方便招聘網站檢索
現在大部分人求職都是通過招聘網站，除非是內推這種形式。在簡歷到達我手里之時，是經過人事部門刷選的，而人事部門的同事對程序猿技術的了解，基本上是通過關鍵字。 作為一個程序猿，查閱資料是必須的，因此，你必須精通信息檢索。我跟大部分的程序猿都聊過，基本要寫出代碼，或者解決疑難雜癥，基本是離不開搜索引擎，更 有人放言，“離開了搜索引擎，我寫不出一句代碼”。也有不少人都表示，絕對不去不能上網查找資料的技術公司。搜索的技能在現代的編程中如此重要，那么，通 過搜索技能我們可以大致判斷一個程序猿在寫代碼上的水平——這并非是無稽之談。如果一個程序猿掌握了搜索的技能，那么你應該知道，如何讓你的簡歷順利通過 人事部門的刷選，毫無疑問，這就是展示你其中一個核心競爭力的方面。比如，你想找IOS開發的崗位，但是你的簡歷中沒有一句是關于IOS或者APP開發或 者其他有關手機開發的關鍵字的，即使你拿了幾個M$的MVP，即使你是架構設計上的大牛，估計也很難通過人事的篩選。盡量在你的簡歷中體現出你要應聘的崗位或者所需的技能的關鍵字，是一個好的習慣。
展現你的學習能力或者項目經驗
如果你是個應屆生，那么我會關注你所學的課程，所在學校，是否做過一些項目，或者在相關的技術社區或者開源站點中活躍。對于應屆生而言，項目往往是薄弱的環節，但是如果你能充分的展示你的學習能力，那么將是最能夠吸引面試官的地方。 作為一個程序猿，你必須得不斷的進行技術充電，要時刻緊跟技術的潮流，否則就會非常容易被時代所拋棄。無論你是想深入學習底層，或者是不斷追逐最新的技 術，這兩種人都非常具有市場，但是，這兩種方向，對學習能力要求都非常之高。前者要求你能夠靜心學習，有較強的悟性；或者要求你有較快的學習能力，并能夠 快速消化新的知識。
如果你是個有多年經驗的程序猿，那么，你應該充分的在簡歷中展現你的項目，介紹項目的功用，應用的技術，你們解決的難點，你承擔的責任。通過項目描述，往往能夠發掘一個人的技術廣度和深度，同時也能夠反應你在過去幾年中的成長，而項目中語言的表述，往往也能反應一個人的組織能力。如果我是要招一個架構師，那么你簡歷中從來沒有擔任過主程，也沒有獨立設計過一個系統，甚至對你從事了幾年的系統都表述不清楚的，技術也含糊不清，那么我還怎么有興趣對你面試？
平時招聘時，我都會先掃描一下程序猿的簡歷，然后做出初步的判斷，沒錯，這就是第一印象，它雖然不能立馬決定你這個人，但是基本上能夠影響我接下來面試的心情。
大體的流程如下：
讀書，寫博客，參加開源項目其實是一個很好的習慣，也能讓你的簡歷更加豐富多彩。
筆試中的核心競爭力
有些程序猿認為筆試毫無作用，有些人認為筆試的題目毫無作用。確實，我從來不認為可以通過筆試題目就能為公司招來一個性價比高的開發人員，而且 有很 多面試題我覺得出的根本毫無意義，尤其算法類的，為什么這么說？有多年工作經驗的程序猿都有這種感觸，算法在實際編程中用的其實并不多。算法重不重要？非 常重要！但是，大部分的時候，我們只需要了解算法的效率，是干什么的，大概能在什么地方用，就已經完全足夠了。很多現代的編程語言，都已經內置了許多的算法，而其他很多不常用的算法，網上也有了足夠的討論和現成的類庫，如果你不是專門搞底層開發，圖形類算法的，沒有必要花費太多的精力在算法研究上，所謂術業有專攻。
我舉個例子，我在工作中遇到了一個問題，如果有非常大數據量的數據需要繪制曲線時，曲線的繪制非常非常慢，因為有大量的數據點要去渲染，而且繪 制出 來的曲線時密密麻麻的，很難反應趨勢。后來我是怎么辦的呢，我研究了下，我們是否可以通過減少非關鍵點來壓縮曲線，只需保留有關鍵特征的數據點即可？但是 怎么壓縮，我并不會，也沒有理論支持，最后在網上搜索曲線壓縮”，立即得到相關的算法，用上去之后，曲線描繪的速度大大的提升，而曲線的趨勢又得到了保留，非常完美的解決了相關的問題。
但是，我認為筆試題目還是很有意義的，它的意義在于，能夠從側門反映你對基礎知識的了解程度，更重要的是，可以從做題的過程反映你這個人的一些編程的細節，面對困難的解決思路，以及基本的邏輯思維。
注重細節
我們有道題目是這樣的：
struct Node { string name; List children; } void Travel(Node root);
Q:函數說明：root是一棵樹的根節點，Travel函數可以遍歷該樹的所有節點，并打印出每個節點的name。
非常非常的簡單，但是，很多有經驗的程序猿答的并不好。完成這道題可以采用遞歸的方式，遍歷子節點并完成打印，但是中間有個細節是List children是一個引用類型，在使用是必須先判斷是否為Null！我看過很多人的試題，大概有60%的人會忽略掉這個細節。而實際上這些人在工作中也真的會寫出這種沒有任何健壯性的代碼，導致程序在使用到非正常數據的時候充滿了BUG，每當看見這些代碼我都非常非常的頭疼，并且不止一次的強調，但是這些人還是沒有這種意識。
何應對困難的處理能力
我們的筆試題目分布也非常有意思。前面兩題是一些概念的闡述，緊跟著是考一些細節和簡單的算法，然后是一到比較難的算法題和一道全部是英文的 ACM 算法題，最后是一些TCP和數據庫的題目。為什么這么分布呢，我們知道筆試一般都會限定一個時間，我們之所以把難題放在中間，其實就是考慮這個人是怎么面 對在工作當中的困難的。
我一般都不會期望面試者能夠把所有題目都在有限的時間內完全答出來，但是，你必須要把簡單的題目認認真真的回答完，不會的題目要大致的寫下思路。
有的人沒有一種全局考慮的思維，喜歡一路往下做題，然后和難題死磕，解決導致完成一份試題耗費非常多的時間，最后沒有完成，剩下的題目也草草寫一下完事。在企業中開發，如何正確的做事比你能夠把事做完要重要得多。我遇到過很多的程序猿，都是非常的有能力，但是往往在開發中，會讓整體的開發計劃偏離甚遠，甚至最后無法完成既定的計劃。不是能力的問題，而是做事的方法不對。
曾經我讓同事負責一個功能模塊的開發，產品給出了具體的需求，他粗略看了下之后估計個一周的時間。結果在做的過程中，發現了有很多不完善的地 方，然 后自己在那里埋頭苦干，研究一些非常細節的解決方案。3、4天之后我問解決了沒有，他說，這個不行那個不行，這個要幾天那個要幾天，最終說要多一個星期。 開發往往是跟預期對不上的，我也理解。結果下個星期又說不行，然后其他項目事情來了，最終一個月內也沒有把這個事情完成。這同事在這當中出現了什么問題 呢？
- 開發前沒有認真審核
- 沒有正確的預估困難
- 出現困難之后不知道靈活變通，先讓計劃正常運轉，把一些困難放在后續的交互中
- 過于在意細節
當然，我不是說我們不應該解決困難，或者不應該完善程序的每個細節。我只是強調做事的一個基本流程，在適當的時候跳過困難以免計劃偏離太大，要把更多的細節放在后期完善。 為什么這么做呢，因為整個系統不是你一個人在做，還有其他配合的程序，以及測試，如果你在這里卡殼，那么會造成整個計劃的無法實施，我們可以預留部分的問 題，在計劃的最后進行補上。另外，羅馬不是一天建成的，QQ也不是在剛開始就安全性這么高，搜索的體驗這么好，也沒有什么匿名發言之類的，我們很多的細節 其實是后期慢慢完善的，如果一開始就太過在意細節，那么往往導致我們沒法把事情順利的完成。再退一步來說，你現在考慮的細節，就一定是滿足以后客戶的需求 的？你能保證你現在想的東西以后一定是不會發生需求變更？
面試中的核心競爭力
面試也是非常有意思的一個環節。有些面試官很喜歡問一些刁鉆的問題，這個算法怎么實現，那個設計模式會不會，然后揪著某個細節批評人這不行那不 行 的，完全不考慮別人的想法。我覺這種情況純屬是平常工作苦逼想在面試中尋求存在感的，這種企圖通過一些實用性較低或者較為生僻的難題來考察求職者能力的， 屬于極度偷懶且不負責任的做法，這種面試官缺少對人才發掘的能力。招人的本質是什么，是找一些在各個方面都有比你強的能力的人組成一個團隊，相互彌補各自不足，從而發揮1+1>2的作用。如果你要找比你專業能力強的人，那有什么理由問他你擅長的地方？而作為一個管理者或者領導者，應該要有足夠的智慧對你手下的人做的取長補短，我們完全沒有理由揪著別人的短處問個不停，甚至因此而判斷這個人的能力有所欠缺。
在我之前的博文，也有這么些人總是忽略我提及的上下文環境，上來就一通說你這怎樣怎樣不行，到底怎么不行，他自己也說不清楚。我面試，從來都是 從應 聘者的項目著手，跟他們一起探討項目的實現，以及相關的技術，從中真實的了解到這個人的真實水平，而不會在意他是否了解某個算法，是否知道C#的擴展方法 怎么寫。
要在你擅長的地方做到精通
我喜歡面試別人的長處，一個人如果能夠在他熟悉的領域、項目能夠做到精通，那么這就足以說明了你的能力。大 部分 的程序猿其實是宅男，在與人溝通方面或多或少都有一些障礙，當然，在網絡中除外。但是一旦說到他擅長的地方，他就會非常的健談，并且會一直捍衛他自己的觀 點，在這個領域，他會覺得自己就是神。我有一個同事屬于這類人，平常交流起來是有點困難，但是做事非常的麻利，說起他的軟件和相關的技術，你根本就插不上 嘴。平常交代的事情，都是很快又高質量的幫你完成。
上個月我面試了一個程序員，看簡歷以及試題，做的都一般般。但是我在面試的時候，這個程序員表現的非常的活躍，給我詳細的介紹了他過去一年所從 事的 一個系統，他只負責其中后臺的一個通訊模塊，但是他把整個系統的工作機制，以及相關的技術還有選擇這些技術的原因跟我做了詳細的描述，并把相關的體系架構 在紙上畫了出來。我當時就覺得這個人是非常有學習能力的，問了他的薪水之后，立馬就跟人事拍板說就他了。不過可惜的是，后來這個人給其他公司要了過去，他 的薪水比在原來公司整整翻了一倍(比我們公司多了2k，主要是因為預算的問題而沒有堅持錄用)。
注重編程思想
我一直都認為編程的思想比編程的能力重要。
一個人的編程思想有很多因素構成：對產品的認識，對細節的要求，解決問題的思路，與人溝通的能力，調試的技巧，業務的了解和抽象能力，架構能力等等……
有人說了，與人溝通，也是一種編程的能力？是的，編碼只是一種編程能力的最直接的體現，但是影響你編程結果的，編碼僅僅只是一小部分。有些人不 擅長 和人溝通，往往做出來的東西和需求方相差甚遠，不但影響了工期，還給用戶帶來非常不好的印象。還有對產品的認識，對事物的認識，也經常能夠影響一個軟件的 好壞。我舉個非常簡單的例子：我們現在的軟件要求的功能是越來越豐富，定制化的程度也非常之高，但是真正給用戶使用的功能，其實并不到軟件整體功能的 20%，這就是著名的二八定律。了解這個有什么用？了解這個就能夠讓我們分清楚重點，可以集中精力把用戶需求的最重要的部分優先完成，并努力做到最好，這 樣，我們就能夠在順利按計劃把項目完成，因為即使中間有偏差，這80%并不常用的功能，也是在客戶的承受范圍之內。
所以在面試中，我非常喜歡問的是：你印象最深的項目是什么？你在這個項目中學到什么？你如何解決這些問題的？你們開發的流程是怎樣的，你怎么看 待你 們的這些流程？你是怎么確認你理解的需求跟用戶一致的？你是怎么保證你的開發計劃是順利進行的，如果開發計劃不能順利進行你會有什么辦法解決？
還有一個是調試的能力。優秀的程序員區別與普通程序員最大的一個特點就是調試能力。調試能力是一種非常綜合的能力，不但要熟悉調試工具，還要了解各種問題，了解語言特點。如果你具有優秀的調試能力，那么在開發中將會比一般的程序員更為高效，解決問題的能力也非常之強。
我們之前遇到過一個問題，我同事更新一個版本之后，偶爾會讓程序發生以下錯誤：
因為我們的程序都有對未處理的異常做一個最后日志的記錄，但是這種異常是無法記錄的，這個同事看到這個問題可能心里就覺得比較棘手，但是項目又 催的 很急，于是跟現場的同時各種調試，加各種日志，折騰半天。下午的時候我問起這個問題，還說這種偶爾出現的異常，可能是第三方控件的一些BUG。我聽了，覺 得就有點不對頭，這種對待錯誤的態度，很可能就導致這個BUG會遲遲不能解決，最終會影響這個項目的驗收。于是，我仔細把上面這個異常看了下，一下就發現 了這個：System.StackOverflowException。然后我查看了最新提交的代碼，發現其中新增了一段代碼，而這段代碼使用了一個遞歸。我馬上就判斷，90%是由于這個遞歸引起的，而且是在一些特殊的數值中會引起這個問題。很快，我同事根據這個判斷重現了BUG，然后花費30分鐘就修復了BUG。
我相信這個同事肯定是看到這個BUG的，但是，他可能敏感性不強，而導致忽略了這個BUG，另外還有可能是因為平時沒有注意把遞歸和System.StackOverflowException關聯起來，導致浪費了幾個小時。要是我不及時去了解，可能會花費一天或者更多。這就是編程的思想在實際工作中所起到的作用。
在面試中，我一般都會設計一些小的例子，讓面試者看看是否存在一些BUG，或者干脆提出一個開放式的問題，讓面試者設計一個日志記錄器，看看他到底會考慮哪些因素，從而判斷他是否掌握了相關的調試能力。
專注并自信
最后，我想說的是，面試是一個非常主觀的事情。你從上述文字應該也可以看出，我的面試，其實就是我個人的想法，我對跟我共事的同事的一個要求。 其他 公司或者其他面試官，或許又有其他的要求。但是，這都沒有關系。你只要在你的領域有足夠深入的了解，而且又有解決問題的能力，那么，你總會找到自己想要的 工作的。如果你暫時沒有找到，只能說你還沒有遇到你的伯樂。就像我們公司一樣，拒絕你，或者是因為覺得公司的要求或者方向不適合你，或者是因為公司給不了 你這個薪水。無論哪種，都不是因為你的能力的問題，我們沒有理由沮喪。優秀的人在哪里都能做出優秀的成果，但不是在哪里都能做出偉大的成績，我們應該要有足夠的耐心等待。
我們在來回顧一下面試中有哪些地方是體現程序員的核心競爭力的，看到結尾的或者直接拉到結尾的，就請默默點個贊吧：
- 簡歷
- 檢索能力，解決問題的能力
- 學習能力，組織的能力以及整體思維
- 筆試
- 編程細節
- 面對困難的能力
- 做事的方法、態度
- 面試
- 技術的深度和廣度
- 對項目的了解程度、做事的方法態度、學習能力
- 編程的思想：產品、細節、業務、溝通、架構、調試
