歡迎關注個人公眾號:石杉的架構筆記(ID:shishan100)
週一至週五早8點半!精品技術文章準時送上!
概述
之前寫過兩篇文章:
通過這兩篇文章,我們給大家聊了聊國內中大型網際網路公司,在Java面試時一些高頻的技術問題。
本文我們通過一篇真實的一線面經,帶大家去體驗一下BAT等網際網路公司的面試現場氛圍!
背景介紹
先介紹一下這位朋友的個人經歷:
- 本科畢業,接近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架構經驗傾囊相授
推薦閱讀:2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問?
3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰
6、大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問
7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍
8、拜託,面試請不要再問我TCC分散式事務的實現原理坑爹呀!
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°無死角考察候選人的?(下篇)