談談如何在面試中發掘程式設計師的核心競爭力
前兩天看了知乎日報的《什麼是程式設計師的核心競爭力？》這篇文章，caoz講的幾點是讓我感同身受。這讓我聯想起了給程式猿的面試，其實也就是通過短暫的接觸來發掘程式猿的核心競爭力。接下來我就談談我是怎麼給程式猿面試的，當然每個公司每個面試官都有自己一套方法。如果覺得我說的有什麼不好的，歡迎在評論中跟我討論。
簡歷中的核心競爭力
簡歷是讓面試官對你有一個初步印象的介質，每個面試者都應該花點時間研究如何讓自己的簡歷成為一塊敲門的金磚。
要方便招聘網站檢索
現在大部分人求職都是通過招聘網站，除非是內推這種形式。在簡歷到達我手裡之時，是經過人事部門刷選的，而人事部門的同事對程式猿技術的瞭解，基本上是通過關鍵字
展現你的學習能力或者專案經驗
如果你是個應屆生，那麼我會關注你所學的課程，所在學校，是否做過一些專案，或者在相關的技術社群或者開源站點中活躍。對於應屆生而言，專案往往是薄弱的環節，但是如果你能充分的展示你的學習能力，那麼將是最能夠吸引面試官的地方。作為一個程式猿，你必須得不斷的進行技術充電，要時刻緊跟技術的潮流，否則就會非常容易被時代所拋棄。無論你是想深入學習底層，或者是不斷追逐最新的技術，這兩種人都非常具有市場，但是，這兩種方向，對學習能力要求都非常之高。前者要求你能夠靜心學習，有較強的悟性；或者要求你有較快的學習能力，並能夠快速消化新的知識。
如果你是個有多年經驗的程式猿，那麼，你應該充分的在簡歷中展現你的專案，介紹專案的功用，應用的技術，你們解決的難點，你承擔的責任。通過專案描述，往往能夠發掘一個人的技術廣度和深度，同時也能夠反應你在過去幾年中的成長，而專案中語言的表述，往往也能反應一個人的組織能力
平時招聘時，我都會先掃描一下程式猿的簡歷，然後做出初步的判斷，沒錯，這就是第一印象，它雖然不能立馬決定你這個人，但是基本上能夠影響我接下來面試的心情。
大體的流程如下：
讀書，寫部落格，參加開源專案其實是一個很好的習慣，也能讓你的簡歷更加豐富多彩。
筆試中的核心競爭力
有些程式猿認為筆試毫無作用，有些人認為筆試的題目毫無作用。確實，我從來不認為可以通過筆試題目就能為公司招來一個性價比高的開發人員，而且有很多面試題我覺得出的根本毫無意義，尤其演算法類的，為什麼這麼說？有多年工作經驗的程式猿都有這種感觸，演算法在實際程式設計中用的其實並不多。演算法重不重要？非常重要！但是，大部分的時候，我們只需要瞭解演算法的效率，是幹什麼的，大概能在什麼地方用，就已經完全足夠了。很多現代的程式語言，都已經內建了許多的演算法，而其他很多不常用的演算法，網上也有了足夠的討論和現成的類庫，如果你不是專門搞底層開發，圖形類演算法的，沒有必要花費太多的精力在演算法研究上，所謂術業有專攻。
我舉個例子，我在工作中遇到了一個問題，如果有非常大資料量的資料需要繪製曲線時，曲線的繪製非常非常慢，因為有大量的資料點要去渲染，而且繪製出來的曲線時密密麻麻的，很難反應趨勢。後來我是怎麼辦的呢，我研究了下，我們是否可以通過減少非關鍵點來壓縮曲線，只需保留有關鍵特徵的資料點即可？但是怎麼壓縮，我並不會，也沒有理論支援，最後在網上搜索曲線壓縮”，立即得到相關的演算法，用上去之後，曲線描繪的速度大大的提升，而曲線的趨勢又得到了保留，非常完美的解決了相關的問題。
但是，我認為筆試題目還是很有意義的，它的意義在於，能夠從側門反映你對基礎知識的瞭解程度，更重要的是，可以從做題的過程反映你這個人的一些程式設計的細節，面對困難的解決思路，以及基本的邏輯思維。
注重細節
我們有道題目是這樣的：
| 1 2 3 4 5 6 |
struct
Node
{
string
name;
List<Node>
children;
}
void
Travel(Node root);
|
Q:函式說明：root是一棵樹的根節點，Travel函式可以遍歷該樹的所有節點，並打印出每個節點的name。
非常非常的簡單，但是，很多有經驗的程式猿答的並不好。完成這道題可以採用遞迴的方式，遍歷子節點並完成列印，但是中間有個細節是List<Node> 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，或者乾脆提出一個開放式的問題，讓面試者設計一個日誌記錄器，看看他到底會考慮哪些因素，從而判斷他是否掌握了相關的除錯能力。
專注並自信
最後，我想說的是，面試是一個非常主觀的事情。你從上述文字應該也可以看出，我的面試，其實就是我個人的想法，我對跟我共事的同事的一個要求。其他公司或者其他面試官，或許又有其他的要求。但是，這都沒有關係。你只要在你的領域有足夠深入的瞭解，而且又有解決問題的能力，那麼，你總會找到自己想要的工作的。如果你暫時沒有找到，只能說你還沒有遇到你的伯樂。就像我們公司一樣，拒絕你，或者是因為覺得公司的要求或者方向不適合你，或者是因為公司給不了你這個薪水。無論哪種，都不是因為你的能力的問題，我們沒有理由沮喪。優秀的人在哪裡都能做出優秀的成果，但不是在哪裡都能做出偉大的成績，我們應該要有足夠的耐心等待。
我們在來回顧一下面試中有哪些地方是體現程式設計師的核心競爭力的，看到結尾的或者直接拉到結尾的，就請默默點個贊吧：
- 簡歷
- 檢索能力，解決問題的能力
- 學習能力，組織的能力以及整體思維
- 筆試
- 程式設計細節
- 面對困難的能力
- 做事的方法、態度
- 面試
- 技術的深度和廣度
- 對專案的瞭解程度、做事的方法態度、學習能力
- 程式設計的思想：產品、細節、業務、溝通、架構、除錯