Google 2027 SWE Intern VO 面经:HashMap + 滑动窗口、Graph BFS,刚面完来复盘
Google 2027 SWE Intern VO 两轮 Technical 复盘:第一轮 HashMap + Sliding Window,从 brute force 优化到 O(n);第二轮 Graph BFS,追问大图、环、返回路径和省空间,附推荐答题流程。
面试概况
最近刚走完 Google 2027 Intern 的 VO,整体感觉没有特别偏的题,但非常看重:
沟通 + Coding 基础 + Follow-up
这次是两轮 Technical,每轮大约 45 分钟。
第一轮 Coding:HashMap + Sliding Window
题目是比较典型的 HashMap + Sliding Window 类型,本身不算特别难。
我的流程是:先给出 brute force → 和面试官确认复杂度 → 再优化到 O(n)。
Follow-up 反而问得比较细:
- 数据量特别大怎么办?
- 如果 input 是 streaming data,怎么处理?
- memory 不够怎么办?
- 有没有容易漏掉的 edge cases?
参考思路:滑动窗口本身就是一次遍历,天然适合流式数据,只需要保存窗口内的状态(HashMap 里的计数),不必存下全部输入。内存不够时,看 HashMap 的 key 空间能不能压缩(比如字符集固定就用定长数组),或者按 key 分片处理。edge cases 常见的有:空输入、窗口大小大于数组长度、全部元素相同、k = 0。
感觉 Google 不只是看最后的代码能不能跑,更看你能不能把思路一步一步讲清楚。
第二轮 Coding:Graph / BFS
先根据题目建立 graph,再用 BFS 找结果。基础版本写完以后,面试官继续修改条件:
- graph 特别大怎么办?
- 出现 cycle 怎么处理?
- 如果需要返回 path,而不是只返回结果呢?
- 如何降低额外空间?
参考思路:
- cycle:BFS 用
visited集合,每个节点只入队一次,环不会导致死循环。- 返回 path:入队时记录每个节点的
parent,到达终点后沿parent往回走、再反转即可。- 大图 / 省空间:图太大时不必预先建好整张邻接表,可以按需生成邻居;已知起点和终点时用双向 BFS,搜索的节点数通常少很多。
from collections import deque
def bfs_path(graph, start, target):
"""无权图最短路径:返回从 start 到 target 的节点列表,不可达返回 []"""
parent = {start: None} # 同时充当 visited
q = deque([start])
while q:
u = q.popleft()
if u == target:
path = []
while u is not None:
path.append(u)
u = parent[u]
return path[::-1]
for v in graph.get(u, []):
if v not in parent:
parent[v] = u
q.append(v)
return []
这一轮我前面有一个 edge case 没考虑到,后来根据面试官的提示及时修掉了。个人感觉 VO 里卡一下问题不大,关键是别沉默,最好一直让面试官知道你在想什么。
推荐的答题流程
clarify → 讲 brute force → 优化 → coding → dry run → edge cases → complexity
我最大的感受是:Google VO 不一定要求你秒出最优解。遇到陌生的变形题时,先冷静判断题型,主动想 edge case 和可能的 follow-up,整个节奏会稳很多。这些平时 mock 时就可以刻意练习。
准备 2027 Summer Intern 的同学,现在开始刷 Google 高频 Medium + 练口述,完全来得及!
看完有收获?欢迎交流。
交流面经、互相 mock、内推信息,都可以找我。
