Uber SWE VO 面试复盘｜两轮 Coding 后，派单系统和项目追问如何准备

这轮 Uber SWE VO 的安排很紧：两轮 Coding 接着系统设计和 HM 交流。写代码时别只报出算法名，面试官会一路追到接口边界、测试用例和规模变化。第一面先做网格题，第二面把实现拉到一个小服务里。后半场的派单设计不需要画得花哨，但数据流、位置更新和失败重试必须说清楚。

第一面：配送区域连通性

练习题： 给定城市网格，格子里标记餐厅是否营业。实现 openRestaurant(x, y) 、 closeRestaurant(x, y) 和 countDeliveryZones() ；每次变更后返回连通营业区域数。追问是频繁开关同一格时，如何避免每次都扫完整张图。 拆解思路： 单次统计可以从每个营业格出发做 BFS，访问过的格子不再入队。写完基础版后，先说明删点会让并查集难以直接维护；若更新频繁，按批次重建连通分量，或维护脏区域并在查询时局部重算。接口返回值要区分坐标非法、重复开店和状态真的改变，测试覆盖单格、桥接两块区域、关闭唯一通路这三类情况。

第二面：司机接单窗口

练习题： 实现一个司机候选池。输入司机位置、空闲状态和最近心跳，按距离与新鲜度返回可接单的前 K 名；状态更新会乱序到达，旧心跳不能把新状态覆盖掉。 拆解思路： 为每个司机保存 version 或时间戳，只有更大的版本才能写入。候选查询先按城市网格或 geohash 找邻近桶，再用小顶堆保留 K 个最佳候选；距离相同按司机 ID 排序，结果才稳定。追问到断线时，心跳超过阈值就把司机从可派单集合移除，并把这条转换写成可重复执行的状态机，重放消息不会重复扣减容量。

第三面：派单服务如何拆

练习题： 设计一个附近司机派单服务。订单创建后要在几秒内找到候选司机，司机接单、拒单和超时会同时发生；同一订单不能被两个人确认。 拆解思路： 订单服务写入待派单状态后发布事件，匹配服务从位置索引取候选司机，给前几名发带租约的 offer。司机确认时用订单版本做条件写入，成功者把订单改成已分配，其余 offer 自动过期。位置流单独走流处理，热数据放在分区内存或缓存，订单事实写入持久库。面试里要主动补充监控：匹配耗时、offer 超时率、重复确认冲突和某个区域的候选池深度；这些指标能直接定位高峰期的退化。

第四面：项目追问和 HM

练习题： 讲一次你把一个不稳定功能上线的经历。HM 追问：当业务要求按期发布、但压测里仍有偶发超时时，你如何决定范围和节奏？ 拆解思路： 回答先交代用户影响和故障边界，再讲你留下了哪些保护：灰度开关、容量阈值、回滚条件和负责人。不要把“延期”说成唯一正确答案；若核心路径稳定、边缘功能可隔离，就带着可观察指标分批发布。结尾落到自己的动作：谁做压测、谁盯告警、什么时候复盘，HM 想听的是你如何让决定真的可执行。

准备时我会这样排

用 45 分钟完成一次网格 BFS 和一次 top K 查询，最后 10 分钟只写边界测试。系统设计练习按“订单状态、候选索引、确认条件写入、失败恢复”顺序讲，不要一开始堆组件名。项目故事准备一条有数据的版本：影响范围、当时约束、你的选择和上线后结果。

FAQ

Uber VO 的 Coding 题要写到什么程度？

主逻辑通过样例后，主动给出复杂度和至少两类边界测试。若追问接口化，把状态、异常返回和幂等处理写出来，比口头补一句更有说服力。

系统设计里一定要画完整架构图吗？

先画订单进入、候选司机筛选、确认写入三条主链路。等面试官问到规模、延迟或故障，再补缓存、队列和分区方式，节奏更自然。

参考来源

Uber SWE 2026 面试流程与 CodeSignal、现场轮次记录 Uber Software Engineer 面试经历与 VO 轮次 Uber Software Engineer 面试问题与近期候选人记录

联系 VOPathway

如果你希望把这套方法用于自己的 OA 或 VO 准备，可以把目标岗位、当前阶段、面试时间和主要难点发给 VOPathway，我们会据此安排针对性的练习与复盘。

微信：Coding0201
邮箱：[email protected]
Telegram：@OAVOProxy
WhatsApp：+86 178 6396 8105

可提供 OA辅助、OA辅导、VO辅助与 VO辅导。文章用于训练参考，不代表相关公司的官方流程；实际安排请以候选人收到的通知为准。