最近參加一個技術社區活動，在討論到“CTO的技術深度和廣度哪個更重要”的話題時，我想起社區里面常常提到的“全棧工程師”的事情，于是表達了一些觀點。臨場未必能夠清晰表達，所以下筆，希望能夠引起一些討論，避免年輕工程師誤入歧途。

長期以來，社區就有人在提“全棧工程師”，還有一些公司直接掛出名為“全棧工程師”的招聘職位。那什么是全棧工程師？

百度百科的解釋是：全棧工程師，英文叫Full Stack Developer，是指掌握多種技能，并能利用多種技能獨立完成產品的人。說白了就是啥都懂的人，左青龍右白虎老牛在腰間，人擋殺人佛擋殺佛。想想，一個項目從前到后要包含多少技術？就拿TalkingData來說，就至少有H5、JavaScript、CSS、Java、Kafka、MongoDB、Redis、MySQL/MariaDB、Vertica、Hadoop、Spark、Tychron等等，這些研發目前需要數據可視化團隊、計算平臺團隊、存儲平臺團隊、數據挖掘團隊和運維團隊來共同完成。要是出現這么一個全能王，把活一攬子全部接下來，那要省掉多少溝通代價和薪資成本？——這簡直就是救世主！

想到這里，我頓覺慚愧，十幾年的技術算是白搞了，要是剛畢業即以此為目標，每個月學一門，學完一門換一門，那用不了兩年就能轉職“全棧工程師”這個終極職業，站上技術巔峰，俯瞰蕓蕓眾生——是不是有一種游戲開掛的快感？想想做個架構師都需要四五年的辛苦積累，現在能兩三年速成，豈不是很爽？

終于，在這樣自我催眠，加上一些輿論的刻意引導下，大批有志青年開始走上全棧工程師的自我修煉之路。沒有多少人愿意腳踏實地積累自己的技術經驗，或者潛心去研究開源技術的底層代碼，或者做更深入的性能對比分析。很多人閃電般的在不同公司之間跳來跳去，走馬觀花，狂熱浮躁。

這幾年，因為大數據需求的不斷成熟和數據業務的持續發展，TalkingData研發團隊一直保持高密度的招聘，我們對這個現象的感覺是比較明顯的。因為我們在面試中越來越多的發現，年輕人的簡歷寫得愈發琳瑯滿目，這也“精通”，那也“擅長”，數量不等的“多年經驗”或“長期從事”……恨不得2年工作經驗比干10年的簡歷還要長，幾乎稱得上當代常用技術巡展。不要太強！只看簡歷就想趕緊招進來，再開掉現在這些“尸位素餐”的非全棧員工，世界肯定清凈了吧？

但是情況真的是這么好嗎？

在面試中，我們會通過問答，檢驗候選人在技術上思考的深度、理解能力、學習能力和解決問題的能力。所以研發人員面試一般會遵循以下流程：

1. 介紹一下背景和職業經歷。

2. 選擇一個你最熟悉或擅長的項目，詳細描述一下整體架構和你做的工作。

3. 討論一下你遇到的挑戰以及怎么去解決的。

4. 然后從這一步開始，我們就會不斷地挑戰，不斷追問“為什么”，直到通關或者回答不出來為止。

在這個流程中，每一步都有大批候選人失敗，比較典型的失敗原因包括：

1. 跳槽頻繁

最常見的理由是“我想學習新的東西”。想學新東西是值得贊賞的，但是我很難想到正常人在短時間就能把一門新的技術學通。尤其是開源技術，基本屬于入門容易精通難，很容易找到一些教程101，幫你5分鐘學會安裝部署，但是一旦用上生產系統，就很容易出現各種各樣的突發問題，配置的、架構的、網絡的、代碼的、甚至還可能有硬件的——逼迫你絞盡腦汁上各種論壇找各種谷哥度娘去解決。經驗就是從不斷填坑的過程中積累起來的。只會安裝部署，距離真正掌握還差八千里。

最夸張的見過2年換了6個公司。所以到后來，只要一看到簡歷中最近3次工作經驗中沒有超過2年的，直接就略過了。

2. 缺乏對架構的感覺

先不說一個技術人員（尤其是大數據技術人員）必備的好奇心或邏輯性，也只有對整體架構有清晰的認識，才能更加準確的了解自己要實現的需求對整個業務線的意義，從而在功能邊界定義和技術選型上有相對合理的判斷。如果對于自己熟悉項目的整體架構缺乏了解或者描述不清晰，我們認為這樣的研發人員比較缺乏整體感和全局觀，成長一般都會比較有限。

實際上畫不出整個產品線技術架構圖的大有人在，能畫出來但是各個模塊畫的稀里糊涂的也不在少數。

3. 技術浮于表面

說起遇到的挑戰時，很容易能夠看出候選人對于技術掌握的深度。說不出挑戰的情況，要么是任何技術都擋不住的大牛，要么就是沒有經歷過比如計算瓶頸、數據淤積、磁盤爆滿、內存不足、架構調優這樣的戰斗洗禮。對于后者，面試官辨就一定要小心，因為這樣的人即使用過的技術和框架再多，為你帶來的坑也可能比填的坑還多。

想起一個印象比較深的例子，一個候選人簡歷上充滿了說自己長于各種大數據技術的明示，然后在面試中請他找個最擅長的項目深入聊聊的時候，他說，呃…這個…那我們來聊聊之前做過的一個網站項目吧，我在里面做web前端……當時我就無語了。

4. 細節禁不住挑戰

為什么要選擇這個方案？和別的方案對比有什么優勢？這個方案有什么問題？如果讓你來研發這個方案的新版本，你準備做什么樣的優化，為什么？數據量如果增大一個數量級，你覺得這個方案會出現瓶頸嗎？再增大一個數量級呢？BlaBlaBla……這些都是例行問題，如果沒有對技術熟悉并研究到一定程度，是很難有條理的說清楚的。

曾經遇到過一個牛氣哄哄的年輕人，剛畢業工作1年就找親戚投資創業擔任CTO，瞎折騰了一年公司黃了，然后出來找工作。第一年的薪資算正常，擔任CTO的時候就給自己工資翻倍，然后在翻倍的基礎上期望我們再漲50%。也就是說，經過這一年創業過程，他覺得自己做了CTO，接觸了好多技術，增值了，“我什么都能干”，理應比第一年漲3倍。實際問起來，每項技術都是泛泛，沒什么細節，自然就fail了。

作家格拉德威爾在《異類》一書中指出，“人們眼中的天才之所以卓越非凡，并非天資超人一等，而是付出了持續不斷的努力。1萬小時的錘煉是任何人從平凡變成超凡的必要條件?！彼麑⒋朔Q為“一萬小時定律”。

要成為某個領域的專家，需要至少10000小時。如果每天工作八個小時，一周工作五天，那么成為一個領域的專家至少需要五年。就算是一直搞“996”，也差不多需要3年。這符合任何一個有經驗的技術人員的認知：一門技術，沒有兩三年以上的熟悉和研究，是根本談不上精通的。尤其是大數據行業是一個比較新的行業，很多技術和方法都在摸索階段，需要更多的時間來積累。TalkingData也是經過了4年多和海量數據以及各種大數據技術的斗爭，趟過了無數的地雷陣，到今天才可以說是有了一些積累，培養出一批在大數據領域比較有經驗的技術專家。即使這樣，我們從來也不認為我們研發團隊里面有“全棧工程師”。

大數據行業一定是靠經驗靠積累，沒有任何速成的做法，所以我們始終控制研發團隊能夠更加聚焦一些而不是更發散一些，做的更深而不是更廣一些。

那說回來，到底有沒有全棧工程師存在？肯定是有的。但是我見過的能稱得上“全?！钡墓こ處煟径荚谀骋粋€領域寫過大量代碼，或者解決過大量問題，積累了非常深厚的功底，然后在精深之后，把知識轉化成為常識，才能真正觸類旁通。這時候看起來應該就是大家說的“全?！卑?。但是這顯然不適合經驗較少的菜鳥工程師。

所以，希望年輕的技術人員能夠更加踏實一些，不要輕信“全棧工程師”的美麗神話。只有為自己打好技術基礎，才能飛得更高。