最近參加一個技術社群活動，在討論到“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萬小時的錘鍊是任何人從平凡變成超凡的必要條件。”他將此稱為“一萬小時定律”。

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

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

那說回來，到底有沒有全棧工程師存在？肯定是有的。但是我見過的能稱得上“全棧”的工程師，基本都在某一個領域寫過大量程式碼，或者解決過大量問題，積累了非常深厚的功底，然後在精深之後，把知識轉化成為常識，才能真正觸類旁通。這時候看起來應該就是大家說的“全棧”吧。但是這顯然不適合經驗較少的菜鳥工程師。

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

廣告時間：如果大家覺得自己有志於大資料領域，對大資料技術有熱情，對如何用資料解決日常生活中的問題有好奇心，歡迎加入TalkingData大資料研發團隊，我們這裡有足夠多的資料和技術來挑戰你的極限，你肯定不會失望！

注：有意者請把簡歷發至

wenfeng。xiao@tendcloud。com

，來信必回。