經(jīng)過半年的沉淀，加上對MySQL，redis和分布式這塊的補齊，終于開始重拾面試信心，再次出征。

鵝廠

面試職位：go后端開發(fā)工程師，接受從Java轉語言

都知道鵝廠是cpp的主戰(zhàn)場，而以cpp為背景的工程師大都對os，network這塊要求特別高，不像是Java這種偏重業(yè)務層的語言，之前面試Java的公司側重還是在數(shù)據(jù)結構、網(wǎng)絡、框架、數(shù)據(jù)庫和分布式。所以OS這塊吃的虧比較大

一面基礎技術面

電話面試，隨便問了些技術問題，最后還問了個LeetCode里面medium級別的算法題，偏簡單

redis有沒有用過，常用的數(shù)據(jù)結構以及在業(yè)務中使用的場景，redis的hash怎么實現(xiàn)的，rehash過程講一下和JavaHashMap的rehash有什么區(qū)別？redis cluster有沒有了解過，怎么做到高可用的？redis的持久化機制，為啥不能用redis做專門的持久化數(shù)據(jù)庫存儲？

了不了解tcp/udp，說下兩者的定義，tcp為什么要三次握手和四次揮手？tcp怎么保證有序傳輸?shù)?，講下tcp的快速重傳和擁塞機制，知不知道time_wait狀態(tài)，這個狀態(tài)出現(xiàn)在什么地方，有什么用？（參考quic）

知道udp是不可靠的傳輸，如果你來設計一個基于udp差不多可靠的算法，怎么設計？

http與https有啥區(qū)別？說下https解決了什么問題，怎么解決的？說下https的握手過程。

看你項目里面用了etcd，講解下etcd干什么用的，怎么保證高可用和一致性？

既然你提到了raft算法，講下raft算法的基本流程？raft算法里面如果出現(xiàn)腦裂怎么處理？有沒有了解過paxos和zookeeper的zab算法，他們之前有啥區(qū)別？

你們后端用什么數(shù)據(jù)庫做持久化的？有沒有用到分庫分表，怎么做的？

索引的常見實現(xiàn)方式有哪些，有哪些區(qū)別？MySQL的存儲引擎有哪些，有哪些區(qū)別？InnoDB使用的是什么方式實現(xiàn)索引，怎么實現(xiàn)的？說下聚簇索引和非聚簇索引的區(qū)別？

有沒有了解過協(xié)程？說下協(xié)程和線程的區(qū)別？

算法題一個，劍指offer第51題，數(shù)組中的重復數(shù)字？

自己的回答情況，redis這塊沒啥問題，具體rehash有印象是漸進式的，但是具體原理可能答的有點出入。tcp的time_wait這塊答的不是很好，之前沒有了解過quic機制的實現(xiàn)，所以問可靠性udp的時候，基本上腦子里就照著tcp的實現(xiàn)在說。https這塊沒啥說的，之前項目里面有用到類似的東西，研究的比較清楚了。raft算法這個因為剛好在刷6.824（才刷到lab2。。。），答的也湊合，不過paxos和zab算法確實不熟悉，直接說不會。MySQL這塊很熟了，包括索引，鎖，事務機制以及mvcc等等，沒啥說的，都已經(jīng)補齊了。協(xié)程和線程，主要說了go程和Java線程的區(qū)別以及go程的調度模型。面試官提示沒有提到線程的有內核態(tài)的切換，go程只在用戶態(tài)調度。最后一個算法題，首先說使用HashMap來做，說空間復雜度能不能降到O（1），后面想了大概5min才想出來原地置換的思路。

二面項目技術面

主要針對自己最熟悉的項目，畫出項目的架構圖，主要的數(shù)據(jù)表結構，項目中使用到的技術點，項目的總峰值qps，時延，以及有沒有分析過時延出現(xiàn)的耗時分別出現(xiàn)在什么地方，項目有啥改進的地方?jīng)]有？

如果請求出現(xiàn)問題沒有響應，如何定位問題，說下思路？

tcp 粘包問題怎么處理？

問了下緩存更新的模式，以及會出現(xiàn)的問題和應對思路？

除了公司項目之外，業(yè)務有沒有研究過知名項目或做出過貢獻？

基本都沒有啥問題，除了面試官說項目經(jīng)驗稍弱之外，其余還不錯。

三面綜合技術面

這面面的是陣腳大亂，面試官采用刨根問底的方式提問，終究是面試經(jīng)驗不夠，導致面試的節(jié)奏有點亂。 舉個例子：

其中有個題是go程和線程有什么區(qū)別？

答：1 起一個go程大概只需要4kb的內存，起一個Java線程需要1.5MB的內存；go程的調度在用戶態(tài)非常輕量，Java線程的切換成本比較高。接著問為啥成本比較高？因為Java線程的調度需要在用戶態(tài)和內核態(tài)切換所以成本高？為啥在用戶態(tài)和內核態(tài)之間切換調度成本比較高？簡單說了下內核態(tài)和用戶態(tài)的定義。接著問，還是沒有明白為啥成本高？心里瞬間崩潰，沒完沒了了呀，OS這塊依舊是痛呀，支支吾吾半天放棄了。

后面所有的提問都是這種模式，結果回答的節(jié)奏全無，感覺被套路了。大多度都能回答個一二甚至是一二三，但是再往后或者再深入的OS層面就GG了。

后面問了下項目過程中遇到的最大的挑戰(zhàn)，以及時怎么解決的？

后面還問了一個問題定位的問題，服務器CPU 100%怎么定位？可能是由于平時定位業(yè)務問題的思維定勢，加之處于蒙蔽狀態(tài)，隨口就是：先查看監(jiān)控面板看有無突發(fā)流量異常，接著查看業(yè)務日志是否有異常，針對CPU100%那個時間段，取一個典型業(yè)務流程的日志查看。最后才提到使用top命令來監(jiān)控看是哪個進程占用到100%。果然陣腳大亂，張口就來，捂臉。。。

本來正確的思路應該是先用top定位出問題的進程，再用top定位到出問題的線程，再打印線程堆棧查看運行情況，這個流程換平時肯定能答出來，但是，但是沒有但是。還是得好好總結。

最后問了一個系統(tǒng)設計題目（朋友圈的設計），白板上面畫出系統(tǒng)的架構圖，主要的表結構和講解主要的業(yè)務流程，如果用戶變多流量變大，架構將怎么擴展，怎樣應對？

這個答的也有點亂，直接上來自顧自的用了一個通用的架構，感覺毫無亮點。后面反思應該先定位業(yè)務的特點，這個業(yè)務明顯是讀多寫少，然后和面試官溝通一期剛開始的方案的用戶量，性能要求，單機目標qps是什么等等？在明確系統(tǒng)的特點和約束之后再來設計，而不是一開始就是用典型互聯(lián)網(wǎng)的那種通用架構自顧自己搞自己的方案。

3天后收到短信被拒

總結

tcp/udp，http和https還有網(wǎng)絡這塊（各種網(wǎng)絡模型，已經(jīng)select，poll和epoll）一定要非常熟悉

一定要有拿的出手的項目經(jīng)驗，而且要能夠講清楚，講清楚項目中取舍，設計模型和數(shù)據(jù)表

分布式要非常熟悉

常見問題定位一定要有思路

操作系統(tǒng)，還是操作系統(tǒng)，重要的事情說三遍

系統(tǒng)設計，思路，思路，思路，一定要思路清晰，一定要總結下系統(tǒng)設計的流程

一點很重要的心得，平時blog和專欄看的再多，如果沒有自己的思考不過是過眼云煙，根本不會成為自己的東西，就像內核態(tài)和用戶態(tài)，平常也看過，但是沒細想，突然要自己說，還真說不出來，這就很尷尬了。勿以浮沙筑高臺，基礎這種東西還是需要時間去慢慢打牢，多去思考和總結。