文章目錄

• 前言
• 得物
• • 一面
  • • 閑聊
    • GRPC
    • GO
• B站
• • 一面
  • • 閑聊
    • 領域驅動設計（DDD）
    • Go
    • 編程題
  • 二面
  • • DDD
    • 數據庫
    • 設計模式
    • 編程題
  • 三面
  • • 閑聊
• 百度
• • 一面
  • • 閑聊
    • 領域驅動設計
    • GO
    • 網絡通信
    • 數據庫
    • 算法題
  • 二面
  • • 閑聊
    • 領域驅動設計
    • 算法題
  • 三面
• 總結

前言

2021年底不幸經歷了裁員風波，盡管已經預感公司有點風雨飄搖的意思了，但是沒有想到來的這么快。

過完國慶后的一周。剛開完技術會議，方案定好，準備大干一場時，收到了leader的飛書，讓去會議室聊聊。leader表現的很誠懇，公司也是第一次大規模裁員，賠償方面也沒有卡。

木已成舟，從會議室出來后，筆者開始快速思考下一步該怎么走。第一次親身經歷裁員，內心的緊迫感是前所未有的。隨后的時間里，筆者開始開始整理過往工作經歷，瘋狂復習 + 刷題。在公司辦理完所有手續之后，一邊開始投遞簡歷，一邊繼續復習刷題。

最后的結果是，花了2周時間（離職前在公司一周，離職后在家一周），面試了3家公司，分別是得物，B站，百度（之后還有米哈游和字節，不過時間原因沒有在面），最終入職了B站。（筆者投遞的公司不多，內心緊迫感也比較強烈）

為何選擇B站，這里還有個小故事：筆者重度二次元，來上海之后一直想要進B站，無奈2年多以來兜兜轉轉始終沒有機會，沒想到最后以這種形式入職了（笑哭）

下面進入正題，來看看筆者所經歷的

得物

第一家面試的公司，也是最慘的一次面試，一面掛。（80%的時間處于痛苦面具的狀態）

一面

閑聊

聊一下上家公司的技術棧

有沒有做過Go項目（筆者之前一直從事python開發，上家開始轉型）

GRPC

項目中對GRPC框架進行了封裝，主要是封裝了什么

這塊表達的不是很好，與面試官產生了歧義；其實主要是就是封裝了一些常用的功能，比如注冊發現，Go程封裝，日志/埋點上報，簽名等等

Grpc底層的通信協議有什么，簡單講講

基于HTTP2，自然是HTTP協議，了解Grpc協議，可以參考這篇～

Grpc為什么采用這種協議，而不是別的

這個問題真的是靈魂發問，不了解很難答上，可以參考這條知乎問題

Grpc對HTTP2協議做了哪些改進（這塊聊的時候提了一嘴，把自己帶坑兒里了）

筆者就答了針對序列化協議做了改進，采用protobuf；支持流式傳輸；

Grpc的序列化方式有幾種

茴香豆的茴字有幾種寫法類型的問題，貌似筆者就知道protobuf，其他例如json或者xml不知道支不支持。

Grpc底層是靠什么傳輸的？

底層傳輸方式基于TCP，傳輸數據為二進制字節流

GO

簡單講講Go的高并發優勢在哪里

高并發的優勢自不必提，回答這個問題主要需要知道Go實現高并發的原理。詳細內容可以參這篇文章

簡單講講GMP模型

這個答案參考上一個問題

Go channel的實現原理

比較典型的考實現原理，這個問題可以參考這篇文章

深拷貝淺拷貝

這里充分解釋一下深拷貝和淺拷貝就可以了，可以結合go語言實現舉例說明；詳細可以參考這篇文章

Go Map的底層實現是什么

又是一個實現原理相關的問題，Map 的實現原理其實大同小異，可能在擴容和處理沖突上有些許區別。關于Go Map的實現原理，可以參考這篇文章

Go Map是協程安全的的嗎？如果并發操作一個map對象，安全性怎么保證。

先說結論，Go map不是線程安全的。但是Go語言提供了線程安全的SyncMap，了解SyncMap可以參考這篇文章

B站

3面
中規中矩，沒有特別難的問題，筆者對DDD有一些淺顯的認知，相當一部分時間都在聊關于DDD的架構設計。比較有意思的是，面試過程中只出了“編程題“，對算法的考量比較少。

一面

閑聊

為什么轉Go，python 和 Go 主要有哪些區別

各有優劣，沒必要捧一踩一。可以圍繞區別講講；筆者認為Go語言相較于Python更加適合高并發的工程項目。（雖然內心更喜歡python一些）

簡歷上提到了系統的性能優化，講講你做了哪些工作

緩存的設計，帶有緩存淘汰策略的內存緩存（LRU / 懶清理）

領域驅動設計（DDD）

DDD設計模式和MVC有什么區別

DDD展開來講東西比較多，很多人對DDD的理解也不盡相同，可以參考的文章很多，筆者這里列舉3篇：
DDD從天書到實踐
美團DDD實踐
后端開發–DDD編碼實踐

如果讓你來設計會員購板塊，你會怎么做

真正的好設計必須要建立在對需求的充分理解上，面試中主要結合DDD講出自己的理解即可。

Go

Go中并發讀10個文件，怎么做，如何保證每個并發任務能夠正確執行

不能保證，所以需要完善的異常捕獲 / 重試機制。簡單發散一下，在讀取文件的場景下可能會出現哪些問題（兩個方面：并發，讀文件）

如果某個任務（Go程）異常阻塞無法釋放，怎么處理

這個問題在于無法釋放的情況怎么處理，如果明確知道哪里出問題的情況下，其實是比較好解決的，找到引起阻塞的代碼修復就好。

如果無法知道是哪里引起的阻塞，這個時候就需要上點小手段了，比如使用Go自帶的pprof性能排查工具排查阻塞的Go程。

可以讓阻塞的那個服務（Go程）自行恢復么（不通過主程）

既然服務已經阻塞，我們就要想辦法讓他能夠主動退出，恰好Go語言的context提供了一個可以定時取消go程的方法WithDeadline，能夠讓Go程在運行時間超出閾值后自動取消協程。

編程題

4個G的文件，里面是不重復的數字，用1個G的內存進行排序

一般這種要處理的數據很大，但是給的內存很小的問題都是采用分治法，寫偽代碼即可

二面

DDD

領取驅動模式設計（DDD）相關討論

參考一面DDD相關問題

數據庫

講講你做過的數據庫優化（表設計 / 索引）

非常常見的問題，類似的文章有很多了，筆者推薦看看這篇文章

mysql索引底層實現是什么

比上個問題還常見

B+樹葉子結點之間連接是單向的嗎？為什么

是雙向的，可以反過來想，如果是單向的，那么逆向的范圍查找就無法支持了。

講講你都用過redis里面哪些數據結構，實現過什么功能

這個根據個人經驗回答即可，緩存是最為常見的了，筆者使用list實現過延遲隊列；使用string實現過分布式鎖等等。

redis客戶端連接池大小應該如何設置比較合理，主要考慮哪些維度

同樣根據個人經驗，可以參考這篇文章

如果系統讀redis緩存失敗了，可能是哪些原因，怎么排查，處理

讀取緩存失敗，可以考慮

客戶端鏈接的時候出現異常

沒有讀取到值

這兩個方面來考慮

redis高可用了解嗎，redis哨兵模式和redis cluster主要有什么區別

這個真給我問住了，哨兵和集群是redis實現高可用的兩種方式，可以參考這篇文章

設計模式

設計模式知道哪些？簡單講講

單例 / 工廠 / 裝飾器 這些最基本的，最好是在多會幾個。再后來聊天的過程中，面試官表示基本問到設計模式的時候，大多數面試者就只會剛提到的這幾種（實際項目中，針對不同場景，我們還采用了策略模式，責任鏈模式，模版模式，建造者模式等等多種設計模式）

觀察者模式知道嗎？

參考上一問，當時筆者是答不出來的

編程題

給你1w個數組成的數組，開10個子任務并發去求和，并返回最終的結果，用Go實現一下

考量的是對Go語言的熟悉程度，可以使用Go提供的waitGroup保證全部Go程執行完后在求和，比較簡單。

三面

閑聊

基本都在聊工作經歷，這里就不展開來講了。

百度

三家中面試體驗最好的一家，全程是通過視頻面的形式完成的

一面

閑聊

簡歷上寫了做過系統優化，說說你做過的優化操作

根據個人經驗回答即可

項目微服務化推進過程中，你都做過些什么

同上

領域驅動設計

領域驅動設計相關討論

參考B站中DDD部分

為什么DDD在各大公司推進比較困難

這個筆者到沒想那么多，回答過程中主要提DDD的規范復雜，團隊中個體對于業務的理解偏差等幾個方面做了回答

GO

說說Go中哪些操作是并發安全的

Go語言中提供了一些線程安全的數據結構和方法，比如channel，SyncMap, once等等

說說你知道的Go語言的編程規范，說5條吧

這個把筆者問到了，這里貼一篇文章供小伙伴們參考：go語言規范-知乎

網絡通信

如果服務間通信失敗了，如果是你會如何處理

排查，確定問題原因，緊急情況下需要做對應的降級，熔斷

數據庫

說說你知道的mysql鎖

什么時候mysql會使用鎖

說說什么是聚簇索引

上面3問都是Mysql八股文
鎖相關：mysql鎖總結
索引相關：mysql索引原理

算法題

二叉樹層次遍歷

百度的算法考察基本來自Leetcode，本題傳送門

二面

閑聊

簡單介紹下你的項目（技術棧，架構）

根據個人經驗回答即可

簡歷上寫了你做過數據庫優化，能簡單介紹下你都做過哪些事情嗎

參考上問數據庫優化相關問題

領域驅動設計

領域驅動設計相關討論

上文提到過了，不再重復

算法題

鏈表排序

同樣是Leetcode原題，本題傳送門

三面

這一面主要考察面試者的技術思維，并沒有標準答案，這里把面試官提到的問題分享給小伙伴們看看

簡單介紹下你自己，注意主要從兩方面介紹：

你自己有哪些核心競爭力方面

你對未來3～5年的規劃

說下你為什么要轉Go

從語言本身，生態，應用場景以及工程性方面去做回答

結合你自己的項目說下你為什么要做微服務化

回答過程中面試官多次強調問題，要回答是什么原因驅使你做微服務化的決策，而不是怎么去做的，并且要結合自己的項目

自己評價一下對于上一個問題的回答是否滿意（請用3個關鍵詞 or 短句描述下答的好的地方和不好的地方）

你期望呆在一個什么樣的團隊

總結

面試復習的過程，也是一個學習的過程，甚至可能是你自我提升最快的過程。雖然很多知識在后續的工作中很少用到，但是扎實的基礎可以幫助你在面對挑戰時更好的去完成。總之，多多學習，肯定是沒有壞處的～

引用一段話做結尾

技術里的二八定律，即用20%的技術可以解決80%的問題
但剩下20%的問題，卻需要用80%的技術去解決

總結

以上是生活随笔為你收集整理的啊哈哈哈，鸡（面）汤（经）来喽～（得物，B站，百度），附答案总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。