面经 | SDE | 🔥🔥 | Google
2026(7-9月) Software Engineer 全职 @ Google - Virtual Onsite | 🙂 Positive | Medium | Pending
整体感觉 Google 的题不一定特别难，但是很喜欢在你写完以后继续改条件。两轮面试官都挺 friendly，基本会听你把思路讲完，不太会故意打断。
Round 1 — BQ + Coding
前面大概 10 分钟 BQ。
问了：
Why Google？
还有一个：
项目最大挑战、怎么解决。
我讲的是之前一个 service 在流量起来以后 latency 变差的问题。
本来以为讲完就结束了，结果 interviewer 顺着项目问了不少：
为什么当时选 Redis，不用 local cache？
cache 的过期策略怎么定？
如果 cache 和 DB 数据不一致怎么办？
最后还问：
如果现在重来一次，你会怎么改？
这里我答得一般。
因为前面基本都在讲“当时为什么这么做”，突然让我自己挑原方案的问题，我想了一下才说现在可能会把 cache invalidation 和 monitoring 做得更早一点。
后面开始 coding。
题目是一个 restaurant waiting list。
大概有三个 API：
join(user, table_size)
delete(user)
find_first_match(table_size)
要求是先到先得。
比如一个 4 人桌空出来，要找到当前最早加入，而且能坐这个桌子的 user。
我一开始直接说 queue，但是很快发现 delete 不是很好做。
后面用了 linked list + hashmap。
delete(user) 可以通过 hashmap 直接找到 node 删除。
比较麻烦的是 find_first_match。
因为你还是要保持全局 FCFS，所以不能单纯给每个 table size 一个独立 queue，然后随便取。
我第一版最坏还是 O(n) scan。
写完以后 interviewer 就问：
如果 waiting list 特别长，有没有办法让 lookup 更快？
这里我没有完全写出来。
大概讨论了一下按 table size 维护辅助 index，但是又要保证全局 arrival order，所以 bookkeeping 会复杂很多。
最后时间差不多了，就口头讲了一下。
这一轮我感觉 coding 本身还行，反而前面的 project follow-up 比我想象中细。
Round 2 — BQ + Coding
第二轮上来又问了几个 BQ。
印象比较深的是：
How do you win over a team member who initially disagrees with you?
我讲了之前一个技术方案和 teammate 意见不一致的例子。
interviewer 后面追问：
你怎么确认最后是你的方案更好？
如果 data 最后证明对方是对的怎么办？
还有一个：
When multiple priorities compete, how do you decide what to focus on first?
这题比较正常，我就讲 impact / urgency / dependency。
BQ 大概十几分钟，后面开始 coding。
先给了一个很简单的 warm-up：
两个时间区间怎么判断 overlap。
这个很快写完。
然后变成 Meeting Rooms II，给一堆 meeting interval，求最少需要多少个 room。
我用 min heap。
先按 start time sort，heap 里面放当前 room 的 end time。
如果下一个 meeting 的 start >= heap top，就可以复用那个 room。
这题我之前做过，所以写得比较快。
然后 interviewer 加 follow-up：
现在不仅要告诉我最少几个 room，还要告诉我每个 meeting 最后被分配到了哪个 room。
这里其实原来的 heap 稍微改一下就行。
heap 里不只放 end time，而是：
(end_time, room_id)
room 空出来以后把 id 复用。
我刚开始新开 room id 的逻辑写错了一点，dry run 的时候自己发现了，改掉以后 testcase 都过了。
最后还问了一句 complexity。
整个 coding 大概 25 分钟就结束了。
后面还剩一点时间，就随便聊了下 team 和 day-to-day。