作者:codegoose
https://segmentfault.com/a/1190000017864721
文中的我,不是 chenssy ,而是作者本人。很多我都想進大廠,也都知道進大廠很難很難,而且面試週期也長(筆試、初試、覆試、終試)。今天給大家帶來作者的三面鵝廠的經歷,希望對大家有所幫助,有所借鑒!!
經過半年的沉澱,加上對MySQL,redis和分散式這塊的補齊,終於重拾面試信心,再次出征。
鵝廠
面試職位:go後端開發工程師,接受從Java轉語言
都知道鵝廠是cpp的主戰場,而以cpp為背景的工程師大都對os,network這塊要求特別高,不像是Java這種偏重業務層的語言.
之前面試Java的公司側重還是在資料結構、網路、框架、資料庫和分散式。所以OS這塊吃的虧比較大
一面:基礎技術面
電話面試,隨便問了些技術問題,最後還問了個LeetCode裡面medium級別的演演算法題,偏簡單。大概整理回憶了一下:
-
redis有沒有用過,常用的資料結構以及在業務中使用的場景。
-
redis的hash怎麼實現的?
-
rehash過程講一下和JavaHashMap的rehash有什麼區別?
-
redis cluster有沒有瞭解過,怎麼做到高可用的?
-
說說redis的持久化機制,為啥不能用redis做專門的持久化資料庫儲存?
-
了不瞭解tcp/udp,說下兩者的定義,tcp為什麼要三次握手和四次揮手?
-
tcp怎麼保證有序傳輸的,講下tcp的快速重傳和擁塞機制
-
知不知道time_wait狀態,這個狀態出現在什麼地方,有什麼用?
-
udp是不可靠的傳輸,如果你來設計一個基於udp差不多可靠的演演算法,怎麼設計?
-
http與https有啥區別?說下https解決了什麼問題,怎麼解決的?說下https的握手過程。
-
看你專案裡面用了etcd,講解下etcd乾什麼用的,怎麼保證高可用和一致性?
-
既然你提到了raft演演算法,講下raft演演算法的基本流程?raft演演算法裡面如果出現腦裂怎麼處理?
-
有沒有瞭解過paxos和zookeeper的zab演演算法,他們之前有啥區別?
-
你們後端用什麼資料庫做持久化的?有沒有用到分庫分表,怎麼做的?
-
索引的常見實現方式有哪些,有哪些區別?
-
MySQL的儲存引擎有哪些,有哪些區別?
-
InnoDB使用的是什麼方式實現索引,怎麼實現的?說下聚簇索引和非聚簇索引的區別?
-
有沒有瞭解過協程?說下協程和執行緒的區別?
-
演演算法題一個,劍指offer第51題,陣列中的重覆數字?
從上面的情況來看,面試大廠redis/MySQL都是比較重要的,正好前兩天還發了兩篇相關的文章:面試必問!5 分鐘帶你搞定 Redis 複製(全會的舉個手看看)|Mysql千萬級別資料批次插入只需簡單三步!正好複習一下。
大概說下我自己的回答情況,redis這塊沒啥問題,具體rehash有印象是漸進式的,但是具體原理可能答的有點出入。
tcp的 time_wait 這塊答的不是很好,之前沒有瞭解過quic機制的實現,所以問可靠性udp的時候,基本上腦子裡就照著tcp的實現在說。
https這塊沒啥說的,之前專案裡面有用到類似的東西,研究的比較清楚了。
raft演演算法這個因為剛好在刷6.824(才刷到lab2。。。),答的也湊合,不過paxos和zab演演算法確實不熟悉,直接說不會。
MySQL這塊很熟了,包括索引,鎖,事務機制以及mvcc等等,沒啥說的,都已經補齊了。
協程和執行緒,主要說了go程和Java執行緒的區別以及go程的排程模型。面試官提示沒有提到執行緒的有核心態的切換,go程只在使用者態排程。
最後一個演演算法題,首先說使用HashMap來做,說空間複雜度能不能降到O(1),後面想了大概5min才想出來原地置換的思路。
總得來說,答的還行,一面就這麼過了。
二面:專案技術面
二面從基礎技術考察轉移到了專案,主要問了我下麵一些問題:
-
針對自己最熟悉的專案,畫出專案的架構圖,專案主要的資料表結構。
-
說說專案中使用到的技術點,專案的總峰值qps,時延。
-
有沒有分析過時延出現的耗時分別出現在什麼地方,專案有啥改進的地方沒有?
-
如果請求出現問題沒有響應,如何定位問題,說下思路?
-
tcp 粘包問題怎麼處理?
-
然後還問了下快取更新的樣式,以及會出現的問題和應對思路?
-
除了公司專案之外,業餘時間有沒有研究過知名專案或做出過貢獻?
這一面答的也比較順利,因為都是圍繞專案,自己很熟悉,基本都沒有啥問題,除了面試官說專案經驗稍弱之外,其餘還不錯。
三面:綜合技術面
這面面的是陣腳大亂,面試官採用刨根問底的方式提問,終究是面試經驗不夠,導致面試的節奏有點亂。舉個例子:
其中有個題:go程和執行緒有什麼區別?
答:起一個go程大概只需要4kb的記憶體,起一個Java執行緒需要1.5MB的記憶體;go程的排程在使用者態非常輕量,Java執行緒的切換成本比較高。
接著問為啥成本比較高?因為Java執行緒的排程需要在使用者態和核心態切換所以成本高?為啥在使用者態和核心態之間切換排程成本比較高?我簡單說了下核心態和使用者態的定義。
接著問,還是沒有明白為啥成本高?心裡瞬間崩潰,沒完沒了了呀,OS這塊依舊是痛呀,支支吾吾半天放棄了。
後面所有的提問都是這種樣式,結果回答的節奏全無,感覺被套路了。大多度都能回答個一二甚至是一二三,但是再往後或者再深入的OS層面就GG了。
後面問了下專案過程中遇到的最大的挑戰,以及怎麼解決的?
還問了一個問題定位的問題,伺服器CPU 100%怎麼定位?
可能是由於平時定位業務問題的思維定勢,加之處於矇蔽狀態,隨口就是:
-
先檢視監控面板看有無突發流量異常
-
接著檢視業務日誌是否有異常,針對CPU100%那個時間段,取一個典型業務流程的日誌檢視
-
最後才提到使用
top
命令來監控看是哪個行程佔用到100%
果然陣腳大亂,張口就來,捂臉。。。
對這個問題,本來正確的思路應該是先用top
定位出問題的行程,再用top
定位到出問題的執行緒,再列印執行緒堆疊檢視執行情況
這個流程換平時肯定能答出來,但是,但是沒有但是。還是得好好總結。
最後問了一個系統設計題目(朋友圈的設計),白板上面畫出系統的架構圖,主要的表結構和講解主要的業務流程,如果使用者變多流量變大,架構將怎麼擴充套件,怎樣應對?
這個答的也有點亂,直接上來自顧自的用了一個通用的架構,感覺毫無亮點。
後面反思應該先定位業務的特點,這個業務明顯是讀多寫少。然後和麵試官溝通一期剛開始的方案的使用者量,效能要求,單機標的qps是什麼等等?
在明確系統的特點和約束之後再來設計,而不是一開始就是用典型網際網路的那種通用架構自顧自己搞自己的方案。
面試結果:3天后收到簡訊,被拒
總結:
-
tcp/udp,http和https還有網路這塊(各種網路模型,已經select,poll和epoll)一定要非常熟悉「大廠對基礎的要求還是非常高的,所以基礎很重要」。
-
一定要有拿的出手的專案經驗,而且要能夠講清楚,講清楚專案中取捨,設計模型和資料表「說明專案經驗很重要」。
-
分散式要非常熟悉「進大廠必備的技能啊」。
-
常見問題定位一定要有思路「思路決定一切」。
-
作業系統,還是作業系統,重要的事情說三遍「底層的重要性」。
-
系統設計,思路,思路,思路,一定要思路清晰,一定要總結下系統設計的流程「說明一定要有自己的獨特的見解與想法」。
-
一點心得,平時blog和專欄看的再多,如果沒有自己的思考不過是過眼雲煙,根本不會成為自己的東西,就像核心態和使用者態,平常也看過,但是沒細想,突然要自己說,還真說不出來,這就很尷尬了。勿以浮沙築高臺,基礎這種東西還是需要時間去慢慢打牢,多去思考和總結「知識源於自已的思考與總結」。
朋友會在“發現-看一看”看到你“在看”的內容