BAT會看上哪樣的中小公司程序員？

80% Java工程師都有的迷茫
跟你們聊一聊不少不少不少人問個人一個問題：中小公司的Java工程師該如何規劃準備，才能跳槽進入BAT這類一線互聯網公司？

我用了三個 「不少」 來形容這個問題，是由於這個問題太廣泛了。國內Java工程師至少好幾十萬，可是在國內互聯網大廠裏幹過的碼農比例不高。

這個是符合28法則的，少部分人在大廠裏幹過，發展得很好。可是大部分人仍是在中小型公司，或者外包類傳統IT公司裏工做。

這些同窗可能對本身的技術成長，職業發展感到很是的迷茫，本身有點追求，也想去一下大廠，可是又不知道怎麼規劃。

我我的在國內幾個最大的互聯網公司前後有着十餘年工做經歷，面試和招聘過大量各類水平的開發人員。包括初、中、高級開發，技術專家，高級技術專家都面過。也指導過不少同窗的職業發展規劃，因此打算從我我的的角度來聊聊這個問題：中小公司的同窗應該如何一步一步實現逆襲進入BAT。

我相信如下情形不少同窗應該都有相似體會：一直徘徊在各類中小公司裏開發一些沒技術難度的Java系統，主要就是CRUD。

哪怕是用了用MQ、緩存、分庫分表，可是也沒什麼併發量，數據量也不算特別大，本身的技術成長極爲緩慢。

等過了三五年，甚至是十多年過去，職業發展和技術水平都停滯在這個狀態，沒法有更進一步的發展。

隨着如今寒冬到來，處處裁人，中年碼農的危機，加不動班、體力愈來愈差、孩子壓力愈來愈大，對本身何去何從很迷茫。

你的技術爲啥十年八年都沒法進步？
先來搞清楚一個問題，你的技術到底爲何十年八年都沒法進步？

拆解一下，你的能力集中在哪幾塊：

技術廣度

對MQ、緩存、NoSQL、大數據、高併發、高可用、微服務，等一系列的相關技術都有必定的瞭解，熟悉常見功能
在本身的項目裏落地使用過，有必定的技術使用經驗。
技術深度

讀過Kafka的底層源碼？
對消息中間件的架構設計思想有深入的理解？
對分佈式事務框架/中間件的架構設計有過研究？
在每秒百萬併發場景下作過底層系統的深刻優化和故障處理？
若是你有相似這種過人之處，那麼才能說你有某些技術深度。

項目經驗

你有沒有總體負責過幾億註冊用戶，幾千萬日活用戶的大規模、高併發、分佈式、高可用、高複雜度的系統架構設計？
或者你負責的一直都是那種公司內部使用的，幾十我的用的OA系統，CRM系統？

團隊管理

你在互聯網公司裏帶過20的團隊？
或者你在一個傳統IT公司裏帶過3我的的小組？
拆解事後再來看看，若是你在一些小型互聯網公司，或者是作一些傳統軟件開發，爲何技術沒法進步？

其實道理很簡單，可能公司推出了一款APP，可是用戶量總共就100萬，日活用戶就10萬人。

那你的系統有技術挑戰嗎？沒有。

既然沒有技術挑戰，你把系統搞那麼複雜幹嗎？或者架構師搞那麼複雜幹嗎？不須要。

你們簡單作一作，主要CRUD寫一下功能，最多如今Spring Cloud流行了，上一下拆成微服務的就夠了。

這套系統就穩定支撐公司的業務了，那你接觸不到很大的技術挑戰，因此技術進入停滯狀態，不是很正常麼？

或者你作一些傳統的軟件開發，好比說建築類軟件、辦公自動化軟件這種的。總共就幾十我的用一個系統，或者幾百人用，那狀況就更是如此了。

可能都不須要Spring Cloud，直接單塊系統，單機部署，就是在裏面填充業務代碼就行了。

因此根本緣由是不少同窗平時的工做環境，沒有什麼技術挑戰，因此只要把系統技術作的簡單一些，低成本就能夠支撐公司業務了，那既然這樣，固然技術就進展很緩慢了。

可能你工做了八年十年，技術廣度還能夠，對流行的技術本身都看過一些書，簡單用過，玩過Demo。

你的項目經驗積累了很多，可是都是一些各個傳統領域的系統業務理解較爲深入，沒有極高技術挑戰的項目經驗。

有的人工做時間長，可能就是帶過一些人，有過一些帶團隊的經驗，能管人。

大概就是如此了，每次換工做，仍是隻能換相似的公司，幹相似的技術，依然沒有進步，依然是相似的項目經驗。

因此大夥兒先梳理清楚，迷茫的根源究竟在哪裏。

追求卓越，本身設立技術挑戰
坦白說，若是站在公司角度是很反對架構的過分設計的，由於平白浪費不少時間，並且不少架構過分複雜沒有必要。

可是若是是站在我的的職業發展角度而言，那麼你的Leader必需要有對技術追求卓越的思惟。或者你是Leader的話，就得有對你的團隊技術追求卓越的品質。

什麼叫追求卓越呢？

舉個例子，如今你開發了一款辦公自動化系統，服務某個公司，幾百人在用，那麼技術通常，就是一個單塊系統，直接Spring MVC + Spring + MyBatis就搞定了。你們都作着沒意思。

如今Leader爲了你們的幸福和將來，咬咬牙說：「兄弟們，如今系統知足公司的發展了，可是咱們不如來大膽的追求一下卓越。」

兄弟們：「領導你是啥意思啊？」

Leader：「我們首先爲了提升系統的開發效率，避免30個兄弟開發一個單塊系統效率過低，咱們來實踐一把最流行的微服務架構吧。

我們一塊兒來把系統重構成微服務的架構，把spring cloud整套東西都用進去。

我們先得作技術調研，小A你來研究研究Spring Cloud核心技術組件，小B你來研究研究配置中心，小C你來研究研究服務鏈路追蹤……

你們分頭行動，都開始學起來新技術。可是我們平時已經很忙了，要是佔用工做時間搞這個，老闆會罵人，你們看，每一個人天天額外加班抽2小時一塊兒來搞一下，怎麼樣？」

兄弟們：「領導，爲了你們的幸福，那確定得趕忙上新技術啊，你們都學點新東西。」

最後你們辛苦了2個月，一塊兒把系統重構成了整套的微服務架構，每一個人都學到了東西，領導也學到了微服務總體架構設計的能力。

Leader：「如今這破系統就幾百人用，忒沒意思了，我們來大膽想象，假如說之後這個系統要作成SaaS雲產品，會有幾百個公司來用，有幾萬人，甚至幾十萬人同時使用一套後臺系統。大夥想一想，那時會怎麼樣？」

兄弟們：「貧窮限制了個人想象力。」

Leader：「那小A你去根據如今系統的訪問量估算一下，若是有幾十萬人用，系統天天的併發量會有多少，數據庫能不能支撐住，須要用哪些高併發的技術來支撐？

小B，你去調研一下，若是有幾十萬人用，咱們會存儲多少數據量，性能會有多差，怎麼支撐海量數據存儲？而後看看用什麼技術來支撐一下？」

兄弟們：「好，領導一句話，上刀山、下火海。 」

幾個月後，你們研發了一套系統，完成了測試，系統集成了緩存集羣、MQ集羣、分庫分表技術，還有不少其餘的一些東西。

這個時候領導就想辦法了，能不能跟老闆建議一下，我們就把產品作成SaaS雲的模式呢？而後是否是能夠就把這套系統給部署到生產環境裏去？

到此爲止，就經過一個例子給你們闡述了一下，本身在公司裏如何經過想辦法不斷的追求系統的卓越，提升研發效率，支撐也許可能會存在的更高的併發量，更多的數據量，儘量把系統作的更好一些。

多想一想爲了解決本身設想的一些技術挑戰，如何儘量把一些業界經常使用的技術都學習一下，好比緩存、消息、分佈式、微服務、大數據等等。

都儘量進行相關的實踐，積累相關的項目經驗。

實際每一個人在落地的這個過程的時候，方式確定是不同的：有的人也許人微言輕，只能對本身負責的模塊設想一些技術挑戰，而後只能本身在本地拉一個公司代碼分支，嘗試對這些分支加入一些技術，本身練習思考。

還有的人多是個小Leader，沒法左右公司產品發展方向，可是能夠儘量跟上級溝通，闡述本身對系統架構追求卓越的一些構想。

而後爭取到一些時間，儘量把系統多融入一些技術，給作得好一些。

每一個人都有每一個人的方式，可是歸根到底一句話：若是你自己工做沒有技術挑戰，那麼儘量多給本身設立一些挑戰，多學一些技術，多作一些嘗試和實踐。

這老是能夠儘量幫助你在必定程度上提升技術，擴展技術知識的。

在這個階段，我見過最多的人犯的最大的一個錯誤就是：以爲本身這樣倒騰一些技術是沒用的，沒有實際的真正的經驗。

而後他們着急忙慌，心浮氣躁，自怨自艾，總想着必須得先進一個好的公司，才能鍛鍊技術。

實際上，這是一種很浮躁的想法，你要進好的公司鍛鍊，你必須先打磨一下本身的技術，而後纔能有資本去一家更好的公司。

幻想一步登天？那只是你的黃粱好夢
不少人多學了一些技術經驗，很容易開始有點膨脹，總是想着一步登天，一會兒就進入BAT。

現實是有相似的一些成功經歷，好比有的人是大專學歷，經過本身的努力學習，加上一些機緣巧合，直接一會兒就從中小公司跳入了BAT。

可是就現實狀況來看，不是每一個人都必定能夠一步登天，複製這個經歷的。

在你學習了一些技術，同時本身多作了一些嘗試，積累了必定的經驗以後，此時應該作的是：作最壞的打算，抱最好的但願。

你徹底能夠去試試BAT、TMD的面試，儘量去爭取機會，可是若是沒面上也無所謂。

你能夠下降指望，人只要跟本身比就行了。

好比說你如今在某小型的傳統外包軟件公司，那麼接下來若是你能面進一家小型創業互聯網公司，有個幾百萬用戶量，日活用戶有幾十萬，比以前的公司技術挑戰多一些，用的技術也更多一些，那麼你就能夠去了。

只要你每一步跳槽，都比以前好，都讓本身有進步，那麼總體的大方向就是沒錯的。

也許你先進一個創業型互聯網公司，而後下一家就能夠進入一個市值幾十億美金的上市互聯網公司，再下一步就能夠進入BAT。

在這個階段我見過不少人犯的最大的錯誤就是：總是以爲本身剛學了一點東西，就必須立馬進大公司。

這些同窗每每心態着急的不行，而忽略了本身的學歷、背景、經驗致使了起點較低。能立馬進BAT固然很好，可是有時候機緣巧合緣分沒到，進不去也正常。

在這個階段最須要作的，就是跟本身比，別跟別人比，只要每一次跳槽都比上一次好，公司更大，薪資更高，職位更高，技術挑戰更大，就能夠了。

不斷提高本身，最後進入 BAT
一旦你開始作到跳槽進入一家比以前更好的公司，有更高的技術挑戰，那麼公司自己的技術挑戰就會促使你快速成長，仍是舉個例子吧。

好比說你原本就在作傳統軟件的開發，用的都是單塊系統涉及的一些技術，就是簡單的Spring MVC、Spring、Mybatis等技術作CRUD的業務開發。

可是你本身業餘不停地學習技術，對本身負責的一些模塊多設立了一些技術挑戰，本身構思了不少更高挑戰的場景下，能夠給本身的模塊加入哪些更高階的技術。

接着你帶着本身學習的一些技術，還有積累的一些實踐經驗和思考，進入了一家創業型互聯網公司。

這家公司的好處就在於，互聯網公司技術氛圍更好，好比ZooKeeper、Redis、RocketMQ、Sharding-JDBC，等各類技術，在公司生產環境的系統裏，都有落地和使用。

那麼你此時是否是就不用停留於一些技術挑戰的構思，能夠開始真正作一些有點技術挑戰的工做了。

可是，此時你仍是須要繼續不停的學習技術，學習更多的架構上須要的技術，深刻的學習技術，同時積累實踐經驗。

而後帶着這份工做經歷，同時加上你不斷增強的技術學習，你進入了一家好比30億美金估值的獨角獸公司。

這家公司有2000萬用戶，日活用戶達到百萬級，高峯併發量能夠過萬，天天數據庫裏日增數據量達到了數十萬。

此時你開始真正接觸一些所謂的：高併發、高可用、高性能、海量數據的實際處理。

基於你開發的業務系統，你開始更多的實踐，同時你還對各類涉及到的技術有了更加深刻的研究，好比對一些核心中間件系統進行了源碼級別的閱讀和研究。

最後你終於等到一個機會，BAT裏某家公司讓你去面試，經歷了四五輪面試以後，對方給了你一個Offer，是年薪40萬的高級Java工程師的職位。

而後你能夠在最頂尖的互聯網公司裏學習開發流程、規範、架構，接觸到最大規模的用戶量，天天都有解決不完的技術挑戰，在這個過程當中，你又能夠繼續成長。

可能你再次跳槽，進入TMD中某一家，拿下技術專家的Offer，在大公司裏拿下技術專家的職位，帶一個團隊，達到人生第一個巔峯。

接着你再跳槽，可能一些創業公司就開始挖你去作一些技術管理層。

你們別覺得這個僅僅是筆者捏造的一個故事，在筆者指導過的同窗中，確實有同窗按照這個路線，實現了人生的逆襲！

最後，送你們一句話：九層之臺，始於壘土；千里之行，始於足下。

最難的是開始的那一步，大量的人都停留在一些徹底沒太多技術含量的技術工做的狀況下，這個時候是最難熬的。

其實只要能把第一步走好，本身拼命地積累技術，努力跟其餘工程師競爭，技術遠超跟本身同狀況的其餘工程師，那麼你就有機會率先脫離這種困境，開始慢慢第二步，第三步。

到了後面，就是讓公司的技術挑戰使你不斷努力和進步，最後進入BAT這類一線互聯網公司。

我本身是一名Java架構師，辭職目前在作講師，整理了一份學習Java乾貨，不管是剛需的高級面試專題仍是經常使用的架構資料都有整理，送給每一位Java小夥伴。在突飛猛進的程序世界裏，咱們每個人都是學生。加羣712477306羣文件直接獲取。