Uber System Design 面经 2026：Dispatch、ETA、Surge 和 Marketplace

💡 核心要点 (Key Takeaways)

• Uber SWE 的 System Design 轮几乎必出 marketplace 场景：Dispatch 派单、ETA 预测、Surge 动态定价、实时位置，准备时要把乘客和司机两侧供需一起建模，不能只画通用架构图。
• Dispatch 题的区分度在目标函数和匹配窗口：ETA、公平、司机收入、留存如何显式加权，拒单 / 改派 / 超时未接怎么兜底，讲清这两点设计才能从能跑进入能运营。
• ETA 和 Surge 都是系统题而不是字段题：ETA 怎么生成、多久更新、误差怎么传导；Surge 的触发条件、定价粒度、收入与体验取舍、灰度和回滚要能完整讲。
• 公开面经信号按「年份 + 级别 + 岗位」筛选，以 2-3 篇的共识判断轮次结构，只提取题型方向和挂点，单篇个例不要当真。
• 常见挂点：只讲单侧供需、不给目标函数、没有失败降级路径、容量估算缺失、coding 轮强度不足——Uber 每轮独立评分，一轮挂了整体就危险。

这篇适合谁

这篇写给准备 Uber Software Engineer（L5 / L6，对应 3 年以上经验的社招）面试、想重点攻克 System Design 轮的候选人。一句话定位：Uber System Design 面经的核心是 marketplace 场景——Dispatch 派单、ETA 预测、Surge 动态定价，准备的重点是「能不能把双边市场约束讲进架构里」，而不是「画过多少架构图」。文章基于 2026 年公开面经信号和 Uber 公开面试机制整理，各团队、地区、级别的轮次结构会有出入，以实际收到的邀请为准。

站内 Uber 页面分工：Uber SWE 题目合集是全轮次题库索引，实时位置与数据平台专题是实时 / 派单供需 / 容量估算题的答题深挖，本篇是 System Design 专项的全流程面经（流程 + 题型雷达 + 高频题 + 挂点 + 路线 + FAQ），三者配合使用。

面试流程：OA / Phone / VO / HM / Team Match 各轮是什么

Uber SWE 的主线流程是：简历筛选 → OA（部分候选人）→ Recruiter Screen → Phone Screen → Onsite Loop（VO）→ HM / Team Match → 结果与 offer。各轮大致长这样：

• OA（Online Assessment）：NG / Intern 基本必考，社招多数情况可以跳过（简历通过初筛后直接进 Phone）。常见 1-2 道 medium 难度 Python 题，限时作答，偶尔带数据 / 排序 flavor。
• Phone Screen（电面）：约 45 分钟，1 道 coding 题 + 背景与动机沟通。Uber 的电面 coding 不算水，medium 偏 hard 的 LeetCode 出现频率不低，考察无提示下写对、写完整，并能解释复杂度和边界。
• Onsite Loop / VO：通常 4-5 轮、每轮 45-60 分钟，一天面完。常见结构是 1 轮 System Design（社招必考，L5 / L6 有时 2 轮）、1-2 轮 Coding、1 轮 Behavioral + 项目深挖，部分团队再加 1 轮 cross-team。System Design 轮是 Uber SWE 最有辨识度的环节，高频场景就是 Dispatch、ETA、Surge 这类 marketplace 题。
• HM / Team Match：Uber 对 team match 比较重视，VO 通过后常有 hiring manager 沟通或跨组匹配环节，不再考技术，重点是双向确认方向、level、location 和文化契合。

题型雷达：System Design 是主轴，Coding、BQ 次之

按 SWE 岗位把题型按出现频率排个雷达（公开信号口径，不同团队会有出入）：

• System Design（最高频，1 轮，L6 有时 2 轮）：场景几乎都在 Uber 业务线上——Dispatch 派单匹配、ETA 预测、Surge 动态定价、实时位置、订单状态机、地理空间查询。考的是从需求澄清、容量估算、数据模型、组件拆分到降级取舍的全链路，尤其看你能不能把乘客 + 司机双边市场的约束讲进设计。
• Coding（1-2 轮）：medium-hard 的 LeetCode 为主，高频方向：数组 / 哈希、图 / BFS-DFS、堆、区间、贪心，以及 Uber flavor 的题（订单匹配、位置轨迹、时间窗口聚合）。考察代码完整性和边界处理，不是拼竞赛深度。
• BQ + 项目深挖（1 轮或穿插）：行为题 + resume 项目深挖（你的角色、具体数字、取舍、重来一次怎么改）。Uber 的 BQ 强调 ownership、在 ambiguity 下推进和跨团队协作。
• ML Design（中低频）：只有 ML 相关团队（ETA 模型、推荐、定价）会单独考 ML system design，通用 SWE 的 loop 里更多是把 ML 当黑盒组件放进设计题里追问。MLE 的完整准备看 Uber MLE 面经。
• SQL（低频）：偶尔出现在 coding 或数据相关团队的轮次里，窗口函数和多表 join 是基本盘。

高频题目方向：只讲题型和考点，不复刻私密原帖

以下是 2026 年公开面经信号里反复出现的题「类型」，只归纳题型和考点，不复刻任何人的具体原题：

• Dispatch 派单 / 匹配系统：给定区域内实时到达的订单和在线司机，如何匹配。考点：目标函数（总 ETA、司机收入、乘客等待公平性、留存）显式加权；局部贪心 vs 全局 assignment 的取舍；匹配窗口内拒单、改派、超时未接的重匹配与兜底；优化服务挂掉时降级到最近司机。这是 Uber 辨识度最高的题，详细拆解见 实时位置与数据平台专题。
• ETA 预测系统：给乘客和司机展示预计到达时间。考点：特征来源（路网、路况、接驾时间、供给、时段）、更新频率、线上缺失时的 fallback、ETA 误差如何传导进排序、取消率和投诉。要把 ETA 当系统讲，不是当字段讲。
• Surge 动态定价：高峰期供需失衡时如何调价。考点：供需比怎么计算和触发、价格弹性与收入 vs 体验的取舍、调价粒度（区域 × 时段）、公平性和舆情风险、规则配置 / 灰度 / 回滚。只讲「乘个系数」是典型减分回答。
• 实时位置追踪：司机位置上报与查询（附近司机、区域热度、轨迹）。考点：上报频率 vs 电量、位置过期与乱序、geospatial 索引选型、gateway 过载降级。
• 订单状态机 / 支付链路：订单从发单到完成的状态流转、幂等、重试、对账。考点：状态机设计、消息丢失与重复、支付失败路径、审计与合规。
• Coding 高频：medium-hard 为主，常见 Uber flavor：时间窗口内的订单 / 位置聚合、区间合并与冲突检测、图上的最近邻 / 路径、堆 + 优先级的实时 top-N。考点是 45 分钟内写完、测对边界，并能接住 follow-up（数据量放大 100 倍怎么办）。
• BQ / 项目深挖方向：一次你主动发现并推动解决的系统问题、一次跨团队（产品 / 数据 / 其他工程团队）协作推动上线、一次在信息不全时做的技术决策、一次线上事故或失败复盘。每个故事要能接两层追问。

公开面经信号怎么读

一亩三分地等面经社区是 Uber 面试信息最集中的公开来源，但读法决定它对你的价值。几个原则：

按「年份 + 级别 + 岗位」筛选。2026 年 L5 的信号和 2023 年 NG 的信号可能完全不一样（轮次、题目风格、BQ 深度都在变），只看年份最近的 2-3 篇。岗位也要对得上——MLE 面经里 ETA 建模的细节对 SWE 参考价值有限，SWE 的 coding 信号对 MLE 同样没用，混着看会准备错方向。

找共识，不信个例。单篇面经说「只有一轮 design」不能当结论；多篇独立帖子都提到 marketplace 场景（Dispatch / ETA / Surge）是 design 高频、loop 是 4-5 轮结构，这个结构才可信。面经作者有幸存者偏差（过的人爱写，挂的人少写），整体难度感知会偏乐观。

提取「轮次结构 + 题型方向 + 挂点」，忽略剧情。每篇面经真正有用的信息密度就这三样：每轮考什么类型、面试官追问到什么深度、作者觉得挂 / 过在哪。故事细节、情绪、对面试官的评价都不需要带进准备里。

不搬运、不暗示合作。本站所有 Uber 面经内容都只归纳公开信号，不复制任何候选人的逐字面经，也不代表与任何面经社区有合作或转载关系。你读到的公开帖子请以原作者发布的内容为准。

常见挂点：Uber System Design 独有的失分方式

把公开面经里的挂因和模拟面试复盘对照，Uber SWE System Design 特有的失分点集中在这几个：

• 只画通用架构图，没有 marketplace 约束：开口就是 API + 缓存 + 数据库，全程不提乘客和司机是两侧、供需会失衡、价格会变化。面试官会判断你没理解 Uber 的业务形态。先讲双边约束、再讲架构怎么服务约束，顺序反了整轮都难救。
• Dispatch 不给目标函数：直接说「派最近的司机」，被追问「最近一定最优吗、司机长期接不到单怎么办」就断片。目标函数（ETA、公平、收入、留存）显式加权是这道题的第一道分水岭。
• 把 ETA 当字段：只会说「加一个 ETA 字段」，讲不清它怎么生成、多久更新、线上线下分布怎么对齐、误差大了怎么影响取消率。ETA 题答成字段题，等于告诉面试官你只做过离线建模。
• Surge 只讲乘系数：讲不清触发条件、粒度、收入 vs 体验的取舍、灰度和回滚，或者不讨论公平性和舆情风险。定价题考的是经济模型 + 工程落地，不是公式。
• 没有失败和降级路径：位置服务挂了、ETA 模型超时、匹配服务过载，不主动交代降级方案，被追问就断片。按「什么信号、什么条件触发、降级后损失什么」的结构主动讲。
• 容量估算缺失：Uber 面试官很爱用数字检验数量感，不给量级假设、或者面试官换数字不会重算，都会明显减分。
• Coding 轮强度不足：很多人把 90% 时间花在 design 上，结果 coding 轮 medium 题 45 分钟写不完或边界测错。Uber 每轮独立评分，一轮挂了整体就危险。

准备路线：7 天 / 14 天 / 30 天

按你距 VO 的天数选路线。三个版本的共同原则：System Design（Dispatch + ETA + Surge）永远优先，coding 保底强度，BQ 最后两天只练口述，不学新东西。

• 7 天（保下限版）：D1-D2 做 Dispatch 和 ETA 各一遍完整 45 分钟结构（澄清 → 容量估算 → 数据模型 → 组件 → 降级），每遍计时，对照本文「常见挂点」自查；D3 Surge + 实时位置各 1 道，重点补目标函数和触发 / 回滚逻辑；D4-D5 Coding 每天 2 道 medium-hard（区间、图、堆各覆盖），限时 40 分钟；D6 BQ 按 4 个方向写 STAR 故事，英文口述录音回听；D7 完整 mock 1 场（45 分钟 design + 10 分钟 BQ），录音复盘。
• 14 天（标准版）：在 7 天基础上——D8-D9 专项 follow-up：匹配窗口拒单改派、ETA 误差传导、surge 灰度回滚，每个写进 2 分钟内能讲完的答案；D10 把做过的 2 道 design 重做一遍，这次强制主动交代失败路径和容量估算；D11-D12 Coding 再补 3 道（Uber flavor：位置聚合、订单状态、top-N 实时查询）；D13 mock 完整 loop（design + coding + BQ 各一段）；D14 缓冲日，检查设备日程，早睡。
• 30 天（系统版）：在 14 天基础上——D15-D19 Design 扩场景：订单状态机 / 支付、地理空间索引、容量估算专项（分层拆流量、10 的幂校验、敏感性分析），每道补三类 follow-up（规模放大、实时性、失败降级）；D20-D22 实验和指标专项：design 题里怎么定义成功指标、灰度怎么切、回滚条件是什么；D23-D25 项目深挖库：3 个主项目各练三层追问（approach → 细节 → reflection）；D26-D28 连续 3 场完整 mock，重点看 follow-up 接没接住、表达节奏；D29-D30 缓冲日，只复盘断片点。

FAQ：Uber SWE 面试 5 个高频问题

Q1：Uber SWE 面经怎么用才不踩坑？
按「年份 + 级别 + 岗位」筛，只看 2026 年 L5 / L6 SWE 的最近 2-3 篇，提取轮次结构、题型方向、挂点三样东西；单篇个例不当结论，也不要指望从面经里拿到逐字原题。面经解决「考什么、怎么考」，Dispatch / ETA / Surge 具体怎么答看 实时位置与数据平台专题，全轮次题库看 Uber SWE 题目合集。

Q2：Uber SWE 面试几轮？
社招通常是 Phone Screen + Onsite Loop 4-5 轮（coding、System Design、BQ + 项目深挖、team match），每轮 45-60 分钟，一般一天面完；NG / Intern 前面加一场 OA。通过后可能有 HM / Team Match 确认环节。具体以实际收到的邀请为准，不同 team 和地区会有出入。

Q3：Uber SWE 考什么？System Design 难吗？
主轴是 coding（medium-hard）和 marketplace 场景的 System Design。Design 轮高频场景是 Dispatch 派单、ETA 预测、Surge 定价、实时位置，难度不靠算法深度，而靠「双边市场约束 + 失败路径 + 数量感」：能讲清目标函数、供需失衡处理、降级和容量估算，就明显高于平均线。

Q4：社招还有 OA 吗？
大多数社招 SWE 没有 OA，简历通过初筛后直接进 Phone Screen；NG 和 Intern 基本必考。个别 team 可能例外，以邀请为准。

Q5：Uber SWE 和 MLE 的 System Design 差别大吗？
差别明显。SWE 的 design 考「业务约束怎么落成系统」：匹配窗口、状态机、降级、容量；MLE 的 design 考「模型怎么服务业务」：特征、评估、上线、监控，ETA 和定价是两边的共同场景但追问方向不同。准备方向不要混，MLE 完整准备看 Uber MLE 面经。