歡迎關注個人公眾號:石杉的架構筆記(ID:shishan100)
週一至週五早8點半!精品技術文章準時送上!
精品學習資料獲取通道,參見文末
目錄
1、從一個求職案例引入
2 、學歷差距:面試官的第一印象
3、公司背景差距:你的人生名片
4、技術差距:硬核能力的欠缺
5、架構能力的差距
6、面試結果的分析
“ 這篇文章,聊一個很多人感興趣的話題,小公司的Java工程師和大廠Java工程師一起出去求職同一個職位時,前者的競爭力到底差在哪裡呢?
搞明白這個事情,相信很多中小公司的同學可以對自己當前的情況以及跟大廠之間的差距有更加清晰的認識。從而可以更好的規劃自己的職業發展路線,更好的去努力爭取一步一步的縮小差距。
(1)從一個求職案例引入
以下是一個非常真實的案例,是一個大廠工程師和一個小公司工程師同時求職一個獨角獸公司的職位的經歷。
其中一個同學,211/985本科學歷,出身網際網路大廠,四五年經驗的樣子。技術積累非常紮實,而且參與開發的系統支撐過上億使用者量,有真正的高併發經驗。
雖然說那個系統不是他主導設計的,他僅僅是一個資深工程師,負責帶幾個小弟設計和開發幾個子系統。
但是呢,他在這個過程中,全程觀察到了大廠裡的大規模系統,如何規劃、設計、構建以及演進的,如何依託各種各樣的技術解決線上很高的挑戰。
另外一個同學,普通二本學歷,同樣五年左右的工作經驗,但是一直都在小公司裡工作。平時也還算是比較好學,學了一些技術,各種東西或多或少都瞭解,在小公司出身的工程師裡,整體技術還算是比較好一些的。
結果這兩個人同時去一個幾十億美金估值的獨角獸公司去面試求職,大家猜猜,發生了什麼事情?
同樣的年齡,兩個人的面試結果是天差地別。
第一位同學,順利拿下獨角獸的技術專家的職位以及一大筆期權,還能獨立帶團隊;
第二位同學,居然連offer都沒拿到,人家甚至都不願意給一個高階工程師的職位。
所以這篇文章就從幾個方面來分析一下這兩種不同的同學,他們之間的差距到底在哪裡。
(2)學歷差距:面試官的第一印象
其實首先面試官看簡歷以及面試的時候,對你的第一觀感就是兩個:一個是學歷,一個是公司背景,這倆東西幾乎就形成了每個面試官對你的第一印象。
比如說上述兩位同學,第一位同學雖然也就是個本科學歷,但起碼是211/985的名校本科,而第二位同學就是一個不知名的普通二本。
很多人也許覺得學歷這個東西是虛的,關鍵還是能力。對於這個我是部分認可。
確實有的時候我們也見到過,高學歷的人他的技術能力、學習能力、人品態度甚至還遠遠不如一個大專學歷的人。
但是也有很多情況下,高學歷的同學他的技術底子更好,學習能力更強,更加聰明,後勁和潛力遠遠比普通學歷的同學要好的多。
所以這個學歷是不能一概而論的,不能說高學歷的同學就一定很牛,也不能說低學歷的同學就一定很差。要知道,高學歷的同學裡也有各方面不好的,低學歷的同學裡也有各方面極為出色和優秀的。
所以,我的觀點一向是不唯學歷論,我們在招人的時候,通常情況下都是要求名校本科/碩士學歷的。
但是如果是特殊情況下,都會給普通學歷的同學一個機會,讓他來證明自己的極為優秀的潛力和能力,也可以破格招收。
但是這裡有一個很關鍵的點,那就是從我們過往大量的經驗而言,高學歷的同學,他當初為了考上名校,往往付出了大量的努力。所以他的學習能力以及潛力,可能往往更好。
而一個普通學歷的同學,當初考上了普通的大學,可能是自己沒發揮好,但是很多情況下,確實是學習能力沒達到那個水平。
所以說,如果拿到兩份簡歷,一份簡歷是211/985名校本科,一份簡歷是不知名的本二學校,那麼作為面試官,第一印象,其實會潛意識裡覺得,這個211/985名校本科的同學,應該學歷能力和潛力會好很多,心裡會更加期望一些,也會更加認可一些。
那麼在面試的時候,面試官內心的個人情感色彩,其實是相對來說對名校同學更加接收程度高一些的。
而對於普通學歷的同學,可能就是沒什麼期待,也沒什麼負面情緒,就是面試的時候帶著很平常的感情色彩來對待。
那麼大家想,這個學歷的差距,是不是在一開始甚至還沒面試的時候,就已經讓面試官有了不同的看待了?這就是學歷給面試結果帶來的第一個影響的地方。
另外,大家可以想象一下。假設兩個人的技術水平、專案能力都是一樣,但是崗位需求有限,就一個坑,你覺得會招誰?
那想都不用想,肯定是211/985學歷的同學!這個就是學歷的優勢了,在其他方面假設面試結果都差不多的時候,你還是可能會因為學歷問題,被競爭對手擠走,然後失去offer,別人因為學歷高,就可以拿到更多的offer機會。
(3)公司背景的差距:你的人生名片
除了學歷之外,你給人的第一印象,就是你的公司背景。這個其實非常簡單,不用我多說,大家也知道。
雖然說很多大廠出身的同學,也有那種能力平庸,技術不太好的情況,小公司出身的同學,反而也有那種技術能力強悍的人。
但還是那句話,大部分情況下,大廠出身的同學,相對技術能力都是比較好的,有保證。
而小公司出身的同學,很多情況下確實技術能力一般,也沒做過什麼有挑戰的技術專案,整體而言比較普通。
所以一般在面試官來看,如果你是知名大廠出身,那麼一般剛開始就會對你心裡有好感,大家都願意找知名公司的人進來加入自己,對方的技術和經驗有保障。
但是如果你是小公司出身,面試官對你是沒任何感情色彩的,不知道你到底怎麼樣,一切還是要看面試情況。
同樣,我們再假設:如果兩個人學歷差不多,技術能力差不多,專案經驗差不多,但是一個是出身大廠,一個是出身小公司,你會要誰?
當然還是會優先選擇大廠的同學加入團隊了,畢竟人家大廠出身,對大廠自身的一些技術體系見識也多一些,眼界更加開闊一些,哪怕衝著這一點也會讓人家進來。
(4)技術差距:硬核能力的欠缺
承接上文所述,接下來上面兩位同學開始了幾輪面試。
第一位同學的情況之前已經說過,平時非常注重技術積累,經常學習各種技術。
而且這位同學喜歡探索各種開源技術的原始碼,喜歡研究各種不同場景下技術挑戰的解決方案,自己做了大量技術筆記,所以對Java領域完整的技術棧都有很深的積累。
同時,因為在大廠裡開發系統,本身在各種技術挑戰之下,是有足夠的機會實踐,將各種技術在專案裡落地。
比如說真正用快取技術來抗每秒幾萬的併發讀請求,或者基於分庫分表抗幾十億資料量的儲存和查詢。
既然如此,面試結果當然是顯而易見了。
面試官一定會從併發程式設計、快取、JVM、MQ、分散式、微服務、分庫分表、NoSQL、高併發等各個環節開連環炮深入的發問,從各種技術的一些基本的原理,到他在專案裡的各種結合業務是如何落地實踐的,平時遇到哪些坑是怎麼解決的,然後深入的一些技術的底層原始碼級別。
這個同學,都可以回答的非常的好,基本能完全hold住面試官的各種問題。
但是第二位同學呢,那就差很多了,基本上面試的時候,面試官各種發問之下,確實發現這個人對各種技術都有一定的瞭解,比如說JUC、RocketMQ、Kafka、Dubbo、Redis等技術,或多或少都知道一些。
但是呢,如果往深了問,比如問他RocketMQ在專案裡到底是怎麼用的?為什麼要用?不用行不行?抗了多大的併發?這些問題,他就沒法說了。
為什麼呢?因為在一些小公司裡,可能對MQ用的很簡單,甚至都沒用,所以他的實踐經驗並不是很多,他只是業餘時間自己學習過一些基本的使用和原理而已。
然後再往深了問,說能不能來聊聊原始碼之類的,那他更加是說不出來了,因為根本沒能力去精讀一個開源技術的原始碼。
所以最後在面試官的眼裡,第一位同學,技術廣度足夠,技術深度紮實,實踐經驗也豐富。
第二位同學,技術廣度差強人意,還算是知道一些,但是技術深度幾乎沒有,實踐經驗也幾乎很少。明顯第一位同學的技術能力要高出第二位同學一大截。
這就是兩個人的硬核技術能力的差距,在面試的時候會直接影響面試官的考察。
(5)架構能力的差距
在面試的過程中除了硬核技術能力之外,非常關鍵體現不同的人的層次和水平的,還有架構設計的能力的差距。
面試官會深入考察你在一個專案裡扮演的是個什麼角色,首先會摸清楚你們一個完整的大系統是多大規模,你在裡面是負責了哪些東西,有沒有帶人,帶人是做什麼的。
接著會仔細考察你對自己系統的設計能力,什麼樣的業務場景,業務多複雜,技術挑戰有多高。
然後你如何整體規劃和設計你的系統,你如何分配子系統和任務給你帶的一個團隊,如何把控一個團隊來推進一個大系統的開發。
另外,面試官還會出一些你沒經歷過的系統設計題目,看看你在短時間內,隨機應變,能否把一個陌生背景下的系統設計出來一個雛形。
通過這些,可以看出你在系統設計的時候,各個點的考慮是否合理,能否全域性把控一個系統,能夠把控多大的系統。
這類問題可以完美區分出來一個人的能力。你是到了技術專家的水平,可以帶團隊負責一個大系統呢?還是說只能帶一兩個小弟作為高階工程師負責一個大系統中的一兩個子系統?通過這一系列的架構能力的拷問,就可以區分出來。
所以第一位同學,他本身就帶了幾個小弟,算是一個小的團隊,而且負責了幾個子系統,他可以很好的說出來自己負責的業務場景。
比如說像使用者量,併發量,資料量,請求量,技術挑戰,技術複雜度,如何規劃和設計一個大系統的,如何給小兄弟分配任務的,怎麼把控一個大系統不斷推進和演進的。這些東西,他都可以說出來。
而第二位同學,就差很多了,他本身在小公司裡最多就帶過1個小弟一起負責某個子系統的開發,沒獨立把控過一個大的系統,而且做的系統也沒太大的技術挑戰,最後說出來的系統架構也很簡單,沒太多的技術挑戰。
所以在這裡,又是體現和區分出了兩個人的能力的差距。
(6)面試結果的分析
最後綜合以上幾點,我們先不考慮其他的因素,比如說軟素質(溝通能力、表達能力、團隊協作能力,等等)。
就上面幾塊分析,大家就可以看到了。第一位同學,學歷更好,潛力更好,技術過硬,能帶團隊,在大廠把控過有技術挑戰的大系統。
所以對於一個獨角獸公司而言,在招聘技術專家的時候,是會選擇這位同學發offer的,因為他來了就可以帶一個團隊,把一個完整的系統抗起來,各種架構設計,團隊管理,技術能力,都可以hold住。
但是第二位同學,學歷普通,潛力一般,技術平平沒太大亮點,也沒太好的架構能力和經驗,又一直在各種小公司裡幹。
最後綜合一考量,甚至可能會招聘一個兩三年經驗的大廠同學到獨角獸公司團隊給高階工程師的offer,而不是要一個四五年經驗的小公司出身的工程師,所以最後這位同學連獨角獸公司的offer都沒拿到。
相信大家看完這篇文章,應該可以從各個層面瞭解到自己的一些欠缺和差距,以及在求職的時候,出身小公司的同學為什麼屢屢受挫,好機會很少。
但是大家也不用因此洩氣,小公司的工程師也是可以逆襲衝進BAT大廠的,只要大家堅持和努力,給自己定好明確的規劃,一步一個腳印慢慢走,就一定可以做到,最難的,是你決定開始的那一步。
而關於如何規劃準備,如何面試,可以參見筆者以前的一篇文章:
「非廣告,純乾貨」中小公司的Java工程師應該如何逆襲衝進BAT?。
(封面,圖源網路,侵權刪除)
掃描下方二維碼,備註:“資料”,獲取更多“祕製” 精品學習資料
一大波微服務、分散式、高併發、高可用的原創系列文章正在路上
歡迎掃描下方二維碼,持續關注:
石杉的架構筆記(id:shishan100)
十餘年BAT架構經驗傾囊相授
推薦閱讀:
2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問?
3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰
6、大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問
7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍
9、【坑爹呀!】最終一致性分散式事務如何保障實際生產中99.99%高可用?
11、【眼前一亮!】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上?
16、億級流量系統架構之如何設計全鏈路99.99%高可用架構
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、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(下)?
37、億級流量系統架構之如何保證百億流量下的資料一致性(上)
38、億級流量系統架構之如何保證百億流量下的資料一致性(中)?
39、億級流量系統架構之如何保證百億流量下的資料一致性(下)?
40、網際網路面試必殺:如何保證訊息中介軟體全鏈路資料100%不丟失(1)
41、網際網路面試必殺:如何保證訊息中介軟體全鏈路資料100%不丟失(2)
42、面試大殺器:訊息中介軟體如何實現消費吞吐量的百倍優化?
43、高併發場景下,如何保證生產者投遞到訊息中介軟體的訊息不丟失?
45、從團隊自研的百萬併發中介軟體系統的核心設計看Java併發效能優化
46、【非廣告,純乾貨】英語差的程式設計師如何才能無障礙閱讀官方文件?
47、如果20萬使用者同時訪問一個熱點快取,如何優化你的快取架構?
48、【非廣告,純乾貨】中小公司的Java工程師應該如何逆襲衝進BAT?
50、【金三銀四跳槽季】Java工程師如何在1個月內做好面試準備?
51、【offer收割機必備】我簡歷上的Java專案都好low,怎麼辦?
52、【offer去哪了】我一連面試了十個Java崗,統統石沉大海!
53、高階Java開發必備:分散式系統的唯一id生成演算法你瞭解嗎?
54、支撐日活百萬使用者的高併發系統,應該如何設計其資料庫架構?
55、尷尬了!Spring Cloud微服務註冊中心Eureka 2.x停止維護了咋辦?
56、【Java高階必備】如何優化Spring Cloud微服務註冊中心架構?
作者:石杉的架構筆記
連結:https://juejin.im/post/5c6a9f25518825787e69e70a
來源:掘金
著作權歸作者所有。商業轉載請聯絡作者獲得授權,非商業轉載請註明出處。