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故事。