啊哈哈哈,鸡(面)汤(经)来喽~(得物,B站,百度),附答案总结
文章目錄
- 前言
- 得物
- 一面
- 閑聊
- 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站,百度),附答案总结的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: npm发包
- 下一篇: java se 14 虚拟机规范