【非廣告,純乾貨】中小公司的Java工程師應該如何逆襲衝進BAT?【石杉的架構筆記】

石杉的架構筆記發表於2019-01-24

歡迎關注個人公眾號:石杉的架構筆記(ID:shishan100)

週一至週五早8點半!精品技術文章準時送上!

目錄

(1)80% Java工程師都有的迷茫

(2)你的技術為啥十年八年都無法進步?

(3)追求卓越,自己設立技術挑戰

(4)幻想一步登天?那只是你的黃粱美夢

(5)不斷提升自己,最後進入BAT

(6)最後的寄語

(1)80% Java工程師都有的迷茫

這篇文章,跟大家聊一聊很多很多很多人問我的一個問題:中小公司的Java工程師應該如何規劃準備,才能跳槽進入BAT這類一線網際網路公司?

之所以我用了三個 “很多” 來形容這個問題,是因為實在這個問題太普遍了,因為國內Java工程師至少好幾十萬,但是在國內網際網路大廠裡幹過的碼農可能也就十分之一,或者五分之一的比例。

所以,其實這個也是符合28法則的,少部分人在大廠裡幹過,發展的很好。但是大部分人還是在中小型公司,或者外包類傳統IT公司裡工作。

這些同學可能對自己的技術成長,職業發展感到非常的迷茫,自己有點追求,也想去一下大廠,但是又不知道怎麼規劃。

開始本文之前,同樣強調一點:像這種講職業規劃發展的文章,有可能很多同學會以為是廣告。但是這篇文章,筆者特意宣告:純乾貨、非廣告。

因為我個人在國內幾個最大的網際網路公司先後有著十餘年工作經歷,面試和招聘過大量各種水平的開發人員。包括初、中、高階開發,技術專家,高階技術專家,都面過。

同樣,也指導過很多同學的職業發展規劃,看過大量的同學不順利的職業發展,所以打算從我個人的角度來聊聊這個問題:中小公司的同學應該如何一步一步實現逆襲進入BAT。

我相信以下情形很多同學應該都有類似體會:一直徘徊在各種中小公司裡開發一些沒技術難度的Java系統,主要就是CRUD。

哪怕是用了用MQ、快取、分庫分表,但是也沒什麼併發量,資料量也不算特別大,自己的技術成長極為緩慢。

然後就是三五年,七八年,甚至十多年,職業發展和技術水平都停滯在這個狀態,無法有更進一步的發展。

隨著現在寒冬到來,到處裁員,中年碼農的危機,加不動班,體力越來越差,孩子壓力越來越大,對自己何去何從很迷茫。

有一些同學是一直徘徊在那種中小型網際網路公司裡碰到上述情況,有一些同學是在一些外包類的IT公司裡碰到上述情況。

(2)你的技術為啥十年八年都無法進步?

先來搞清楚一個問題,你的技術到底為什麼十年八年都無法進步?

拆解一下,你的能力集中在哪幾塊:

技術廣度

對MQ、快取、NoSQL、大資料、高併發、高可用、微服務,等一系列的相關技術都有一定的瞭解,熟悉常見功能 在自己的專案裡落地使用過,有一定的技術使用經驗

這可以解釋為技術廣度。

技術深度

讀過Kafka的底層原始碼? 對訊息中介軟體的架構設計思想有深刻的理解? 對分散式事務框架/中介軟體的架構設計有過研究? 在每秒百萬併發場景下做過底層系統的深入優化和故障處理? 如果你有類似這種過人之處,那麼你才能說你有某些技術深度。

專案經驗

你有沒有整體負責過幾億註冊使用者,幾千萬日活使用者的大規模、高併發、分散式、高可用、高複雜度的系統架構設計? 或者你負責的一直都是那種公司內部使用的,幾十個人用的OA系統,CRM系統? 這些就是你的專案經驗

*團隊管理

你在網際網路公司裡帶過20的團隊? 或者你在一個傳統IT公司裡帶過3個人的小組? 這都是你的團隊管理經驗。

拆解過後,再來看看,如果你在一些小型網際網路公司,或者是做一些傳統軟體開發,為什麼技術無法進步?

其實道理很簡單,可能你的公司推出了一款APP,但是不好意思,使用者量總共就100萬,日活使用者就10萬人。

那你覺得你的系統有技術挑戰嗎?沒有。

既然沒有技術挑戰,你把系統搞那麼複雜幹嘛?或者你的架構師搞那麼複雜幹嘛?不需要。

大家簡單做一做,主要crud寫一下功能,最多現在spring cloud流行了,上一下拆成微服務的就夠了。

然後這套系統就穩定支撐你公司的業務了,那你接觸不到很大的技術挑戰,所以技術進入停滯狀態,不是很正常麼?

或者你做一些傳統的軟體開發,比如說建築類軟體,辦公自動化軟體,類似這種的。總共就幾十個人用一個系統,或者幾百人用,那你就更是如此了。

可能都不需要spring cloud,直接單塊系統,單機部署,就是在裡面填充業務程式碼就好了。

所以根本原因,就是很多同學平時的工作環境,他沒有什麼技術挑戰,所以只要把系統技術做的簡單一些,低成本就可以支撐公司業務了,那既然這樣,當然技術就進展很緩慢了。

然後可能你工作了八年十年,技術廣度還可以,對流行的技術自己都看過一些書,簡單用過,玩過demo。

你的專案經驗積累了不少,但是都是一些各個傳統領域的系統業務理解較為深刻,沒有極高技術挑戰的專案經驗。

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

大概就是如此了,每次換工作,還是隻能換類似的公司,幹類似的技術,依然沒有進步,依然是類似的專案經驗。

所以大夥兒先梳理清楚,迷茫的根源究竟在哪裡。

(3)追求卓越,自己設立技術挑戰

通常來說,我個人站在公司角度是很反對架構的過度設計的,因為平白浪費很多時間,而且很多架構過度複雜沒有必要。

但是如果是站在個人的職業發展角度而言,那麼你的leader必須要有對技術追求卓越的思維。或者你是leader的話,就得有對你的團隊技術追求卓越的品質。

什麼叫追求卓越呢?

舉個例子,現在你開發了一款辦公自動化系統,服務了某個公司,幾百人在用,那麼技術一般,就是一個單塊系統,直接Spring MVC + Spring + MyBatis就搞定了。大家都做著沒意思。

好,現在leader為了大家的幸福和未來,咬咬牙說:

Leader

兄弟們,現在系統滿足公司的發展了,但是我們不如來大膽的追求一下卓越。

兄弟們

領導你是啥意思啊??

Leader

這樣,我們們首先為了提高系統的開發效率,避免30個兄弟開發一個單塊系統效率太低,我們來實踐一把最流行的微服務架構吧。

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

兄弟們

(認真聽著)

Leader

我們們先得做技術調研,小A你來研究研究Spring Cloud核心技術元件,小B你來研究研究配置中心,小C你來研究研究服務鏈路追蹤,等等。

大家分頭行動,都開始學起來新技術。但是呢,我們們平時已經很忙了,要是佔用工作時間搞這個,老闆會罵人,大家看,每個人每天額外加班抽2小時一起來搞一下,怎麼樣?

兄弟們

領導,為了大家的幸福,那肯定得趕緊上新技術啊,大家都學點新東西。

最後大家辛苦了2個月,一起把系統重構成了整套的微服務架構,每個人都學到了東西,領導也學到了微服務整體架構設計的能力。

Leader

兄弟們,還想不想繼續為未來的幸福努力一下?

兄弟們

一切都聽領導安排。

Leader

現在這破系統就幾百人用,忒沒意思了,我們們來大膽想象,假如說以後這個系統要做成SaaS雲產品,會有幾百個公司來用,有幾萬人,甚至幾十萬人同時使用一套後臺系統。大夥想想,那時會怎麼樣?

兄弟們

貧窮限制了我的想象力。。。。

Leader

那小A你去根據現在系統的訪問量估算一下,如果有幾十萬人用,系統每天的併發量會有多少,資料庫能不能支撐住,需要用哪些高併發的技術來支撐?

小B,你去調研一下,如果有幾十萬人用,我們會儲存多少資料量,效能會有多差,怎麼支撐海量資料儲存?然後看看用什麼技術來支撐一下?

兄弟們

好,領導一句話,上刀山、下火海。

幾個月後,大家研發了一套系統,完成了測試,系統整合了快取叢集、MQ叢集、分庫分表技術,還有很多其他的一些東西。

這個時候領導就想辦法了,能不能跟老闆建議一下,我們們就把產品做成SaaS雲的模式呢?然後是不是可以就把這套系統給部署到生產環境裡去?

到此為止,就通過一個例子,給大家闡述了一下,自己在公司裡,如何通過想辦法不斷的追求系統的卓越,提高研發效率,支撐也許可能會存在的更高的併發量,更多的資料量,儘可能把系統做的更好一些。

多想想為了解決自己設想的一些技術挑戰,如何儘可能把一些業界常用的技術都學習一下,比如快取、訊息、分散式、微服務、大資料,等等。

然後都儘可能進行相關的實踐,積累相關的專案經驗。

實際每個人在落地的這個過程的時候,方式肯定是不一樣的:有的人也許人微言輕,只能對自己負責的模組設想一些技術挑戰,然後只能自己在本地拉一個公司程式碼分支,嘗試對這些分支加入一些技術,自己練習思考。

還有的人,可能是個小leader,無法左右公司產品發展方向,但是可以儘可能跟上級溝通,闡述自己對系統架構追求卓越的一些構想。

然後,爭取到一些時間,儘可能把系統多融入一些技術,給做的好一些。

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

這總是可以儘可能幫助你在一定程度上提高技術,擴充套件技術知識的。

在這個階段,我見過最多的人犯的最大的一個錯誤就是:覺得自己這樣倒騰一些技術是沒用的,沒有實際的真正的經驗。

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

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

(4)幻想一步登天?那只是你的黃粱美夢

很多人多學了一些技術,有了一些經驗,很容易開始有點膨脹,老是想著一步登天,一下子就進入BAT。

關於這個,其實是有類似的一些成功經歷,比如有的人是大專學歷,通過自己的努力學習,加上一些機緣巧合,直接一下子就從中小公司跳入了BAT。

但是就現實情況來看,不是每個人都一定可以一步登天,複製這個經歷的。

在你學習了一些技術,同時自己多做了一些嘗試,積累了一定的經驗之後,此時應該做的是:做最壞的打算,抱最好的希望。

你完全可以去試試BAT的面試,TMD的面試,儘可能去爭取機會,但是如果沒面上也無所謂。

你可以降低期望,人只要跟自己比就好了。

比如說你現在在某小型的傳統外包軟體公司,那麼接下來如果你能面進一家小型創業網際網路公司,有個幾百萬使用者量,日活使用者有幾十萬,比之前的公司技術挑戰多一些,用的技術也更多一些,那麼你就可以去了。

只要你每一步跳槽,都比之前好,都讓自己有進步,那麼整體的大方向就是沒錯的。

也許你先進一個創業型網際網路公司,然後下一家就可以進入一個市值幾十億美金的上市網際網路公司,再下一步就可以進入BAT。

在這個階段我見過很多人犯的最大的錯誤就是:老是覺得自己剛學了一點東西,就必須立馬進大公司。

這些同學往往心態著急的不行,而忽略了自己的學歷、背景、經驗導致了起點較低。能立馬進BAT當然很好,但是有時候機緣巧合緣分沒到,進不去也正常。

在這個階段最需要做的,就是跟自己比,別跟別人比,只要每一次跳槽都比上一次好,公司更大,薪資更高,職位更高,技術挑戰更大,就可以了。

(5)不斷提升自己,最後進入BAT

一旦你開始做到跳槽進入一家比之前更好的公司,有更高的技術挑戰,那麼公司本身的技術挑戰就會促使你快速成長,還是舉個例子吧。

比如說你本來就在做傳統軟體的開發,用的都是單塊系統涉及的一些技術,就是簡單的spring mvc、spring、mybatis等技術做CRUD的業務開發。

但是呢,你通過追求卓越,自己業餘不停的學習技術,然後對自己負責的一些模組多設立了一些技術挑戰,自己構思了很多更高挑戰的場景下,可以給自己的模組加入哪些更高階的技術。

接著你帶著自己學習的一些技術,還有積累的一些實踐經驗和思考,進入了一家創業型網際網路公司。

這家公司的好處就在於,網際網路公司技術氛圍更好,比如zookeeper、redis、rocketmq、sharding-jdbc,等各種技術,在公司生產環境的系統裡,都有落地和使用。

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

但是,此時你還是需要繼續不停的學習技術,學習更多的架構上需要的技術,深入的學習技術,同時積累實踐經驗。

然後帶著這份工作經歷,同時加上你不斷加強的技術學習,你進入了一家比如30億美金估值的獨角獸公司。

這家公司有2000萬使用者,日活使用者達到百萬級,高峰併發量可以過萬,每天資料庫裡日增資料量達到了數十萬。

此時你開始真正接觸一些所謂的:高併發、高可用、高效能、海量資料的實際處理。

基於你開發的業務系統,你開始更多的實踐,同時你還對各種涉及到的技術有了更加深入的研究,比如對一些核心中介軟體系統進行了原始碼級別的閱讀和研究。

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

然後你進去之後,可以在最頂尖的網際網路公司裡學習開發流程、規範、架構,接觸到最大規模的使用者量,每天都有解決不完的技術挑戰,在這個過程中,你又可以繼續成長。

最後可能你再次跳槽,就可以進入TMD中某一家,拿下技術專家的offer,在大公司裡拿下技術專家的職位,帶一個團隊,達到人生第一個巔峰。

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

大家別以為這個僅僅是筆者捏造的一個故事,在筆者指導過的同學中,確實有同學按照這個路線,實現了人生的逆襲!

(6)最後的寄語

最後,送大家一句話:九層之臺,始於壘土;千里之行,始於足下。

這裡面最難的就是開始的那一步,也就是大量的人都停留在一些完全沒太多技術含量的技術工作的情況下,這個時候是最難熬的。

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

到了後面,就是讓公司的技術挑戰push你不斷努力和進步,最後進入BAT這類一線網際網路公司。

END

如有收穫,請幫忙轉發,您的鼓勵是作者最大的動力,謝謝!

一大波微服務、分散式、高併發、高可用的原創系列文章正在路上

歡迎掃描下方二維碼,持續關注:

【非廣告,純乾貨】中小公司的Java工程師應該如何逆襲衝進BAT?【石杉的架構筆記】

石杉的架構筆記(id:shishan100)

十餘年BAT架構經驗傾囊相授

推薦閱讀:

1、拜託!面試請不要再問我Spring Cloud底層原理

2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問?

3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰

4、微服務架構如何保障雙11狂歡下的99.99%高可用

5、兄弟,用大白話告訴你小白都能聽懂的Hadoop架構原理

6、大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問

7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍

8、拜託,面試請不要再問我TCC分散式事務的實現原理!

9、【坑爹呀!】最終一致性分散式事務如何保障實際生產中99.99%高可用?

10、拜託,面試請不要再問我Redis分散式鎖的實現原理!

11、【眼前一亮!】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上?

12、億級流量系統架構之如何支撐百億級資料的儲存與計算

13、億級流量系統架構之如何設計高容錯分散式計算系統

14、億級流量系統架構之如何設計承載百億流量的高效能架構

15、億級流量系統架構之如何設計每秒十萬查詢的高併發架構

16、億級流量系統架構之如何設計全鏈路99.99%高可用架構

17、七張圖徹底講清楚ZooKeeper分散式鎖的實現原理

18、大白話聊聊Java併發面試問題之volatile到底是什麼?

19、大白話聊聊Java併發面試問題之Java 8如何優化CAS效能?

20、大白話聊聊Java併發面試問題之談談你對AQS的理解?

21、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥?

22、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化

23、網際網路公司的面試官是如何360°無死角考察候選人的?(上篇)

24、網際網路公司面試官是如何360°無死角考察候選人的?(下篇)

25、Java進階面試系列之一:哥們,你們的系統架構中為什麼要引入訊息中介軟體?

26、【Java進階面試系列之二】:哥們,那你說說系統架構引入訊息中介軟體有什麼缺點?

27、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷

28、【Java進階面試系列之三】哥們,訊息中介軟體在你們專案裡是如何落地的?

29、【Java進階面試系列之四】扎心!線上服務當機時,如何保證資料100%不丟失?

30、一次JVM FullGC的背後,竟隱藏著驚心動魄的線上生產事故!

31、【高併發優化實踐】10倍請求壓力來襲,你的系統會被擊垮嗎?

32、【Java進階面試系列之五】訊息中介軟體叢集崩潰,如何保證百萬生產資料不丟失?

33、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(上)?

34、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(中)?

35、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(下)?

36、億級流量架構第二彈:你的系統真的無懈可擊嗎?

37、億級流量系統架構之如何保證百億流量下的資料一致性(上)

38、億級流量系統架構之如何保證百億流量下的資料一致性(中)?

39、億級流量系統架構之如何保證百億流量下的資料一致性(下)?

40、網際網路面試必殺:如何保證訊息中介軟體全鏈路資料100%不丟失(1)

41、網際網路面試必殺:如何保證訊息中介軟體全鏈路資料100%不丟失(2

42、面試大殺器:訊息中介軟體如何實現消費吞吐量的百倍優化?

43、高併發場景下,如何保證生產者投遞到訊息中介軟體的訊息不丟失?

44、兄弟,用大白話給你講小白都能看懂的分散式系統容錯架構

45、從團隊自研的百萬併發中介軟體系統的核心設計看Java併發效能優化

46、【非廣告,純乾貨】英語差的程式設計師如何才能無障礙閱讀官方文件?

47、如果20萬使用者同時訪問一個熱點快取,如何優化你的快取架構?

作者:石杉的架構筆記 連結:juejin.im/post/5c263a… 來源:掘金 著作權歸作者所有,轉載請聯絡作者獲得授權!

相關文章