整理几份 Waymo 的面经之后，一个很不一样的感受是，这类面试不像典型大厂那样结构清晰、题型固定。相反，它更像是在刻意制造不确定性，通过模糊问题去观察你的建模能力、沟通能力，以及在开放场景下的思考方式。很多人会觉得题目不难但面得很怪，其实这正是 Waymo 的风格。

Coding：看似常规，实际强调建模

Waymo 的 coding 表面上看覆盖了常见题型，比如 run-length encoding、top K、custom sort、二维点集找矩形、稀疏矩阵计算等，但真正的考察重点往往藏在约束和follow-up里。比如 run-length encoding，不只是让你 encode，而是让你基于压缩数据实现随机访问函数 Find(p)，再进一步扩展到区间查询。这其实是在考你如何在压缩表示上构建索引，而不是简单处理数组。再比如 custom sort，要求 linear time，这就意味着你不能用常规排序，而需要利用字符集有限的特性做计数排序。这类题如果只按直觉写，很容易错过关键要求。

还有一些题会明显带有系统背景，比如稀疏矩阵乘法，这种题不仅考实现，还隐含了性能和存储优化的考虑。一个很典型的特点是，题目往往不会一开始就完全定义清楚。你需要主动问清楚输入规模、约束条件、边界情况，然后再决定解法。这一点和传统题目写得很清楚的面试很不一样。

Problem Solving：从模糊描述到清晰模型

Waymo 的题目经常带有语义模糊的特点。比如电面中让你计算地图节点之间的 ETA，本质是最短路径问题，但不会直接说是 graph。你需要自己识别出这是一个加权图问题，然后选择合适的算法，比如 Dijkstra。类似的还有选举问题、点集问题等，很多时候题目描述更像是现实场景，而不是算法题。这种情况下，关键不是写代码，而是你如何把问题抽象成一个数学或计算模型。面试官往往更关注你如何理解问题，而不是你最终用了哪种算法。

System Design：不是设计系统

Waymo 的 system design 非常不一样，甚至可以说反常规。典型题是如何评估自动驾驶模型。这类题没有明确的输入输出，也没有标准架构图，更像是一场开放讨论。你需要从多个角度去拆这个问题，比如如何构建测试数据、如何做仿真、如何设计评估指标、如何覆盖长尾场景。面试官可能会不断抛出问题，比如如何模拟突发状况，如何判断仿真是否真实，或者在计算资源有限的情况下如何扩展测试规模。这一轮很少画图，甚至不像传统 system design 那样讲组件和架构，而更像是在考察你对复杂系统的理解，以及你是否能在不确定条件下建立评估框架。如果用传统 system design 的套路去答，很容易显得不贴题。

Engineering Thinking

有些题明显带有真实系统的影子，比如停车场 + 叫车系统。这类题不仅涉及资源调度，还涉及状态流转，比如车辆从充电位到普通车位，再到被调度接单。这种问题的重点不在于设计一个完美系统，而在于你是否能识别关键状态、关键流程，以及如何定义性能指标。比如你是否会考虑等待时间、资源利用率、车辆调度效率，而不是只停留在怎么存数据。Waymo 很看重这种贴近现实的工程思维。

Behavioral

Behavioral 部分整体比较标准，比如讲项目、讲挑战、讲分歧处理等。但有一个隐含点是，他们会关注你是否具备在不确定环境中工作的能力。比如你如何处理模糊需求，如何面对不确定性，如何在信息不完整的情况下做决策。相比一些公司强调 impact 或 ownership，这里更偏向于你是否适应这种探索型工作。

面试体验：困惑本身就是筛选的一部分

Waymo 的面试体验经常让人困惑，比如题目不明确、system design 不像 system design、面试官互动较少。这种非结构化的体验其实不是偶然，而是筛选的一部分。他们并不只是想看你在熟悉题型下的表现，而是想看你在陌生、模糊甚至有点混乱的环境下，是否还能建立清晰的思路。这也是为什么很多人会觉得题目不难但面得很差。问题不在于不会做，而在于没有适应这种提问方式。