【非廣告，純乾貨】本科畢業3年的我，是如何薪資翻倍拿到38萬年薪Offer的？【石杉的架構筆記】

【本文是公衆號讀者投稿的面試經歷，感謝你們分享本身的面試經歷給其餘廣大同窗參考】

目錄：

1、以往履歷

2、技術積累

2.1 公司裏的積累

2.2 業餘時間的積累

3、面試過程

3.1 一面：深挖技術

3.1 二面：結合項目

3.3 三面：聊薪資、聊理想、聊人生

先說一下這位同窗的面試成果，普通本科學歷，畢業僅僅3年，原先年薪也才20萬，可是最近跳槽一舉拿下年薪38萬的offer。

如下是這位同窗整理的此次面試通過的一些心得體會，供廣大同窗參考

1、以往履歷

以前經歷過的都是小的互聯網創業公司，技術氛圍很差，過程管理也不規範，作過的項目也都是一個個的風投項目，容易被市場優勝劣汰下來。

進入大公司一直是個人夢想也是個人情結，可是目前年限不夠。因此先沉澱一下，找了一家B輪融資的互聯網公司，但願下次有幸能寫面經的時候可以收到大廠的offer。

2、技術積累

2.1 公司裏的積累

① 珍惜項目帶來的技術挑戰

以前作一個項目時，遇到了地理位置相關的技術挑戰，因而接觸到了GeoHash算法。

當時是使用mongo存儲經緯度 + geo計算來解決了這個問題。

在這個過程就會對MongoDB技術進行必定的研究，並且對地理位置相關的問題也會有必定的經驗積累。

作另一個項目時接觸到了千萬級別的用戶量，在搞活動的時候受到了高併發挑戰。

用戶量很大時，高併發請求後臺系統，對交易鏈路形成了壓力，這裏應該如何解決也有了必定的積累。

還有就是我在作一個公司全新探索性項目時，因爲是全新的領域，須要進行必定的領域建模。在建模的過程當中，大大鍛鍊了本身的系統設計能力。

② 珍惜團隊管理的機會

印象很深入的一點是，當時因爲一個探索性的項目屬於公司的試點項目，剛開始後端研發人員就3我的。

因此咱們做爲老員工，在後麪糰隊擴招時也瓜熟蒂落的成了小組leader之類的角色。

新領域有技術調研的困難，也有需求合理性的苦惱，加上剛開始人員很少，基本上是加班特別嚴重的。

因而公司高層引入了敏捷開發，咱們成立了一個個scrum小組，需求拆解，迭代任務，物理看板，每日站立會。

第一次接觸scrum給個人職業生涯帶來了很大的衝擊，而團隊管理也讓我從另外一個角度來認識整個團隊的容量和交付能力。

可是一旦把此次機會把握住了，就能夠快速積累帶一個小團隊的能力，包括人員招聘、項目管理、團隊管理、任務拆分、進度追蹤、保證產出，等等。

2.2 業餘時間的積累

① 善於總結和複習

1）週期性總結，有利於對知識的整理記憶。

本身平時會學習不少的技術，好比Java併發、緩存、MQ、微服務、分佈式，等等。

可是其實人有一個很大的問題，就是學完就會忘。這個是很正常的，人不是神仙，誰不會忘呢？

因此說必定要週期性的複習，這樣你每年纔會發現本身把不少技術都掌握的很紮實。

2）有段落標題有總結的文字比一堆文字更直觀

對於本身平時學習的時候記錄的筆記，不是說寫一堆文字就能夠的，咱們都須要本身提煉一番，概括出一堆小標題。

經過小標題的形式串聯起來大量的知識點，在複習的時候，哪怕就是看到標題就知道背後的知識點。

② 尋根究底

平時在學習一些技術的時候，每每會找不少的書籍還有視頻。

可是其實在學習的時候，不光是吸取書籍或者視頻裏的東西，還要有本身主動思考的能力。

舉幾個例子：好比以前研究Spring Cloud技術的時候，就對裏面不少技術都有本身的思考，而後帶着本身思考的問題主動去裏面進行探索。

一、我對Ribbon做爲負載均衡技術，在Spring Cloud源碼內部的一些實現細節上，有如下的疑問：

• springclientfactory原理是什麼？

• 誰觸發注入了springclientfactory？

• 爲何ribbon這裏的整合使用springclientfactory，還有其餘方式嗎？

• 將bean注入ioc容器的方式有哪些？

• 自動配置的原理是什麼？

• spring.factories和jdk的spi有什麼異同？

而後會帶着這些問題去深刻探索Spring Cloud源碼的一些實現。

二、我對Zuul做爲SpringCloud的網關也有疑問：

路由表只是從配置文件讀取的嗎，會不會從serverList裏動態刷新路由表呢？

帶着這個問題也會去探究其底層源碼。

三、對MySQL技術，個人疑問是：

mvcc機制爲innodb提供了讀寫併發的能力，快照讀都是經過隱藏的事務ID列來讀取快照數據？

此時能夠再深刻研究innodb的其餘細節：

• innodb的事務的ACID特性是如何實現的？
• undo日誌是存儲在哪的，快照讀是怎麼和undo日誌結合起來的？

③ 培養獨立看源碼，畫圖的能力（重要性：5顆星）

第三個，平時必定要創建起來本身獨立看源碼的能力。

好比說以前我經過一些網上的博客，大概看過裏面對Atomikos、ByteTCC的源碼的分析，瞭解了XA事務和TCC事務的執行流程和框架設計。

優秀的分佈式事務框架其實也有不少，在ByteTCC中，cancel是和try對應的，若是confirm失敗，便會根據事務日誌一直重試，這是ByteTCC的設計理念。

可是，咱們還能夠看看其餘TCC框架，如tcc-transaction、Hmily他們在TCC方面的設計理念。

根據看源碼的方式，先大體瀏覽文檔，跑一個demo，找單元測試和框架入口。

先讀靜態源碼，再debug跟進，邊調試邊畫流程圖

慢慢的，這種獨立看源碼和畫圖的能力能夠獲得很大提高，從怕看源碼到愛看源碼。

3、面試過程

其實這家公司，由於我知道他是一家B輪融資發展很好的公司，因此直接就去面試了。

本身此次的目標，就是找一家發展潛力好的中型互聯網公司，而不是直接進大廠，由於本身知道年紀過輕，直接面大廠信心還有所不足，就想先沉澱一下。

3.1 一面

① jvm類加載機制，什麼時候觸發類的加載和卸載

主要說了Java爲了實現語言的靈活性，採用了在運行時動態加載字節碼，以及加載、鏈接、初始化的各個步驟流程。

還說了加載使用的雙親委派模型以及其打破該模型的案例，各個類加載器加載什麼樣的類，如何自定義類加載器。

對類的七種主動使用觸發類的加載，類的卸載的條件。

總結起來：主要就是圍繞類加載，聊了一些老生常談的問題。面試官確定是知道，可是答的時候，要儘量的多說多擴展。

這樣可讓面試官知道咱們大體的知識範圍，也掌握面試主動性。

② gc算法

說gc算法以前，先聊瞭如何判斷一個對象能夠被回收，我說了引用計數法，GC Root等方式，回收對象的流程。

而後先從標記清除算法開始談，說出其優缺點，從而引伸出複製清除和標記整理算法。各個算法聊完以後，引伸出分代清除算法。

聊完算法便開始聊各類垃圾收集器的特色和使用場景。

這裏個人一點感覺是：不少知識點其實不是死記硬背的，而是前人設計的智慧或者是妥協。

咱們能夠按邏輯分析的方式跟面試官侃侃而談，用分析問題的方式來回答，而不是死背答案的方式。

③ nio，aio，netty

這方面其實不太熟，直接跟面試官代表對這方面有欠缺，可是有必定本身的瞭解。

主要從傳統的bio模型開始提及，而後說到tomcat在bio模型下同步阻塞的問題。

接着說了爲何要設計nio這同步無阻塞的模型，是怎麼經過一個selector多路複用來監控多個channel的。

最後還聊了聊aio的異步無阻塞模型的大體概念，nio基於事件的同步無阻塞模型適用於服務器端編程，aio異步無阻塞適用於大文件讀取。

這裏給你們分享的一點心得就是，不熟悉的知識點千萬不要亂掰，浪費面試官時間，也讓本身在面試中處於被動形勢。

能夠先代表本身對該知識點有欠缺，再大體說說本身的瞭解，讓面試官快速瞭解本身的水平。

④ innodb的索引結構

直接和麪試官說了innodb的BTree索引的B+樹，說說其存儲結構和優勢。再聊到了彙集索引和輔助索引。

後來補充了下二叉查找樹，鏈表，hash，B樹的優劣勢以及爲何會選擇用B+樹來做爲索引結構。

儘可能多從本身做爲設計者的角度來回答問題，表現出分析和表述能力。

⑤ 一致性hash

• 先聊hash算法的優勢
• 再聊一致性hash的使用場景：
• 分佈式環境下多節點負載數據
• 防止節點的動態增減影響到大範圍的數據
• 再聊一致性hash的原理，如何實現，本身實現該算法的思路
• 再聊其餘中間件對其的實現，如redis-cluster的hash slot方式

⑥ redis的持久化、哨兵、cluster

這些都是老生常談的問題，基本上你只要看過石杉老師的億級流量課程，均可以輕鬆的回答。

⑦ synchronized的原理

先聊了sync的指令，再說其加鎖的原理。

而後聊到了JDK 1.6對其的優化（自旋鎖，自適應自旋，偏向鎖等），而後說到了sync和wait、notify這對黃金搭檔。

⑧ AQS、CAS、以及其餘組件

說完sync，面試官就問了JDK的可重入鎖，問其實現原理。

天然而然的就說到了AQS，以及可重入鎖的那一套原理，而後瓜熟蒂落的聊了公平鎖，非公平鎖。

接着面試官就問了使用AQS的其餘組件，而後就聊了讀寫鎖，信號量，CountDownLatch、ThreadPoolExecutor等的原理。

⑨ 讓你實現一個RPC框架該如何設計

• 通信協議
• 序列化方式
• SPI擴展
• 底層代理
• 超時、重試、負載均衡
• 攔截器、插件等自定義支持
• 註冊中心的選型與交互

這類開放式問題按照我我的的理解，應該不是讓咱們直接回答底層很詳細的細節，而是從很hign level的級別來談談須要考慮哪些點。

⑩ 設計秒殺系統

我自己沒作過秒殺系統，以前也沒怎麼看過相關的設計，只記得以前上班通勤的時候偶爾翻過幾篇博文，因而帶着本身的分析跟面試官談的。

• 臨時機器、帶寬申請，環境隔離，不要影響主體業務
• 與產品溝通，前端限流方式是否影響用戶體驗（如答題、拼圖等）
• 預估用戶量：好比只有40%的用戶能搶到，那麼直接讓50%的用戶當即秒殺失敗，不進入後續服務
• 後端作好流量控制，限流降級，一些非核心的數據作好多級緩存
• 層級過濾下的少許用戶，進入秒殺核心邏輯，這時候有多種方式：
• 使用隊列（削峯，串行化，扛併發）
• redis的incr（單線程）
• 分佈式鎖（能夠聊聊分段加鎖，增大分佈式鎖的TPS）
• 再聊聊產品需求設計，是採用下單即鎖定庫存仍是支付才鎖定庫存

3.2 二面

二面比較關注個人項目經驗，主要問了我最近的一個項目以及項目的用戶量，訂單量，交易量，QPS，TPS等。

另外還問了相關的業務，看我是否對一個項目及業務有着完整的理解，而後跟着項目問了一些簡歷上寫到的東西。

① 分佈式事務

跟面試官聊了分佈式事務的各類解決方案以及適用場景，大體聊了下具體的細節。

② 分佈式鎖

不少人聊分佈式鎖喜歡單刀直入的直接聊redis和zk鎖，我喜歡先聊分佈式鎖的原理。

其實就是在分佈式系統中，找一個全局惟一的第三方的一個標識，某個節點的某個線程，獲取到該標識，即爲獲取到分佈式鎖。

相應的方案有不少：

• 基於某個遠程本地文件鎖（只有某個線程能惟一建立一個文件）
• 基於數據庫某張表的惟一索引
• 基於Redis的setnx/lua實現
• 基於zk的瞬時序列節點實現

再一個個聊他們的優缺點以及本身是如何在項目中封裝落地的。

③ 限流算法

• 單節點限流：簡單的聊了下漏斗和令牌桶算法以及他們的特性
• 集羣限流：想了想用Redis作信號量

順便聊了下Hystrix的信號量以及線程池限流。

④ 設計模式

設計模式我我的掌握的很熟，這也是很基礎的東西。

主要聊了在上一個項目的哪些場景使用了哪些設計模式，爲何要用該模式。

而後又補充了一下，一些第三方框架裏使用的一些設計模式。

⑤ RabbitMQ

由於項目用的是RabbitMQ，因此主要聊的是他的使用場景，如何保證消息儘量不丟失，RabbitMQ的集羣模式。都是很基礎的問題。

⑥ 手寫ArrayList

這個沒什麼好說的，相信看過相關源碼都能寫出來。

⑦ 不使用鏈表怎麼讓HashMap有序

問問題的時候，二面面試官邊面試還在邊拿着本子修復線上bug（看起來來的不是時候...）

當時考慮時間很短，沒有什麼好的想法。

因而說HashMap爲何插入讀取是無序的，由於其爲了快速查找定位的hash算法，致使其在數組中散列。

若是不使用鏈表記錄順序的話，可能就想着有個有序的隊列之類的來記錄索引，從而遍歷。

答完以後，我的感受答得很差，不過也過了。

3.3 三面

三面主要是人事面，聊了聊公司業務，公司目前融資狀況，公司人員狀況。

人事主要就是聊人生聊理想，問了問上一家離職緣由，指望薪資以及入職時間。

最後由於一面和二面，幾乎技術面試無死角無短板，哪怕是不擅長的技術問題，也會給出本身的一些思考。

因此最後獲得了面試官一致的承認，直接就給出了38萬年薪的offer，本身也沒有繼續面試，直接就去了這家公司。

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

歡迎關注公衆號：石杉的架構筆記

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

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