Google軟件工程師L4面試全復盤：算法+系統設計+行為面完整記錄

背景介紹

先說下我的背景：5年開發經驗，目前在國內某頭部互聯網公司做後端開發，主要技術棧是Go和Python，平時也寫一些基礎設施相關的代碼。2026年3月，一個在Google Mountain View工作的前同事內推了我，說是他們組在招L4 SWE，問我要不要試試。

說實話，我當時猶豫了整整一週。一方面，我在現公司雖然不算特別開心，但收入穩定、團隊也不錯；另一方面，Google一直是我的dream company，這種機會錯過可能就沒了。最終還是在3月底提交了簡歷，職位是Software Engineer L4，地點選了Mountain View。

從投遞到拿到offer，整個過程歷時約8週。4月中旬收到recruiter的初篩電話，4月底完成phone screen，5月中旬安排onsite（現在叫virtual onsite），5月底出結果。整個流程比我預想的要快，但等待結果的那一週真的是度日如年。

我的準備週期大概6週，每天下班後刷2-3道LeetCode，週末做系統設計練習。總刷題量大約120道，以Medium和Hard為主，重點練了圖論、動態規劃和二分搜索。系統設計方面，看了Alex Xu的兩本書和YouTube上的一些影片。行為面準備了一週，整理了大約8個STAR故事。

第1輪 算法面（約45分鐘）

面試官是一位在Google工作了6年的Senior SWE，態度很友好，先花2分鐘自我介紹，然後直接進入題目。

題目一：課程安排合法性檢測（變體）

題目描述：給定n門課程和一組依賴關係 [a, b] 表示課程a依賴課程b，另外還有一組 衝突關係 [c, d] 表示課程c和課程d不能在同一學期修。判斷是否存在合法的課程安排方案。

這道題本質上是拓撲排序的變體。我一開始只考慮了依賴關係的拓撲排序，寫完之後面試官追問衝突關係的處理。我思考了大約3分鐘，提出可以把衝突關係建模為二分圖著色問題——在同一學期的課程不能有衝突，等價於給拓撲排序後的課程分配學期編號，使得衝突課程不在同一學期。

我用了BFS拓撲排序 + 貪心分配學期的方案，時間複雜度O(V+E+C)，其中C是衝突關係數量。面試官對這個方案表示認可，但追問了最小學期數的情況，這裡我卡了一下，最終給出了二分搜索學期數 + 每次check用拓撲排序的解法，面試官點了點頭。

題目二：區間合併計數

題目描述：給定一組區間，求合併後的區間數量，並輸出每個合併後區間的起始和結束位置。進階：如果區間數量非常大（10億級別），如何優化？

第一問是經典區間合併，我很快寫完了。進階問題我提出了外部排序 + 流式合併的方案，面試官追問了具體實現細節，包括如何用有限內存處理大規模數據。我畫了一個示意圖，說明可以用多路歸併 + 最小堆的方式，面試官似乎比較滿意。

這輪感受：整體節奏比較緊湊，第一題變體確實需要思考，好在拓撲排序是基本功。第二題進階部分讓我有點緊張，但外部排序的思路還是想出來了。面試官全程沒有太多表情，但最後說了句"good job"，讓我稍微安心了一些。

第2輪 算法面（約45分鐘）

這輪面試官是一位L5 SWE，風格和第一輪完全不同——非常安靜，幾乎不說話，全程就看我寫代碼。

題目一：字符串解碼

題目描述：給定一個編碼後的字符串，規則是 k[encoded_string] 表示方括號內的字符串重複k次。可能有嵌套。返回解碼後的字符串。例如 "3[a2[c]]" 解碼為 "accaccacc"。

這道題是LeetCode 394的原題，我用棧的方式很快寫完了，大約10分鐘。面試官看了一眼，讓我分析時間和空間複雜度，我回答都是O(n)。然後他直接說"next question"。

題目二：最短路徑變體——帶限制條件的最少飛行中轉

題目描述：給定一組航班信息 (from, to, price)，求從起點到終點、總價格不超過budget的最少中轉次數路徑。如果有多條同樣中轉次數的路徑，返回總價格最低的。n個城市，m條航班，n ≤ 100, m ≤ 10000。

這道題我想了大約5分鐘，一開始想用Dijkstra，但發現需要同時優化兩個維度（中轉次數和價格），普通的Dijkstra不太行。後來我提出用BFS按層遍歷（每層代表一次中轉），同時維護到每個城市的最低價格，一旦總價格超過budget就剪枝。

寫代碼的時候出了一個小bug——我在BFS的visited判斷上寫錯了，應該用 city + currentPrice 作為狀態，而不是只看city。面試官指出了這個問題，我立刻修正了。時間複雜度O(m * budget)，面試官沒有提出異議。

這輪感受：第二題確實讓我緊張了，BFS雙維度優化的思路不是第一時間想到的，而且visited的bug讓我覺得自己表現不夠好。面試官全程面無表情，完全猜不到他的想法。出來之後我甚至覺得這輪可能要掛。

第3輪 系統設計（約45分鐘）

這輪是我最緊張的一輪，因為系統設計一直是我的弱項。面試官是一位Staff Engineer，非常資深，提問很有引導性。

題目：設計Google Drive

面試官說："Design a cloud file storage system like Google Drive that supports file upload/download, sharing, and real-time collaboration."

我按照慣用框架開始拆解：

1. 需求澄清：我主動問了幾個問題——用戶量級（面試官說10億+）、單文件大小限制（面試官說5TB）、是否需要版本控制（需要）、是否需要實時協作編輯（需要，類似Google Docs）。面試官對我的提問表示肯定。

2. 容量估算：10億用戶，假設平均每個用戶存儲50GB數據，總存儲量約50PB。假設日活躍用戶1億，平均每天上傳/下載10個文件，QPS約10萬，峰值QPS約50萬。

3. 高層架構：我畫了Client → API Gateway → Metadata Service + File Storage Service + Notification Service的架構。Metadata Service用關聯式資料庫（Spanner），File Storage用對象存儲，Notification用長輪詢或WebSocket。

4. 文件上傳：我提出了分塊上傳的方案，每個chunk 4MB，客戶端並行上傳多個chunk，服務端合併。面試官追問了斷點續傳的實現，我用了記錄已上傳chunk list的方式。

5. 文件共享：我設計了基於ACL的權限模型，每個文件/文件夾有owner和ACL list。面試官追問了共享鏈接的實現——我提出用短鏈 + token的方式，token有過期時間，可以設置密碼保護。

6. 實時協作：這是最難的部分。我提出了基於OT（Operational Transformation）的方案，但面試官讓我詳細解釋OT的原理。說實話，我對OT的理解停留在概念層面，具體實現細節講得比較模糊。面試官追問了CRDT和OT的區別，我大概說了一下CRDT是最終一致性、OT是強一致性，但細節上確實不夠深入。面試官沒有繼續追問，但表情上看得出不太滿意。

7. 數據一致性：面試官問了跨區域複製的方案。我提出了異步複製 + 讀自己寫一致性（read-your-writes consistency）的方案，用版本號來解決衝突。

這輪感受：前半部分發揮不錯，需求澄清和容量估算做得比較到位，分塊上傳和ACL共享也講得比較清楚。但實時協作部分確實暴露了我的短板，OT/CRDT的實現細節沒有準備好。如果重新來過，我一定會把Google Docs的協作原理研究透徹。

第4輪 算法面（約45分鐘）

這輪面試官是一位L4 SWE，比我還晚入職半年，但技術能力很強。風格很輕鬆，像是在和同事討論問題。

題目一：二元樹中的最大路徑和

題目描述：給定一棵二元樹，找到任意兩個節點之間的最大路徑和（路徑中節點值之和最大的路徑）。這是LeetCode 124，經典Hard題。

我之前刷過這道題，所以很快給出了遞迴 + 全域變數的解法。關鍵點是：對於每個節點，計算以該節點為"拐點"的最大路徑和，同時返回以該節點為起點的單側最大貢獻值給父節點。時間複雜度O(n)，空間複雜度O(h)。面試官讓我跑了兩個test case，確認正確後進入下一題。

題目二：設計一個數據結構支持動態中位數查詢

題目描述：實現一個數據結構，支持三種操作：addNum(num) 添加一個數字，findMedian() 返回當前所有數字的中位數，removeMedian() 刪除中位數。要求addNum和findMedian時間複雜度O(log n)，removeMedian也是O(log n)。

addNum + findMedian是經典的雙堆問題，我很快寫完了。但removeMedian讓我卡了——刪除堆頂元素後，需要重新平衡兩個堆的大小。我一開始想用lazy deletion，但面試官說"如果刪除操作很頻繁，lazy deletion會導致堆越來越大"。我思考了一會兒，提出可以用兩個堆 + 一個輔助的平衡操作：刪除中位數後，從較大的堆中移動一個元素到較小的堆。具體實現上，我用了一個HashMap來記錄被刪除的元素，在堆頂元素被標記刪除時才真正彈出。

面試官對這個方案追問了幾個邊界情況，比如連續刪除多次中位數會怎樣。我承認這個方案在極端情況下可能退化，但面試官說"對於面試來說已經夠了"。

這輪感受：整體發揮不錯，第一題是刷過的原題，第二題雖然removeMedian部分有些波折，但最終給出了可行的方案。面試官的反饋也比較積極，最後還聊了幾句他做的項目。

第5輪 行為面/Googleyness（約45分鐘）

Google的行為面和其他公司不太一樣，他們叫"Googleyness & Leadership"，重點考察你是否符合Google的文化價值觀。面試官是一位People Partner（HRBP），但技術背景出身。

問題1：講一個你和同事產生分歧的經歷，你是如何解決的？

我講了一次和前端同事關於API設計格式的爭論。我主張RESTful，他主張GraphQL。我沒有直接否定他的方案，而是組織了一次技術討論會，讓雙方各準備一個5分鐘的presentation，用實際數據對比兩種方案在我們場景下的優劣。最終我們選擇了RESTful，但採納了他關於靈活查詢的建議，在部分接口使用了字段過濾參數。

面試官追問："如果對方堅持不讓步呢？"我回答說我會上升到tech lead，讓更senior的人來做決策，但在此之前我會確保雙方的觀點都被充分理解。

問題2：講一個你在工作中犯過的錯誤，你是如何處理的？

我講了一次線上事故——我負責的一個服務在發佈後出現了內存洩漏，導致服務OOM重啟。我第一時間回滾了版本，然後花了兩天時間排查根因，發現是我引入的一個緩存沒有設置過期時間。修復後我做了三件事：一是在code review中增加了內存使用的檢查項，二是推動了團隊引入內存profiling的CI檢查，三是寫了一篇post-mortem文檔分享給其他團隊。

面試官追問："你覺得為什麼code review沒有發現這個問題？"我坦誠地說因為緩存是在一個工具類裡初始化的，和業務代碼不在同一個review scope裡，這是一個流程上的漏洞。

問題3：講一個你主動承擔超出職責範圍的工作的經歷

我講了團隊裡沒有人願意做的on-call排班系統的開發。原來的排班是手動Excel，經常出錯。我主動提出用兩週時間開發一個自動排班工具，考慮了每個人的時區、偏好和輪換公平性。上線後，排班出錯率降到了0，團隊滿意度也提高了。

面試官追問："這個工具後來有其他人維護嗎？"我說我寫了詳細的文檔和單元測試，後來交接給了一個新入職的同事，他接手後還加了幾個新功能。

問題4：你如何幫助團隊中表現較弱的成員？

我講了一個mentor的經歷。我帶過一個應屆生，他代碼能力不錯但設計能力較弱。我每週和他做一次1-on-1的code review，不是簡單指出問題，而是引導他自己發現問題。比如我會問"你覺得這段代碼如果需求變了，改起來容易嗎？"而不是直接說"你應該用策略模式"。半年後他獨立負責了一個模組的設計，做得很好。

問題5：為什麼選擇Google？

我結合了自己的職業規劃和對Google產品的熱愛來回答。重點提了三點：一是Google的技術深度和規模，很多問題只有Google這個量級才會遇到；二是Google對工程師文化的重視，20% time、內部技術分享等；三是Google在AI領域的投入，我希望能參與到影響數十億人的產品中。

這輪感受：行為面比我想像的輕鬆，可能是因為我提前準備了8個STAR故事，覆蓋了衝突解決、犯錯、主動承擔、幫助他人等常見主題。面試官的追問都比較自然，沒有故意刁難的感覺。我覺得關鍵是要講真實的故事，不要編造，因為追問會讓你原形畢露。

面試真題彙總

第1輪 算法面

1. 課程安排合法性檢測（拓撲排序變體 + 二分圖著色）| 考察點：圖論、拓撲排序、二分圖 | 難度：Hard

2. 區間合併計數 + 大規模數據優化 | 考察點：排序、貪心、外部排序 | 難度：Medium → Hard（進階）

第2輪 算法面

3. 字符串解碼（棧） | 考察點：棧、字符串處理 | 難度：Medium

4. 帶限制條件的最少飛行中轉（BFS + 剪枝） | 考察點：BFS、狀態設計、多維度優化 | 難度：Hard

第3輪 系統設計

5. 設計Google Drive | 考察點：分佈式存儲、分塊上傳、ACL權限、實時協作 | 難度：Hard

第4輪 算法面

6. 二元樹中的最大路徑和（遞迴 + 全域變數） | 考察點：樹形DP、遞迴 | 難度：Hard

7. 動態中位數數據結構（雙堆 + 刪除操作） | 考察點：堆、數據結構設計 | 難度：Hard

第5輪 行為面/Googleyness

8. 衝突解決 | 9. 犯錯處理 | 10. 超出職責的主動性 | 11. 幫助弱成員 | 12. 為什麼選擇Google

心得體會與建議

1. 算法要練到"肌肉記憶"的程度。Google的算法面試節奏很快，45分鐘2道題，幾乎沒有太多思考時間。拓撲排序、BFS、雙堆這些必須做到看到題目就能動手寫。我第2輪的BFS變體就因為狀態設計不夠熟練而浪費了時間。建議刷題不要只追求數量，每個題型至少做3-5道，確保真正理解。

2. 系統設計要深入，不要只停留在框架層面。我第3輪的教訓就是實時協作部分只講了概念，沒有深入到OT/CRDT的實現細節。Google面試官會追問到你答不上來為止，所以每個設計決策都要能講清楚"為什麼"和"怎麼做"。建議針對Google常考的系統設計題（Google Drive、YouTube、Search等），每個都做深度研究。

3. 行為面要準備真實故事，不要背模板。Googleyness面試官非常擅長追問，如果你的故事是編的或者過度包裝的，追問兩三層就會露餡。我的建議是準備6-8個真實的STAR故事，覆蓋不同主題，然後針對每個故事想好可能被追問的方向。

4. 溝通和心態比完美解法更重要。我第2輪的BFS變體其實沒有給出最優解，但我和面試官保持了良好的溝通，邊想邊說，讓他看到我的思考過程。第3輪的實時協作雖然答得不好，但我也坦誠地說"我對OT的實現細節不夠深入"，然後盡力給出了我能想到的方案。最終我還是拿到了offer，說明Google更看重你的思考方式和溝通能力，而不是每個問題都完美解答。

最後，5月28日收到recruiter的電話，說HC（Hiring Committee）通過了，compensation package還在審批中。6月初拿到正式offer，L4級別，總包比我現在漲了約40%。整個過程中最煎熬的是等HC結果的那一週，但最終一切值得。祝大家都能拿到心儀的offer！

FAQ

Q1：Google L4面試一般幾輪？
通常onsite是4-5輪，其中3-4輪算法/編碼面，1輪系統設計，1輪Googleyness行為面。具體安排可能因職位和團隊而異。我的情況是4輪技術面 + 1輪行為面，共5輪。

Q2：Google面試可以用Python嗎？
可以。Google支持多種編程語言，包括Python、Java、C++、Go、JavaScript等。我選了Python寫算法題，因為Python寫起來更快，可以節省時間。但要注意Python的一些陷阱，比如遞迴深度限制、GIL等，面試官可能會追問。

Q3：Google面試算法題難度大概是什麼水平？
以LeetCode為參考，大部分題目在Medium到Hard之間。Google不太會出純Hard的題目，但經常在Medium題上加變體或追問，讓難度升級到Hard。建議以LeetCode Medium為主，重點練圖論、DP、二分搜索、堆這幾個高頻類別。

Q4：系統設計面試需要畫圖嗎？
需要。Google的virtual onsite一般用Google Docs或Codelab，可以在上面畫簡單的架構圖。建議提前熟悉這些工具的使用。畫圖能讓面試官更快理解你的設計，也能展示你的溝通能力。

Q5：Googleyness面試到底考什麼？
Googleyness主要考察四個維度：Respect（尊重他人）、Judgment（判斷力）、Inclusion（包容性）、Leadership（領導力）。具體來說，就是你是否能在團隊中有效合作、是否能在模糊情況下做出好的決策、是否尊重不同的觀點、是否能主動推動事情前進。準備時圍繞這四個維度組織你的STAR故事。