这轮 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 面试问题与近期候选人记录
关于 CSINTERVIEWHELP
无论是 OA 题型解析、OA 辅导、VO 辅助、VO 模拟面试、VO 面试陪练还是系统设计辅助，CSINTERVIEWHELP 都可以结合目标公司的流程陪你把题目拆透、把项目故事讲顺。查看服务
