【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷【石杉的架構筆記】

歡迎關注我的公衆號：石杉的架構筆記（ID:shishan100）

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

概述

以前寫過兩篇文章：

• 互聯網公司的面試官是如何360°無死角考察候選人的？（上篇）
• 互聯網公司面試官是如何360°無死角考察候選人的？（下篇）

經過這兩篇文章，咱們給你們聊了聊國內中大型互聯網公司，在Java面試時一些高頻的技術問題。

本文咱們經過一篇真實的一線面經，帶你們去體驗一下BAT等互聯網公司的面試現場氛圍！

背景介紹

PS：

面試者是筆者之前的下屬，多年的好朋友。

這是他今年早些時候出去面試，拿到BAT等多家一線互聯網公司技術專家Offer的面試經歷。

先介紹一下這位朋友的我的經歷：

• 本科畢業，接近10年工做經驗。跳槽以前，在國內某大型互聯網公司裏帶一個8人左右的技術團隊。
• 因爲公司業務發展較爲平緩，因此職業上升機會較少。
• 朋友對其負責的系統架構和技術已經很是熟悉，薪資上也較難有大幅度的增加，至於晉升更高的級別，短時間內也不容易。

所以，在仔細思考一番以後，決定出來看看機會，可否在帶團隊的規模、技術以及薪資上實現一個突破。

○一面○

一面是一個獵頭給朋友推的一個職位，BAT中某一個大廠的某個團隊，具體就不說是哪一個部門了。

一面就直接過去當面聊了一次，大概從下午2點聊到了下午4點多，時間很長，炮火至關猛烈。

一面面試官也是專家職級，上來就是先聊項目，針對項目中的各類細節仔細問，就項目展開，並且極其注重細節。

下面的內容，是根據朋友面試以後的回憶，整理出的部分問題。

面試一樣是經過互聯網公司最喜歡的連環炮形式發問。好比在面試過程當中，聊到了緩存。連環炮以下：

接着，面試官繼續深扣了不少細節

面試官：

• 那請說一下，這些請求具體是落在哪些接口上？
• 哪些數據是數據庫和緩存雙寫一份的？
• 雙寫一致性如何保證？保證一致性的同時如何保證高併發和性能？
• 緩存線上是如何部署的？給了多大的總內存？命中率有多高？
• 緩存抗了多少QPS？數據流回源會有多少QPS？
• 是否某個key出現了熱點緩存致使緩存集羣中某個機器的負載太高？如何解決的？
• 是否出現超大value打滿網卡的問題？如何規避這個問題？
• 線上是否出過緩存集羣事故？若是出現了大家怎麼解決有什麼高可用保障預案？
• 平時如何監控緩存集羣的QPS和容量？若是要擴容該怎麼擴？可否平滑擴容？擴容會致使系統須要停機嗎？
• 聊聊Redis的集羣原理？擴容的時候會不會致使數據丟失？key尋址算法都瞭解哪些？
• 你瞭解一致性hash算法嗎？畫個圖說說Redis線程模型和內存模型？

朋友：

紙筆翻飛，大腦高度運轉，一個接一個的回答。。。

如上所述，全部問題，所有結合項目，落地到生產中，同時注重聊技術的不少細節，包括技術的一些原理。

像緩存這樣的連環炮提問法，面試官還用來問了MQ、MySQL分庫分表、高可用、JVM、多線程併發，等各類問題。

簡單總結：

• 一面其實關注了技術廣度，同時結合項目死扣各類細節。
• 另外也兼顧了必定的技術深度，會就一個技術往深了問下去。

整體來講，一面還算順利，畢竟都是結合項目來問的，各類細節平時朋友進行架構設計時，都會仔細考慮過。

並且朋友也作過線上的高併發系統，踩過不少坑，因此這些問題基本都回答的不錯。

可是這裏給你們提醒一句，通常某個同窗出去面試，回來以後其餘人問他面試經驗，通常都是問：都有啥面試題？面試官是怎麼問的？

說實話，你們看了上面那些問題，可能會以爲說，哦，其實我也能夠答出來，沒什麼特別的。

但其實並非這樣，若是隻是拿高級崗位的Offer，你的技術會佔很大比重。

可是若是要拿專家崗位的Offer，你到底有沒有線上真實的高負載的系統架構經驗，很是重要。

一樣的問題，普通人會回答的很普通，可是經歷過真實幾十億流量請求的人必定會說出大量經驗總結、教訓以及採坑。

並且對整套複雜的大型系統究竟是如何抗住高併發的，會了然於胸，熟悉全部的細節。

因此針對一面，通常就是結合項目，深挖細扣，看你到底有多少水平，作過多複雜的系統。

這塊說實話，作過就是作過，沒作過就是沒作過，是不可能做假的。

不少同窗可能本身平時也看過不少書和博客，可是看書和博客只是基礎，若是沒有真實的線上生產環境的歷練，是確定不夠的。畢竟實踐出真知！

○二面○

一面就順利經過了，緊接着安排了第二輪面試。

二面面試官應該是這個團隊的leader，P8級別的，若是進去，應該就是朋友將來的頂頭上司。

據朋友講，二面面試官態度很是好，很和善，看來一面面試官反饋以後，這個team對朋友仍是比較重視的。

（1）技術深度

二面內容就從廣度變成深度了，面試官技術實力很深厚，應該是有十幾年經驗。對相關技術深挖了不少東西。

一樣，二面也聊到了緩存相關的問題。問了朋友具體瞭解過哪些緩存技術，redis、memcached，還有阿里開源的tair，哪一個瞭解過內核原理？

朋友以前看過一些redis的內核，就聊了聊redis內核的一些數據結構和實現原理。包括集羣、持久化在內核層面的一些東西。

此外在MQ這塊，朋友正好對kafka作過深刻的研究，就聊了聊Kafka的源碼。

好比KafkaController在故障轉移這塊的源碼，日誌存儲、網絡通訊的一些細節。如何保證磁盤讀寫的高性能，零拷貝那塊的底層實現，leader和follower之間的數據是如何同步的，都是從源碼層面來聊。

此外，還聊了dubbo的源碼以及mysql內核層面的東西。

（2）系統設計、工程素養、帶團隊

同時二面很是重視考察系統設計能力、工程素養、帶團隊的能力。

好比面試官就這個部門負責的一塊業務，出了一個相關的系統設計題目。

題目細節記不清楚了，大致內容是給出具體的用戶量、業務場景、併發量、數據量，而後讓你總體負責這個系統的架構設計。

朋友須要闡述本身的總體設計思路，從哪些點來考慮，存在着哪些技術挑戰，而且現場畫出來具體的架構設計圖。

工程素養這塊，讓朋友聊了聊平時如何作的技術設計、技術評審、編碼規範、測試、上線、回滾、灰度、壓測、監控等等。

帶團隊，讓朋友說一下，如何招人、面試標準、如何搭建團隊的人才梯度，等等。

（3）架構演進

此外，還會問一下，整個系統架構是如何一步一步進行演進的。

從0到1的時候是什麼架構？從1到10的時候是什麼架構？從10到100的時候是什麼架構？這塊就是看看你的總體架構能力，以及技術規劃能力。

說到這裏，筆者提一句，若是出去面試，尤爲是去BAT等大型互聯網公司面試，必須精心準備。

包括你的項目的每一個細節，你解決過的各類線上問題和坑，你簡歷裏的技術是否達到必定的深度，你平時其餘的工程、設計能力，這些都必定要精心準備一下。

絕對不要裸面！絕對不要裸面！絕對不要裸面！

重要的事情說三遍！裸面必敗，並且若是一問三不知，那麼給人的印象就是不好的。

若是要衝着心儀的大公司去，最起碼精心準備1個月以上，你們務必記住這一點，這也是朋友此次的一個重要心得，準備充分了，纔能有備無患。

○三面○

二面以後，又等了大概一兩週。。。

由於越往上面，領導級別越高，平時越忙，有時人家可能出差開會去了，不過等了一兩週，那邊總算約上了三面。

三面是總監級別的，不太肯定是走的M線仍是P線。若是是P線，那麼必定是P9，可是觀察面試風格應該是M線的總監。

這一面，聊技術其實並很少，更多的是跟朋友聊過往的各類公司的經歷和項目經驗，具體負責過哪些比較有挑戰的大型的系統。

另外，考察了各類軟素質。好比說責任心、抗壓能力、自我驅動，讓朋友舉例說明本身過去的一些事情，來證實軟素質。

同時還會聊聊職業價值觀，是否願意加班，等等吧。最後也聊了聊朋友的職場指望，包括這個團隊是幹什麼的，將來的發展方向之類的。

朋友以爲最重要的仍是前面兩面，其實這一面，只要人品端正，平時幹活兒認真負責，通常的都沒什麼太大的問題。

○終面○

接着又過了一兩個禮拜，由於當時二面面試官，也就是那個將來可能成爲朋友leader的人，對朋友仍是比較看重的，私下還短信聯繫了一段時間，就怕朋友跑去別的公司了。他告訴朋友說是由於HR那邊太忙了，因此終面還未安排上。

關於HR面，朋友印象真是至關之深入，爲何呢？由於HR是直接電話聊的，沒過去了，過去實在太折騰，並且二面面試官也是去打了招呼。

HR當時竟然是晚上11點打來的電話，人家剛剛加班開會結束，就打來了電話，真是不得不佩服其敬業精神！

並且這位HR是至關專業的，若是是普通的HR其實隨便聊聊就好了，可是這邊的HR問了不少問題，大概聊了1個小時左右。

主要是跟朋友聊了一些價值觀的東西，好比以前以爲作過最難的事情是啥，怎麼克服的，當時啥心態。

還有就是爲啥要離職，沒有發展空間？那當時沒考慮過公司內部transfer（轉崗）嗎？爲啥很差transfer？你的績效平時怎麼樣？你以爲你跟同事相處的怎麼樣？

終面內容，總結起來，其實仍是一句話，你人品正就行了，通常都問題不大，老老實實的踏實回答。

後來HR面了事後，那邊的薪資確實給到位了，達到了朋友的指望薪資。

可是那邊給的規劃是將來能夠帶的團隊人數也就是10人之內，並且不是配發集團股票，是配發的正在快速發展的這個團隊的期權。

因此朋友當時糾結了一下，但仍是先答應了，因而offer就發了過來。

後記

原本朋友想的是，若是沒有別的更好的機會，那麼這個機會也能夠考慮，畢竟薪資上仍是能夠的。

可是當時包括TMD（頭條、美團、滴滴）這邊，也都有人內推朋友過去試試，因此當時也面了其餘的幾個一線互聯網公司。

其實若是經歷了BAT這種互聯網公司的幾輪技術面試洗禮，那麼去國內任何一個公司都沒什麼問題了，因此當時面試也都很順利，得心應手。

一樣，朋友也不出意外的拿到了那些一線互聯網公司的offer。

通過一番對比，朋友最終沒有選擇去最初面試的那個BAT中的某個大廠，而是去了上面說的那幾個超級獨角獸公司中的其中一個。

緣由是這家超級獨角獸公司給出的薪資超出指望以外，並且領導對朋友一樣很是重視，配發了大量的期權，承諾能夠獨立帶20+人的團隊。

而朋友更看重的是這個超級獨角獸公司將來的潛力。

• 第一，公司發展速度快，人員擴張迅猛，因此給到的帶團隊的機會很是好，能帶更大的團隊，比朋友當前帶的團隊規模大了一倍多。
• 第二，雖然BAT的那家大廠一樣配發了期權，可是這家超級獨角獸的期權將來潛力可能更大。事實證實，的確如此。
• 因此綜合考慮了以後，朋友最終仍是根據本身的職業發展選擇了獨角獸公司，沒有再回到BAT行列中。

因爲公衆號再也不開通文章留言功能，若是對文章有什麼問題或者對公衆號有什麼建議，歡迎在公衆號聊天框留言交流！

END

若有收穫，請幫忙轉發，您的鼓勵是做者最大的動力，謝謝！

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

歡迎掃描下方二維碼，持續關注：

石杉的架構筆記（id:shishan100）

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

推薦閱讀：

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

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

三、【性能優化之道】每秒上萬併發下的Spring Cloud參數優化實戰

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

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

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

七、【性能優化的祕密】Hadoop如何將TB級大文件的上傳性能優化上百倍

八、拜託，面試請不要再問我TCC分佈式事務的實現原理坑爹呀！

九、【坑爹呀！】最終一致性分佈式事務如何保障實際生產中99.99%高可用？

十、拜託，面試請不要再問我Redis分佈式鎖的實現原理！

十一、【眼前一亮！】看Hadoop底層算法如何優雅的將大規模集羣性能提高10倍以上？

十二、億級流量系統架構之如何支撐百億級數據的存儲與計算

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

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

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

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

1七、七張圖完全講清楚ZooKeeper分佈式鎖的實現原理

1八、大白話聊聊Java併發面試問題之volatile究竟是什麼？

1九、大白話聊聊Java併發面試問題之Java 8如何優化CAS性能？

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

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

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

2三、互聯網公司的面試官是如何360°無死角考察候選人的？（上篇）

2四、互聯網公司面試官是如何360°無死角考察候選人的？（下篇）

2五、Java進階面試系列之一：哥們，大家的系統架構中爲何要引入消息中間件？

2六、【Java進階面試系列之二】：哥們，那你說說系統架構引入消息中間件有什麼缺點？