如何辨別一個程序員水平的高低？

12-27

工作3-5年，大家都做過點什麼？但是有的程序員只是技術遷移、完全沒解決問題的能力啊？大家盤點下，在你眼中，高工作年限的程序員，技術水平差是什麼樣子？
問題一來讓大家了解下，技術差是給別人是怎樣的一種體驗，二來是告訴大家如果自己有這些方面的問題，趕快成長，努力修補。

給他安排debug的任務，最好是崩潰問題或性能問題，觀察他面對大量複雜的代碼，在信息不全的的情況下，看他怎樣一步步抽絲剝繭縮小範圍，最終定位根本原因，並且給出一個不錯的fix。

如果能獨立完成工作，那麼以後必然成為高手。
如果經過少量提醒點撥也能完成，以後會是個不錯的程序員。
如果需要不斷提醒，只能按照我給的思路去反覆測試調查，那麼只能說是個踏實肯乾的人，但天賦不高，可以委派些普通任務。

如果以上皆非，我基本就放棄對他的治療了。

之所以選崩潰或性能問題，因為這種問題沒什麼玄學，行就行、不行就不行，結果好驗證。
這種問題很考察基本功，可能對操作系統，語言，編譯鏈接器，內存，進線程，網路，存儲，圖形學都要有深刻理解，也很考驗邏輯推理能力，在一堆證據中構建合理的證據鏈推導出最終結果，懂得大膽假設小心求證的工作方法，也考察耐心和毅力，有的問題需要構建複雜的測試場景，還要反覆多次測試才能重現，考察溝通能力，複雜的bug可能涉及多個部門開發組，可能還要對最終用戶做訪談。

判斷別人水平的最好方法是提高自己的水平。一個程序員可以容易的判斷比自己水平低的程序員的能力。當你看到一個程序員犯過多少自己當年犯的錯誤的時候你就很清楚了，不然他很可能比你強，不過你很難判斷他比你強多少。

先放觀點：
辨別一個程序員的水平唯一的辦法就是看 產出質量。
關鍵字：普通程序員
——————————————無恥割————————————————————
演算法和數據結構都是錦上添花，並非是雪中送炭。而一個程序員的水準大致上是可以通過之前的代碼質量估算出來的。【如果你可以獲得此程序員的真實編寫的代碼，比如原創的Github】。
舉個栗子：下面是我最近在單位一個同事寫的代碼，Java語言

private boolean checkProportions(String str, Integer grades) { String proportion = str; for (int i = 1; i &< grades; i++) { String st = proportion.substring(proportion.lastIndexOf(",") + 1); if (st.equals("")) return false; proportion = proportion.substring(0, proportion.lastIndexOf(",")); } if (proportion.equals("")) return false; str = str.replace(".", ""); str = str.replace(",", ""); for (int i = str.length(); --i &>= 0; ) { int chr = str.charAt(i); if (chr &< 48 || chr &> 57) return false; } return true; }

大致上的功能就是將 1,2,6.2,4,1 的字元串判斷每一『,』內是數字，而且長度符合規定
這樣的代碼看上第一眼就覺得非常的醜陋。所以在我的要求之下，進行了一次重構。

private static boolean checkProportions(String str, int grades) { String[] proportions = str.split(","); if (proportions.length != grades) { return false; } for (String s : proportions) { if (!NumberUtils.isNumber(s)) { return false; } } return true; }

這裡看上去差不多就Ok。這樣的代碼其實也並沒有用到什麼數據結構和演算法，就是很簡單的字元串處理。

實際情況：在我們寫的絕大多數的代碼裡面，大部分屬於業務邏輯，極少部分的代碼需要使用到演算法和數據結構，在這樣的情況下，我們能使用的到的技能最為關鍵的是讓代碼如何更加合理。而讓代碼更加優秀的方式是通過千錘百鍊的重構，而重構是極大的考驗一個程序員耐心和能力的東西。

—————————————————————————————————————
質量的範圍廣泛，我從下面幾個小方面聊聊。
出貨能力：如果一個程序，演算法再精妙，不能出貨都是扯淡，我看過某某大神，演算法溜得很，但是一個人完全做不到按照工程需要把事情給做完。
優化能力：並沒有一個程序是一步到位的，一個工程的交出去可運行了，那才是第一步，很多時候隨著業務的增大，對性能的要求越來越高，有一定對於代碼優化的能力也是比較重要的。
調錯能力：項目越大，遇見的Bug也就是越離奇，這個時候需要強大的Debug能力，找出那個最為關鍵的錯誤點，甚至於追溯底層框架的源碼。
技術掌控：你項目能用Spring，Hibernate等等框架，但是有沒有想過，這些技術你真的可以掌控么，如果有一天你的框架版本需要升級，真的做得到么？甚至於從Hibernate轉為MyBatis。

演算法和數據結構是影響到一些核心區的問題，但是其他的一些技能，比如面向對象的架構設計，代碼的低耦合，那都是對整個項目有著直觀改善的技能。並非是貶低演算法，而在實際工作中，有太多比演算法更重要的問題了。

最後補充一點吧：從善如登從惡如崩，毋以惡小而為之，此古人誠不欺我。

這個問題是每年招聘的時候都會遇到的問題哈！正確的問法應該是怎樣在比較短的時間內辨別一個程序員水平的高低。因為如果給你個三五年的時間天天盯著他，估計什麼方法都是好用的。而這個過程需求量最大的時候就是招聘的時候，候選人太多，要迅速篩出來優質的苗子為公司所用。

首先第零點公理，相同的方法，時間越長，辨別度越高。這個上面也提到了，你花在一個候選人身上的時間越長就對他了解的越多，對他綜合素質的評價就會越準確。所以下面就不說時間的事情了，說說我們公司招人時候的一些點吧。

第一，知識的考察。這個是幾乎每個公司都會做的，也是很有效的手段，基本就是考試。包括問語法問標準演算法問API問一切有標準答案的問題。一個人懂得多，不一定寫得特別好，但是什麼都不懂一定寫不明白。這個方式還可以按需求選人才，比如我們就在php做前端，那我就可以問一堆關於php的，如果我是做嵌入式的，那我可以問一堆c。可以考察這個程序員在和公司需求的交集上完成的怎麼樣。這也是最最簡單和直觀的方法。

第二，對過往項目的理解。這個也是在簡歷關很常問的，說說你當時做的這個項目吧。這個問題非常有效地考察了他是否理解他之前做的東西。有的人簡歷寫的巨漂亮可是實際那項目和他沒關係，或者他就是複製粘貼的代碼，其實自己啥都沒寫。這種時候你和他聊的足夠深入之後能很明顯地發現他自己說不明白了。同時還可以考察一定的語言表達能力和邏輯能力。用我們的話說，先問到面試官不會的深度，然後讓他給面試官講明白。如果他做的東西，他蒙圈的時候比面試官還早（前提是面試官不是搞這方向的），那一般就比較悲劇了。

第三，對寫程序本身的理解。我們很喜歡問一道題，描述一下你是怎麼寫程序的。凡是說我事先design好所有的模塊、介面、功能，然後逐一實現，然後程序就work的，我們都心裡默默補上「呵呵」。因為這是不可能的，只能說明他沒寫過大程序或者沒總結過寫程序的經驗。沒有人在完成一千行以上的程序的時候在沒寫之前就做好所有模塊設計的，何況更大的程序。當然還有就是他會不會認為程序跑通一次就完成了（即寫程序有沒有test階段）之類的。

第四，動手寫程序的能力。這個說實話是面試的時候不太容易考的，因為時間有限。現在的大公司基本是45－60分鐘一輪，一輪還要問好幾個程序題，所以寫的代碼都是片段的，大概20行左右，根本沒法體現一個人會不會寫程序。所以很多人不需要會寫程序，只需要刷好leetcode之類的演算法題庫就可以進大公司（相信我我認識很多）。我們認為一個好的程序員一定要在限定時間之內完成一個完整工作，滿足要求的程序。從輸入到輸出到corner case的驗證。而不僅僅是研究明白某個基礎演算法如何用nlogn而不是n^2解決。這一關卡下去了無數看起來很美好的人。因為我們的題目是不可能在那個時間內找到最優解的，就像絕大部分工程中的編程一樣。一個較好的可用解往往比最優解要有價值的多，因為後者需要大量的時間，很可能沒有前者直白，而且提升未必很高。這是我們公司最在乎的一點。

當然，這說的都是面試過程中的方法，如果你想辨別同事是不是厲害，問問他就行了。

要判斷別人水平怎麼樣，自己先要有一定的水平。如果別人的水平比自己高出很多，很可能本人是感覺不出來的。

因為本身自己就是程序員，創業到現在都是做技術驅動型的產品，團隊一直在大量招聘高水平的程序員，所以對這個問題做過長時間的思考。簡單的說一個高水平的程序員大概有幾個特點：

聰明。應該說智商夠高，情商也不差。
學習能力好。
基礎知識紮實。
動手能力強。

其實這就是對一個優秀的工程師的普遍期望，不僅僅局限於程序員。

針對題主的問題，大致談談一些體會：

基礎知識

這幾年大學擴招，互聯網企業人才需求量大，造就了一個現象，很多業內的從業人員，嚴格意義上來說並不是一個合格的程序員，最突出的特點就是普遍基礎知識欠缺。
我們在招聘的過程中，一般我們會問候選人幾個簡單的計算機基礎知識，比如 CPU 原理、操作系統原理或者是網路原理，有人就會回答，給我一個具體的需求，我們可以把東西做出來，但是問這些說不清楚，或者是記不得了。
其實我們日常工作接觸到的很多特性，往往是由 CPU、操作系統的特點決定的，不理解這些原理，我們以為自己理解了的東西，並沒有真實理解。
以職業學校的培養方式培養出來的人，幾乎沒什麼發展前景，水平很難提高。

學習能力

軟體開發是一個知識迭代很快的事情，了解現有的理論和技術，對拓展思路、提高效率至關重要。
這種大量、高頻率的學習，都要靠自學，等老師、高手來教，幾乎不可能。
業內有這樣的情況，程序員在考慮一個問題的解決方案時，只看自己現在會的技術能解決到什麼程度，而不是廣泛的研究所有可能的方案。這也會制約水平的提高。

先寫這麼多，關注多再加內容。

-------------
評論里幾個抖機靈的把無知當有趣，基礎知識欠缺需要的是學習，抖機靈不能幫你提高。

不要問面經上有答案的問題
問一個開放的問題
問他沒有遇到的問題
看他的解決思路（包括思考方式、求助方式等）

再重複一遍，不要再SB一樣的問他JVM內存分幾代的問題，問快排怎麼實現的問題，問javadoc能查到的問題。。。
那樣只會招到會背書的程序員（或者經過北大青鳥培訓的）而已
多問點開放性的、與你的工作場景中真正相關的問題

隨口胡謅兩句，各位看過權且笑笑

單講程序員，不討論學術界。

入門之後的新手，喜歡談演算法，這是什麼什麼問題，用什麼什麼解。
比如異或交換變數，不用四則運算實現加減法，這個問題本質是位運算，那個應該是 blahblah…… 幼稚。

做了幾年後（有的甚至做了很多年都這樣），執著於談技術，你做了什麼項目多？你會什麼技術？
比如要約人去 GitHub 寫 tokenizer、資料庫什麼的
比如我在這個回答中的大部分問題，可以說是愚蠢之極。如何面試 iOS 工程師？ - 蕭井陌的回答
技術都是可以、甚至可以輕鬆學會的，並不是什麼問題

一個人的思想、性格、對世界的認知、對問題的看法、決策的取捨，這些才是對程序員來說最有意義的。

低手永遠不要去評估高手的水平。你說不定都看不出來他比你高……

我覺得辨別一個程序員當前的水平高低和預測一個程序員未來的水平高低是兩個問題。我個人更贊同 @蕭井陌的觀點，從性格、氣質、三觀、視野的角度會看出一個程序員未來的潛力，如果面試官是把招聘的過程看做為自己挑選搭檔，以及結識值得交往的朋友的過程的話，我覺得這個思路完全沒問題。

我想吐槽一下現在企業招聘，尤其是初創企業招聘時一個誤區「期望通過普通招聘流程找到一個可以獨當一面的人」。我個人的判斷這是一個極小概率事件，跟中彩票差不多，如果你期待能在企業經營中種這個彩票，這簡直是個愚蠢的企業決策。

首先，必須要承認，優秀的人是少數的，到底有多少，我按照「二八法則」粗略給出一個比例大概就是20%的20%的人，即4%。也就是說在中國自稱程序員的人種有20%是合格的程序員，而在這些合格的程序員中有20%是精英程序員（可以理解成題主所說的高水平程序員）。而精英的人之所以是精英幾乎跟工作年限沒有正比例關係，太多的人是用一年工作經驗工作10年了。我通常認為能在一個領域達到精英水平的人擁有的共性一般是，富有遠見，三觀正確，性格特立獨行的人，他從事某種職業只不過是機緣巧合，其實只要他喜歡，即使從事別的職業也能進到這4%的精英群體中來。

接下來，問題就來了，如何才能招到這一小撮人呢？第一招，英雄惜英雄。用一個本身就是精英的面試官去招聘，通常精英面試官的社會影響力會吸引一些高水平的人。而且一般優秀的人在遇到優秀的面試官時能更充分的展示自己的才華（因為他知道對面會理解他的某些行為和想法，而不是對牛彈琴），而且更容易被說服留下來。第二招，「樹大招風」。大企業自然會吸引很多人關注，對於很多優秀的人才，他們當然更喜歡在更高級別的企業工作，而且大企業也更容易打出第一招的牌。第三招，畫餅洗腦。當然我指的不是騙人的那種「畫餅」，而是企業雖小，但是真的是一幫有情懷有理想的人組成的，恰好有熟識的朋友是大牛，用期權忽悠過來。第四招，有錢能使鬼推磨。開出高出行業標準2倍甚至以上的薪水去其他公司的核心崗位挖人。

看了上面的四招，讀者可能會說我也沒拿出可行的辦法鑒別高水平程序員嗎？其實我是想說，你以為提個問題，看了別人的回答就能學會鑒別高水平程序員了么？要知道在古代，鑒別馬匹的優劣是有一個職業叫做「伯樂」，後來引申為能識別出優秀人才的人。鑒馬尚且不易，更何況鑒別人。我認為能鑒別一個程序員水平的唯一辦法，就是讓高水平的程序員與他共事，然後看一下這名高水平程序員的工作滿意度就好了。

最後，我覺得討論演算法，debug，編程速度什麼的都屬於玄學的範疇了，我是不信真的能通過這些指標能判斷出這4%的精英的。這些東西，充其量能大致判斷20%合格的程序員都不易了。人類有放大自己優點的天性，很多人都（誤）以為自己是高水平的，我覺得這沒有問題。但問題在於，有些人認為自己水平足夠高了，不需要在進步了。而另外一些人認為，自己水平挺高的，所以應該更進一步。這就是為什麼我衡量一個人是否是高水平的時候，更在意一些內在的，固有的人格，人性上的品質，而不是徒有其表的技能列表。漂亮話誰都會說，實幹家甚少。

面試時，我喜歡問對方以往開發中遇到的問題。
比如:「聊聊你上個項目遇到最棘手的問題」
看看工作經驗和對問題的理解。
有時會插入幾個假設的限制，比如「如果同樣的情景中，計算的規模提高10/100/1000倍，怎麼辦？」
問題不局限於某方面，為的是聽聽他解決新問題的思路。
然後聊聊業餘的興趣愛好，比如主要的閱讀媒介、比如喜歡的遊戲。順便了解性格與自學能力。
能從搜索、文檔中唾手可得的信息沒必要深究。只要確定他有自學的能力即可。

我認為程序員水平的高低直接體現在對問題理解的深刻程度。

眾所周知程序的精髓在於演算法，一個程序好不好，毫無疑問應該看它的演算法好不好，這直接影響了程序解決問題的正確性和效率。而演算法的實現又強烈依賴程序員的抽象能力及理解能力。

舉個栗子，之前我回答過一個問題：做了一份前端面試題，有兩道沒寫出標準答案？ - 前端開發

給定一個list，元素都是正整數，要求返回這些元素組成的最大數。例如 [5,3,31,2]，返回 53312

對於這道題我當時理解不夠深刻，開始用遞歸解決的，後來想了半天又寫了個更簡單的方法：

可以看到，這兩個方法的代碼量差了一倍不止，卻解決的是同一個問題。
如果這兩個解法是兩個人分別寫的，那麼顯然可以說，後一個人的水平比第一個人的水平高，因為前一個解法只是單純的「解決」了問題，後一個卻看到了問題的「本質」。
而往往，對於本質的解法是 simplest 的，卻是 most difficult to come up with 的。

-------------------------------------------------------------------------------------------------------------------

再來看一個面試題：

100個人排成一行，分別以1、2、3……編號，從這些人中選出偶數號的殺掉，剩下的人重新從1開始編號，然後再選偶數殺掉……如此循環直到只剩下1個人為止。請問你要站在哪個位置才能保證存活時間最長（除了1號）？

這個問題如果是第一次看到，相信大多數人拿到手裡都沒什麼頭緒。然後有的人可能會試圖去找規律，試圖去在腦中演繹，試圖去從反方向逆向推出結論……

如果我現在告訴你，這道題考的實際上是二進位，你會怎麼想？覺得不知所云？亦或是突然找到了靈感？

其實這道題很簡單，掌握了方法之後無論題目說有多少個人都能在 1 秒內得出答案。

對於這道題，答案是 65。

把總人數轉成二進位，110 0100
除了最高位其餘都變成 0 : 100 0000
把這個數轉成十進位再加 1

其實也就是不超過總人數的 2 的最大次冪再加 1 。

對這道題思考的過程，其實就是一個人理解問題的過程。這方法看似簡單，毫無技術含量，卻不是所有人都能一下子發現的。
如果不信，可將此題發給身邊的人，讓他們說出思考的過程。許多人都會需要進行大量的演算、比較、試驗後，才能得出一個類似數列的通項公式，卻還是不能抓住本質。

看到問題實質的能力，是通過經年累月訓練出來的，不是一下子能夠完成的。

-------------------------------------------------------------------------------------------------------------------

題主問的是「如何辨別」，那麼觀察一個人的思維方式是最簡單直接的方法。

給他/她一道題（可以是抽象問題或實際技術問題），告訴他/她不用解，告訴我你是怎麼想的。對於比較難的題目來說，一般人都不能一下說到本質，但隨著思考的深入，水平差異就體現出來了。屢試不爽。

最後，給大家留一個題目，有興趣的話可以拿來訓練一下自己。不要去百度上搜，我看過了答案都是錯的。

有 12 個外觀相同的球，其中一個的質量與其餘不同。用一天平稱 3 次找出這個球。

祝大家思考愉快。

前面幾位都很有道理。

依我看來：
評論一個程序員技術的高低，不是看他會多少技術，又懂多少技術。參加過什麼大型的項目，也不是看他有沒有自己的博客，github有多少star。

而是看他解決問題，定位問題的能力。

這個很重要，真的很重要。

技術可以很快上手使用，但是解決問題定位問題的能力不是輕易就行的。特別是在高壓下解決問題的能力。

舉個例子：
小天：老大，這裡怎麼沒有執行成功呢？代碼我從其他地方拷過來的呢！

老大：報異常了沒有？

小天：報了，說的是文件導入失敗，可是我的文件寫入的方法沒有問題呀！

老大：你看看人家怎麼寫的

小天：人家沒寫這一塊，只有我這裡才需要對文件內容進行特殊處理

老大：那麼問題就在這一塊兒了。（縮小問題範圍了）

小天：我只是把文件內容寫好了就導入了資料庫了呀！

老大：資料庫導入文件那個我看了是公共的sql，沒問題。

小天：你看我文件寫入這一塊的代碼嘛，沒啥問題呢，我看了文件內容都是正常的。

老大：既然如此，那麼肯定是導入的時候存在問題，但是公共方法是可行的，肯定是你的文件格式有問題，你調整一下文件的編碼試一試。

。。。。。。。。。。。。。。。。。。

小天：老大，搞定了，果然是文件編碼的問題，不同的編碼讀取的位元組長度不一樣，資料庫總是以它認為的編碼去讀取，保持編碼一直就行了。

老大：好的，我知道了。

從始至終，老大沒有看過代碼。

牢騷幾句，和答案關係不大，但是希望能幫到你。

面試面試，其實考的是面試官的水平。很多人說，看出一個人的水平是你要比他強就是這個這個道理。

技術崗位很有意思的地方是每個公司的要求多多少少都有不一樣的地方。面試官經常犯的錯誤是以己之長量彼之短，陷入到比較技術的本身之中。最後面了很多得出結論，水平都不行啊。

最有效的面試私以為就是面試他擅長的知識和經歷，這樣最能考察出一個人的優勢。當然了，這條有個前提，就是在基本方向滿足的前提下，你要個做資料庫的，結果來了個做圖形圖像的，你還要去迎合他去問他領域的問題，那不就扯淡了嗎。

還有人會說，那他的劣勢就不考察了嗎，當然要考察。但是這個又是個辯證，你找個人不就是要利用他的長處嗎，就好像你要個前鋒，你偏說他防守不行，這個也挺扯淡的。

總之，如果自己無法分辨他人水平，可以請個信的過的人來幫忙看看。面試者面試官能相識一場也是緣分，多花點時間非常值得。

我定義自己的核心競爭力第一條就是debug能力。

debug能力是在豐富經驗的基礎上，以敏感的判斷迅速確定問題出現的環節，而這個過程如果是在眾人圍觀定位線上bug的情況下，心裡滿足感瞬間爆表，這就是我們常說的「消防員」。

所以debug要求豐富的經驗、廣泛的知識面、紮實coding能力（包括熟記各種命令參數）、敏感的判斷。就PHP在我看來，debug能力可以分以下幾個層級。

A 刷新頁面，出錯，百度，修改，刷新...

B tail -f php_error.log，刷新頁面，修改，刷新...

C 開發環境列印：var_dump，線上寫到文件：file_put_contents + tail
當然也有些同學會覺得var_dump這名字寫得太長不方便，重新定義一個d =&> var_dump，dd =&> var_dump + die，贊一個，畢竟排錯越快越好，尤其是線上問題。到了這裡，基本都會做，以下沒有太強的等級性，有些是平行的，如網路和進程。

D 還有一些稍微需要配置的debug工具，如xdebug，xhporf，wincachegrind，php/mysql慢日誌分析，這些的話，基本需要優化的點了

E 需要對這個PHP腳本進程做更細粒度的debug，ps查找僵死進程，strace -p php進程id來查看一個僵死進程現在是在做什麼，因為什麼原因。

F 如果是web端，從請求到nginx到php-fpm到php文件到log文件，確定問題在哪一環節。可能你需要tcpdump這個粒度到三次握手的數據包工具來debug有部分請求出現499，是系統、nginx、php-fpm參數設置不當？還是php進程被長時間腳本佔用，沒有及時消耗nginx的隊列。或者最近遇到的一個很神奇的問題：php輸出一個標準json_encode(array)，web端得到的居然是一個array亂序的json。

G 如果是有開發php擴展需要的同學，必不可少的就是gdb和.gdbinit zbacktrace，當時在開發ip2city擴展的時候，出現core dump，也只有靠它了。

H 待補充

好吧，這些在面試的時候得找到很合適的例子，才能讓展開思路。

但有另外一個可以直接看出一個工程師的能力，那就是github，代碼規範一覽無遺，邏輯層次，模塊設計能力，注釋說明，異常處理等等，那就已經把這個工程師釘死在哪一個水平了。目前致力於

代碼部署系統：瓦力(meolu/walle-web · GitHub)、內網文檔框架瓦爾登(meolu/walden · GitHub)，歡迎fork試用、標star什麼的：）

下文有不滿和戾氣，可能還有以偏概全，願意指點一二的，麻煩評論個，先謝謝！
＝＝＝＝＝＝邪惡的分割線＝＝＝＝＝＝＝＝
以下都是很好的回答：
怎麼成為一個優秀的程序員，而不是一個優秀的碼農？ - 知乎用戶的回答@蕭井陌
如何辨別一個程序員水平的高低？ - 姚冬的回答
如何辨別一個程序員水平的高低？ - 知乎用戶的回答
如何辨別一個程序員水平的高低？ - 知乎用戶的回答
如何辨別一個程序員水平的高低？ - Vkki 的回答
如何辨別一個程序員水平的高低？ - 吳水永的回答
如何辨別一個程序員水平的高低？ - 紀路的回答
如何辨別一個程序員水平的高低？ - think123 的回答
如何辨別一個程序員水平的高低？ - 汪淘的回答
如何辨別一個程序員水平的高低？ - 白喬的回答

一句話，是騾子是馬，拉出來溜溜就知道了！

＝＝＝＝＝＝以下的嫌棄太長的就不看吧＝＝＝＝＝
個人經驗的補充：
1.代碼的命名真的很重要，很重要，很重要，很重要。
這樣的代碼我就不貼了，每次看到我都有忍不住重構的衝動。
代碼是寫給人看的好嘛！代碼是寫給人看的好嘛！代碼是寫給人看的好嘛！

headImg 是什麼鬼？我能以為是banner么，頭部的圖片，請原諒我蹩腳的中式英語！
avatar 這個呢、portrait 這個呢？會不會更好些？英語不好就不能用好有道、google翻譯么？
還有用中文拼音命名的，親，我們用的是英文做為腳本好么？
你要用這樣的，用易語言可好？！

為什麼要用框架？一個很重要的原因是命名規範，目錄規範，結構規範，分層規範，
有利於團隊協作，不要本末倒置！

2.架構和規劃能力很重要，模塊分層，解耦設計什麼的，文件目錄嵌幾層？
這其中又跟命名的能力能搭上點關係。命名都命不好，目錄結構怎麼建？
url不要做的漂亮些嗎？不考慮seo了？
你喜歡 addGoods 還是喜歡 goodsAdd ? 請你尊重點我的那些初高中英語語法好么？

3.協助能力、可持續能力。
API考慮過兼容性沒，為後續的維護考慮過沒，考慮過這段代碼可能承載幾十萬並發沒？
那些什麼動不動就上了問 auth2 你了解過嗎？ mongo你用過沒？ redis呢？memcache呢？
一個工具罷了，問的問題有多lower啊？！
就不會問，什麼情況下 memcahed命中率就不行了？怎麼提高命中率？使用場景適合哪些？
那如果我說，不好意思，mongao我沒接觸過？你一杆子打死我么？
還有，不要說什麼，額，工期趕，沒時間做優化，呵呵達， @Vkki 、 @夏岩他們怎麼能寫出來？

代碼能寫的清晰些么？ if嵌套可不可以不盡量使用？
用array 代替 switch 可好？代碼越精簡不好嘛？多動了下腦子，少寫了幾行不好嗎？

head做變數初始、參數檢查、環境檢查
body做業務邏輯，
if里做返回，外面寫邏輯可是能省幾層嵌套的，這你可知道？
foot構造返回結果。
這個樣的三段式如何？

&db-&>createCommand($sql)-&>bindValue(":isdel", CUser::ISDEL)-&>queryAll(); if(empty($user_ids )){ return false; }


     if(!$this-&>activateUsers($user_ids)){

        return false;

     }
     $this-&>xxxxx($user_ids);

     $this-&>xxxxx($user_ids);

     $this-&>xxxxx($user_ids);

     $this-&>xxxxx($user_ids);
     $result["user_list"] = $this-&>xxxxx($user_ids);

     $result["xxxxx"] = $this-&>xxxxx($user_ids);

return $result; } }

上面的是否比你們的if(xxx){}else{if(xxx){}else{}} 閱讀性強很多？

比如設計個支付功能，你是如何想的？支付網關這麼多家，API腫么弄？
要不要繼承抽象再具體實現，對外暴露統一介面，內部再細分實現？
見過直接拿鵝廠的api直接引用的，自己都懶得再封裝一次，
就沒考慮過還會用支付寶，財富通，匯付通、xxx通了，接入一個用一套嗎，不統一管理？
實現後台可配置可切換，脫離程序汪，後人只要繼承抽象類，實現api就好，不優雅嗎？
簡訊網關腫么做？可不可以實現和處理支付的方法一樣，實現插件式、可切換、低耦合？
你們不是學了各種設計模式嗎？以上就可以秀什麼工廠模式、單例模式、監聽模式等等等。
你們幾個這麼想過的？從系統層面、運維層面考慮過沒？
有為後面可能為你擦屁股的同事考慮過嗎？
那麼請問，如果要你寫個資金託管功能，你怎麼寫呢？

資料庫的欄位屬性設定可以在模型里做常量定義么？
你喜歡在業務變化後，欄位屬性變更後，改SQL代碼的時候四處查找替換么？

你就是喜歡配置寫在代碼里，就是喜歡沒有考慮過使用配置文件要麼資料庫。
你就是喜歡客服沒事告訴你這裡有問題，然後你去改個代碼再上傳的鬧騰下，
顯示在救火，刷我還存在，刷我很厲害的樣子。
其實你不知道，最好的程序代碼是脫離其產生者的。
為自己程序處處救火的程序汪並不是一條好汪。

我記得一句話就是：別想著你的代碼以後還有機會重構！
每次說，額，這裡我後面會改的，會改的，但是可惜，現實情況是根本不會給你這個時間的。
代碼寫出來，一是要爽了自己，二是也要爽了別人。

4.debug的能力、總結能力、學習能力
真的很重要，代碼寫出來真的花的時間不長，但擦屁股的時間比寫代碼的時間多多了！
出了問題不記錄，寫個博文都好啊，我可沒那麼強大的記憶力，所以最討厭考記憶力。

5.不要一貫的使用各種演算法，秀演算法的你們夠了，要寫去寫底層，應用的場景比較多。
應用層面的程序，演算法的應用不是特別多，大部分都是業務代碼。
以這個作為評價標準的，真心然並軟。
你們要面試，麻煩你們出題的時候好好結合實際好么？
哪怕出一個你當前手上的任務為題目也好啊！

6.有github是加分項，有博客是加分項！？
我還真沒見過幾個面試官面試的時候跟我說，我看過你github、你博客中的某篇文章不錯什麼的。
沒有，真沒有，面試官那種浮躁的要死，面試官也時脫產來面試的，根本沒有時間看嘛。
但搞的好像沒有github、博客就沒有競爭優勢似的，大家都註冊成風了，尤其是新人！
我寫博客只是記錄和分享我的經驗的，不是來給你們加分的。

7.論大公司的面試（有點口水，不看唄）
有幸被騰訊面試了，是的，鵝廠，可惜是委託面試。被各種虐，是的，真的覺得自己的不足。
開口各種關鍵詞，而且是英文縮寫，各種沒聽過，真的，我真沒有聽過，，，
恕我一直在二線城市，我沒有靠譜的大平台能參與，也沒有高並發，很少用的大數據統計分析。
但，我只是面試個外包企業啊，有必要扯那麼多犢子嗎？
建站公司，外包公司什麼尿性，也是做人才儲備嗎？

我承認問這些的必要性，因為鵝廠招人，是去做人才儲備的，基礎不牢靠肯定不要的。

同事的哥哥是鵝廠的，也聽過一些面試的小消息，
對於社招的，不內推，要進去真的很難！
HR都是設置自動篩選機制好么，沒有達標的直接不看好么！

英雄不看出處真的不是處處都有的！投遞簡歷的方式，學歷是硬傷！

不見得我的潛力就沒有本科的好，但這也是招聘的無奈，因為不通過實際的工作，
根本看不出一個人的能力長短，但招聘的時間比較短，只能通過一些明面的東西來篩選了。

公司的大半同事都是推薦的，包括我，也是被人推薦給boss的(不知道是誰推薦的)，
然後CTO主動電話面試。

如何面試 iOS 工程師？ - 知乎用戶的回答
裡面的各種奇葩問題，對，就是要用奇葩！
因為有人曾經問我，無限極分類怎麼寫，呵呵，我只回一句：循環調用！

8.識人才難，成人才更難！
HR很多都是良莠不齊，而且還有噁心的！

其實要懂行的人聊十分鐘就知道對方的水平了比如fp領域大概聊一會我大概就能知道對方的段位了

1）通過人氣辨別
很簡單，你就看周圍是不是經常有人去請他解決問題，其他項目出現技術問題，是不是有人第一個想到他
2）水平高低大家經常只關注技術層面，作為一個牛逼的技術人，
能不能影響周圍的人一起學技術，鑽研技術，做一個技術極客團隊

能不能把技術很好傳承，自己牛不算牛，整個團隊牛，那才叫牛逼，

兩個能不能也是我們現在很多技術團隊最欠缺的，開放分享才能促進自己更大的進步

可惜啊國外的面試全特么面演算法，其實我也發現了，國外做底層的人太少，也沒有人願意去把一門技術吃的很深。

第一點：能不能出活。如果不能出活，吹的再牛，也只是吹。沒活，什麼都不能評價，就沒有後面的幾點了。
第二點：能不能長久穩定的出活。產量很重要，如果能出活，但很久才出一個，自己都無法預計自己的工作量的，非新人莫屬了。
第三點：凡是出的活都負責到底。我見過很多程序員新人，只喜歡做新東西，凡是做過的東西就丟在一邊不去管它，久而久之，凡是他做的東西，團隊內的人都敬而遠之，他個人的聲望也在團隊里降低到底線。當然還有不少程序員新人，對自己做的東西絕望了，然後就放棄治療了，這樣的程序員肯定也算不上好的。
第四點：質量高的出活，出的活別人都搶著維護。大家當然願意維護容易維護的東西了，如果一個團隊里，出現某人寫的東西，大家都樂意在上面繼續開發，以及使用。那說明確實很牛了。反之，某人寫了一個工具模塊或者中間件，大家都不願意使用，即使非得使用，也滿是吐槽。那隻能說明水平還有待提升。
第五點：解決問題的能力。這個和出活還不一樣，幹活只需要體力和腦力的付出。解決問題需要的能力比幹活高很多，大部分時候解決的還不是問題本身，還是問題的人。這不但需要很好的體力和精力，足夠的智商，還需要不低的情商和手段。

從debug的思路去觀察，高手總是能從細微處找到突破口，然後靠知識面不斷的假設驗證假設驗證，進而層層深入