Waymo SWE Offer 拿到了，整个过程比我想象的累——不是题难，是每道题后面都跟着三四个”那如果……”，出来之后脑子还在转。Waymo 和大多数互联网公司考法不一样，他们不满足于你给出一个正确答案，他们想看你的推理在压力下能不能撑住。 网上对Waymo 分析里有一句话说得很准：“Repeated follow-up questions are a depth check, not a sign that your first answer was wrong.” 当时不理解，面完之后完全认同。
Waymo SWE 时间线
9.9 收到 LinkedIn recruiter reach out
9.12 HR quick call，了解组和岗位方向
9.17 找 refer 并正式投递
9.19 填 VO Survey
10.9 两轮 back to back VO
10.21 Offer
六周，比预期快一点。TechPrep 的 Waymo 指南说”4 到 8 周”，这次算短的。
Waymo swe interview 注意事项
各 team 差异很大。 vervecopilot 的分析里专门强调了这一点：mapping team 和 fleet operations team 的候选人，面试体验可能完全不同。我面的是 infrastructure 方向，所以没碰到 perception 或 planning 的 domain 题。如果你面的是 robotics 或 Planning team，domain knowledge 的权重会高很多，dataford.io 的指南里写了”For onboard roles, C++ memory management and concurrency is effectively a requirement”。
Waymo 的 safety mindset 不是让你背公司价值观。 TechPrep 指南里说 behavioral 轮的核心是”safety mindset and collaboration under pressure”，这不是说让你去背”Waymo 很注重安全”，是看你在技术讨论里有没有自然地把 failure mode 想进去。设计一个传感器 pipeline，你主动提”如果传感器在隧道里失联系统怎么降级”，远比被追问之后才说有用。
正确答案只是进入这道题的门票。 两轮里每道题的第一个答案都能过，真正把人分开的是后面三四层的追问。这个备考的时候很难练到——大多数人刷题时写对了就跳过了，但 Waymo 的面试在你写对之后才开始。
Round 1：BQ + 项目深挖 + Coding
面试官是位白人小哥，态度很友善，节奏挺快。BQ 大概 20 分钟，然后项目深挖，最后 Coding。
BQ：DDL 压力下怎么决策
问题围绕简历展开，问的是在 deadline 极度紧张的情况下怎么推进项目。
我答完，他追：你当时有没有考虑过放弃某个功能？放弃的标准是什么？这个标准是你自己定的还是和 stakeholder 对齐过的？
三层追问，每层都让你说出更具体的判断依据。Waymo 的 BQ 不要”最终我们赶上了”的结局，要”当时你怎么判断的”的过程。
项目深挖：实时监控平台重构
聊了一个流处理相关的重构项目。他的追问方向：
为什么不用定时任务——我说定时任务有固定延迟，实时监控需要事件驱动，定时轮询在数据量大时延迟不可控。
数据延迟怎么处理——时间戳对齐和水位线机制，Watermark 在流处理里是控制延迟数据的标准手段。
版本灰度怎么做——配置中心加流量染色，新版本只对特定标记的流量生效，出问题立即切回。
每个追问都是”那如果……”。这不是否定，是在看你的推理有没有死角。
Coding：最少会议室数量 + 三个 follow-up
给一组会议的开始和结束时间，求最少需要多少间会议室。
扫描线：start 记 +1，end 记 -1，事件按时间点排序后扫一遍，维护当前占用数，取全程最大值。
def min_meeting_rooms(intervals):
events = []
for start, end in intervals:
events.append((start, 1))
events.append((end, -1))
events.sort(key=lambda x: (x[0], x[1]))
cur = max_rooms = 0
for _, delta in events:
cur += delta
max_rooms = max(max_rooms, cur)
return max_roomsFollow-up 一：同一时刻有会议结束也有会议开始，怎么排序？
先 clarify 区间类型——[start, end) 还是 [start, end]。左闭右开的话，结束时间等于另一个会议的开始时间可以复用同一间，排序时让 -1 在 +1 前面；两端闭合则反过来。这个 clarify 是关键，不先问直接写很容易踩坑。
Follow-up 二：不只返回数量，还要输出哪间会议室分配给哪个会议。
最小堆维护当前占用会议室的结束时间。新会议来了，堆顶结束时间 ≤ 新会议开始时间就复用（更新堆顶），否则新开一间，同时维护一个映射记录分配关系。
Follow-up 三（这是被追问最麻的一个）：如果字符串非常长（10 亿级），内存放不下怎么办？
他在这里切换了话题，把 Round 1 开始的那道题（无重复字符最长子串）拿出来继续追。我答了流式处理——把数据分块，维护窗口状态，块间传递边界状态。他追：块边界横跨了一个正在处理的”最长子串”怎么办——我卡了一下，才想清楚要把上一块末尾的状态带进下一块的初始状态，不能简单截断。这个细节是真的被追出来的，不是我自己想到的。
Round 2：Coding + 轻系统设计
这轮节奏更紧，两道题。
Coding：网格最短路径 + 三个 follow-up
给一个网格地图，有些格子是障碍物，求起点到终点的最短步数。
标准 BFS：
from collections import deque
def shortest_path(grid, start, end):
m, n = len(grid), len(grid[0])
queue = deque([(start[0], start[1], 0)])
visited = [[False]*n for _ in range(m)]
visited[start[0]][start[1]] = True
dirs = [(0,1),(0,-1),(1,0),(-1,0)]
while queue:
x, y, steps = queue.popleft()
if (x, y) == tuple(end):
return steps
for dx, dy in dirs:
nx, ny = x+dx, y+dy
if 0<=nx<m and 0<=ny<n and not visited[nx][ny] and grid[nx][ny]!=1:
visited[nx][ny] = True
queue.append((nx, ny, steps+1))
return -1TechPrep 的指南里提到”Shortest Path in Binary Matrix 是 Waymo Coding 轮的代表性题目”，因为直接对应路径规划场景。
Follow-up 一：可以消除一个障碍物，怎么改？
状态扩展成 (x, y, k)，k 表示还剩几次消除机会。(x, y, 0) 和 (x, y, 1) 是两个不同状态，分别记录是否访问过。
Follow-up 二：地图动态更新（格子从通行变成障碍物），怎么处理？
这是这轮最有 Waymo 特色的追问——直接对应自动驾驶场景下道路状况实时变化。我说了两个方向：变化频率低时重新跑 BFS；频率高时维护增量缓存，只重算以变化节点为中心的受影响区域。他追问了局部 BFS 的边界怎么定，我说以变化节点为起点，影响范围以”原最短路径是否经过这个节点”来划定。
Follow-up 三：如果网格非常大，内存装不下 visited 数组怎么处理？
类似 Round 1 的流式问题，考的是空间受限下怎么权衡。我说了分块处理加上哈希集替代二维数组的思路，在大网格上 sparse 的 visited 集合比全量数组省很多内存。
系统设计：网约车派单系统
司机持续上传位置，乘客发起叫车请求，设计整个派单系统。
这道题很 Waymo——他们本身就在做这个，追问方向全是真实工程问题。
我的方案：入口层（负载均衡 + 鉴权）→ Kafka（按 region 分区，保证区域有序）→ 流处理层（匹配、计费、状态同步）→ 存储层（实时位置进 GeoDB，订单数据落关系库）。
dataford.io 指南里写到 Waymo 系统设计看重”ability to handle trade-offs between latency, consistency, and availability”，这道追问完全印证了这一点：
订单取消怎么处理——状态机控制，幂等 token 避免并发下重复派单，取消后司机状态推回 Kafka。
高并发热点区域——分片集群，同区域打同一分片，高峰期加限流和请求队列。
我提到用卡尔曼滤波纠偏 GPS 噪声，他追问”速度突变时效果怎样”——我说急加速/急刹车场景下单靠 GPS 的卡尔曼会有短暂失真，需要结合速度传感器做多源融合。他说”这个方向是对的”，明显比之前几个问题更投入，感觉这里加了分。
这家面试真正在考什么
Correctness 比速度重要。 “a fast but buggy solution is often a failing grade.” 他们造安全关键系统，宁愿你慢一点把 edge case 都想到，也不要一个快但会在极端场景出错的方案。
Follow-up 是真正的筛人环节。 “follow-up is where most candidates get exposed”，两轮加起来 10+ 个 follow-up，每一个都在往更极端的约束里推。提前练”那如果这个条件变了呢”比多刷一道 LC 有用得多。
Safety mindset 要在技术方案里自然体现。设计系统时要”naturally surface failure modes”。不是说说”我很在意安全”，是在讲方案的时候主动说”如果传感器失联，系统会……”，不等面试官追问。
BQ 追问是真的会追三四层。 说完故事之后他们会继续问”你当时的判断依据是什么””如果重来你会改什么”——不是走过场，是真的在看你推理的深度。
高频题型总结
Coding 高频
图论和 BFS——最短路径、状态扩展 BFS（带约束搜索）、A* 变体。TechPrep 指南明确列出”BFS、Dijkstra、A* variations on grid-based environments”是核心，直接对应路径规划场景。
扫描线——会议室分配、区间合并、最大并发数，这次 Round 1 就碰到了。
滑动窗口——无重复子串这类，Waymo 会在原题上套”流式数据内存受限”的追问。
计算几何——凸包、边界框、多边形相交。dataford.io 指南说”Computational Geometry appears frequently”，是 Waymo 区别于其他大厂最明显的考点，planning/perception team 必准备。
System Design 高频
TechPrep 指南说”Waymo’s version has a distinct flavor — prompts tend to connect to fleet infrastructure rather than generic e-commerce scenarios”。高频题包括：PB 级车辆日志摄入和索引 pipeline；实时 disengagement 指标评估服务；仿真引擎（Multiverse）架构；网约车派单系统。
BQ 高频
“Tell me about a high-risk decision involving safety-critical systems”——TechPrep 指南原文引用的真实问题。
“How do you handle technical disagreements when the outcome affects physical safety”——同上。
对自己过去架构决策的反思，不需要被提示就能说”如果重来我会……”。
备考建议
图论和 BFS 优先级最高。 状态扩展 BFS（(x, y, k) 这类三维状态）是 Waymo 特有的变形，单纯的模板不够用，要专门练带状态的版本。
Geometry 看 team。 如果面 perception 或 planning 方向，凸包、多边形相交比图论还高频。dataford.io 指南专门列了这一块，如果是 infrastructure 方向可以优先级放低。
Follow-up 专门练。 每道题写完之后追问自己”如果是流式数据怎么办””如果地图动态变化怎么办””如果内存受限怎么办”，这个习惯比多刷题有用。
C++ 看岗位。 Onboard 和 robotics 相关的岗位，C++ memory management（smart pointers、move semantics）和 concurrency 是真实考点；infrastructure 和 platform 方向 Python 通常够用。
有在准备 Waymo 或其他自动驾驶公司 SWE 岗的同学，可以来聊聊。InterviewShow 做过 Waymo、Cruise 这些公司的面试，状态扩展 BFS、实时派单系统设计、safety mindset 的 BQ 打磨都有专门覆盖，有需要的来聊。·