Uber 的 SDE 面试通常会考算法编程、系统设计和 BQ，具体流程会因岗位、级别和招聘类型有所不同。备考时，既要搞清楚 OA、Technical Interview 和 VO 各轮的考法，也要熟悉常见的 Coding 题型和系统设计思路，再准备好能用真实项目经历回答的 BQ。
本文整理了 Uber 的面试流程、OA 真题和 VO 内容,并以”实时动态加价系统”为例,拆解系统设计中的数据处理、价格计算、故障恢复和区域规则,最后分析”技术决策分歧”这道 BQ 的答题思路。
1. Uber Interview Process
| 面试阶段 | 主要内容 | 考查重点 |
|---|---|---|
| Application | 提交简历，等待招聘团队筛选 | 技术背景、项目经历、岗位匹配度 |
| Online Assessment（OA） | 在线完成编程题，部分岗位会安排 | Data Structures、Algorithms、代码实现和边界条件 |
| Technical Interview | 与工程师进行实时技术面试，部分候选人会有此环节 | Coding、复杂度分析、代码质量和 Follow-up |
| Virtual Onsite（VO） | 多轮技术及综合面试 | Coding、System Design / LLD、Behavioral Interview（BQ） |
| Hiring Decision | 招聘团队综合各轮面试反馈 | 技术能力、岗位匹配度及团队协作能力 |
2. Uber OA
Uber OA 主要考查候选人的算法基础、问题分析能力和代码实现能力。题目可能涉及前缀和、二分查找、数组处理等常见算法，也可能将算法放在模拟业务场景中考查。除了给出正确答案，还需要注意时间复杂度、边界条件和大规模输入下的性能表现。
2.1 Security Breaching
题目描述
计算攻击者在多层级网络攻击模拟中能够获得的积分。
- 攻击者需要依次突破 n个安全层级，层级编号为1 到 n。
- 攻击者可以从任意层级 i 开始攻击，初始能量为 k。
- 在每个层级i，攻击者必须消耗
layers[i]点能量才能突破该层级。 - 如果当前能量不足以突破该层级，攻击失败并立即结束。
- 成功突破后，如果剩余能量大于或等于
energy[i]，攻击者获得 1 分。
请计算一个数组，其中第 i 个元素表示攻击者从第 i个层级开始，在初始能量为 k 的情况下能够获得的最高积分。返回每个起始层级对应的最高积分数组。
解题思路
可以从每个起始层级分别模拟攻击过程。对于起始位置 i，将当前能量初始化为 k，并从第 i 层开始依次遍历后续层级。如果当前能量不足以支付 layers[j]，就立即停止；否则扣除对应能量，再判断剩余能量是否达到 energy[j]，满足条件时积分加 1。遍历结束后，将累计积分写入结果数组。这种方法容易实现，也能直接对应题目的能量消耗和得分规则。
- 时间复杂度：O(n^2)
- 额外空间复杂度：O(1)，不包括结果数组
如果原题的数据规模较大，还需要结合完整约束寻找更高效的算法。以上复杂度分析基于题目给出的规则，不代表已经确认这是最优解。
2.2 Shopping Optimization
题目描述
Alex 在 Ocora Galleria Mall 购物，商场中的每个摊位都以固定价格出售商品。所有摊位按照商品价格从左到右非递减的顺序排列。给定一个包含 n个整数的数组 prices，其中 prices[i] 表示第 i 个摊位的商品价格。此外，还有 q个查询需要处理。每个查询包含以下两个参数：
pos：Alex 开始购物的位置。amount：Alex 拥有的金额。
Alex 会从位置 pos 开始，依次访问后续摊位，直到第 n 个摊位。对于每个访问过的摊位，Alex 最多只能购买一件商品。请计算在不超过可用金额 amount 的前提下，Alex 最多能够购买多少件商品，并返回每个查询对应的结果。
解题思路
由于 prices 已经按照非递减顺序排列，可以使用前缀和预处理价格累计值，再通过二分查找快速回答查询。定义前缀和数组 prefix，其中 prefix[i] 表示前 i 件商品的累计价格。对于从位置 pos 开始的查询，购买从 pos 到 r 的商品所需金额为：prefix[r] - prefix[pos - 1]
在商品价格非负、且题目规则允许依次购买所经过摊位的商品时，可以利用二分查找寻找满足累计花费不超过 amount 的最远位置 r。答案就是 r - pos + 1。前缀和可以将每次区间花费计算从线性时间降为 O(1)，二分查找则将每次查询的时间复杂度控制在 O(\log n)。
- 预处理时间复杂度：O(n)
- 每次查询时间复杂度：O(\log n)
- 总时间复杂度：O(n+q\log n)
该解法基于上述购买规则。如果原题允许跳过买不起的商品、选择性购买后续商品，或包含其他限制，则需要重新确认算法。
3. Uber Technical Interview
Uber Technical Interview 的具体安排取决于岗位和级别。Coding 面试通常要求候选人解释解题思路、实现代码并分析复杂度；System Design 或 LLD 则更关注需求分析、架构选择和技术方案的取舍。遇到 Follow-up Questions 时，需要根据新增条件调整原有方案。
4.Uber VO: Coding and System Design
Virtual Onsite（VO）通常比 OA 更关注候选人的现场分析与沟通能力。Coding 面试可能要求候选人边解释思路边实现代码，并讨论复杂度与边界情况；System Design 则更强调需求澄清、架构选择、数据流、可靠性和扩展能力。对于 Uber 这类涉及实时出行与定价的业务，能够将技术设计与实际业务约束联系起来尤其重要。
4.1 System Design：实时动态加价系统
题目描述
Design a real-time surge pricing engine。系统需要根据地理区域计算加价乘数，综合历史需求、天气及大型活动等因素，并至少每 60 秒更新一次，供计价服务调用。
解题思路：优先梳理数据流向：定位和叫车事件流入 Kafka，利用 H3 将经纬度映射到网格，再通过 Flink 实时维护供需状态，随后定时计算加价乘数并存入 Redis。乘客查询价格时，计价服务直接读取缓存。需要区分价格更新周期与数据处理延迟：例如，每 30–60 秒生成一版新价格，而链路的 P99 延迟低于 5 秒则是另一项设计指标。
供给侧需要统计当前可用司机，按 driver_id 保存最新位置和接单状态，并将超时未更新的司机移出统计。同一司机上报多条 GPS 消息时，需要避免重复计数。需求侧按 request_id 去重，同时明确统计窗口内的请求是否包含已取消和已完成的订单。
H3 用于组织地理数据和查询邻近网格。网格粒度需要结合司机密度与价格稳定性进行选择；融合邻近区域的供需情况时，还需要考虑实际接驾时间。
Follow-up 1：加价乘数具体怎么算？
解题思路
先用 max(1.0, demand / (supply × target_ratio)) 解释供需比，这是一个便于讨论的简化公式。供给为零时需要单独处理，并为计算结果设置上限。target_ratio 需要结合统计窗口和供需口径进行校准，不能直接将 GPS 消息条数作为供给量。
邻近区域的供需情况可以按接驾时间进行加权，避免因网格边界导致价格突变。查询一跳邻居时，需要确认返回结果是否包含中心网格，防止重复统计。最后，再结合历史需求基线、天气和大型活动等信号进行调整，并通过价格平滑机制限制短时间内的乘数波动。
Follow-up 2：Flink 任务中途崩溃怎么办？
解题思路
Flink 任务可以通过 checkpoint 恢复窗口状态和消费位置，然后继续处理 Kafka 中的事件。写入 Redis 时，可以附带结果版本和计算时间，防止恢复后产生的旧结果覆盖更新的价格。DLQ（Dead Letter Queue）主要用于隔离需要单独处理的异常数据，不能直接解决整个 Flink 作业崩溃的问题。
读取端可以根据 computed_at 判断价格是否过期。在约定时间内允许继续使用旧值，超过阈值后则执行预先配置的降级策略。如果题目约定降级乘数为 1.0x，就应在此时生效。同时，缓存 TTL 也需要与过期判断和降级规则协调，避免旧值已经被删除，而降级策略尚未触发。
Follow-up 3：网格跨越城市边界，应该用哪套规则？
解题思路
只说“每个城市单独配置”还不够。一个 H3 网格可能跨越行政边界，需要根据实际位置识别适用的 policy_id，并将规则版本传入计算和查询链路。邻近网格的供需情况仍可作为计算信号，但最终价格必须遵守当前报价适用的区域规则。
缓存键可以加入 city_id、policy_id 和 H3 网格 ID。规则发生变化后，需要重新计算或失效相关缓存。不能只根据网格中心决定整个网格适用哪套规则，边界区域还需要保留基于实际坐标的判断。具体价格上限应依据已核实的业务规则确定，不应将某个城市的限制直接当作通用常数。
回答这类 System Design 题时，应先确认业务指标、流量规模和区域规则，再展开架构设计。讨论供需计算时，还需要说明价格上限、平滑机制和异常情况下的处理方式，解释这些设计如何满足业务需求，而不只是罗列技术组件。
4.2 BQ 轮：分享一次你与团队在技术决策上产生分歧的经历。
解题思路
可以使用通知系统从定时轮询迁移到事件驱动的案例，按照 STAR-L 结构组织回答。先交代背景：数据库每 5 秒被轮询一次，并出现 CPU 使用率峰值。接着说明自己为什么提出使用 Kafka 和事件驱动架构。面对团队对运维成本的顾虑，可以通过三天的原型验证，对比新旧方案的延迟和资源消耗，同时明确新增的维护工作。
回答示例中的结果是事件链路平均延迟约 200ms、CPU 使用率下降 60%。这些数字需要有对应的测量依据；轮询间隔也不等于平均通知延迟。实际面试时，应替换成自己项目中的真实数据，并说明如何回应同事的顾虑，最终达成一致。
这道 BQ 题容易出现的一个问题，是将队友描述成保守、固执的一方。回答时应避免这种表达，重点突出自己如何通过原型验证和量化指标化解分歧，基于客观数据推动团队达成共识，展现技术判断力与协作能力。
总结
准备 Uber 面试时，可以分别练习 Coding、System Design 和 BQ，再通过模拟面试检查自己的分析与表达。对于实时出行和动态定价相关的设计题，除了说明架构，还要讲清楚数据时效性、异常处理和业务规则；BQ 则应结合真实经历，突出个人的判断依据、沟通过程和实际结果。
如果你正在准备Uber或其他大厂的 OA 或面试，除了刷题，也可以结合真实面经熟悉常见题型和考察方向。InterviewShow 整理了 Uber Microsoft、Amazon、Google、Stripe、TikTok 等科技公司的面试资料，可领取相关公司的 OA/VO 真题，帮助你了解常见考点和面试形式。我们也提供 OA 辅助和面试辅助服务，覆盖 Coding、System Design 和 BQ。你可以查看服务介绍，或直接联系我们了解详情。
FAQ
Uber OA 难吗？一般考哪些题型？
Uber OA 主要考查 Data Structures、Algorithms 和代码实现能力，常见练习方向包括数组、前缀和、二分查找、滑动窗口及其他算法问题。除了通过测试用例，还需要关注边界条件、时间复杂度和大规模输入下的运行效率。
Uber VO 会考 Coding 和 System Design 吗？
Uber VO 可能包含多轮 Coding、System Design 或 Low-Level Design（LLD），具体安排取决于岗位和级别。Coding 通常关注解题思路、代码正确性、复杂度分析及 Follow-up Questions；System Design 更关注需求澄清、架构设计、数据流、可靠性和扩展能力。
Uber Behavioral Interview（BQ）应该怎么准备？
准备 BQ 时，可以使用 STAR（Situation、Task、Action、Result）结构整理真实项目经历，重点准备团队协作、技术决策、处理分歧、解决问题和应对挑战等主题。回答时应突出个人采取的行动、判断依据和实际结果，涉及性能或业务指标时，需要确保数据真实且能够解释。