最近辅助了大量 Uber VO，最大的感受不是题太难，而是 Uber 的面试非常明确地在筛选某一类人。题目本身大多不复杂，但如果你不清楚他们在看什么，很容易在自我感觉还行的情况下被刷掉。趁记忆还新，把多场 Uber 面经整理成一篇，给准备 Uber 的同学一个更真实的预期。
一、整体风格：不卷算法，但非常看工程基本功
如果你刷了大量 hard 算法题来准备 Uber，方向其实有点偏。Uber 的面试更像在问一个问题：你是不是一个能在真实工程里稳定交付的人？ Coding 轮更多是工程向问题，System Design 很贴近业务，Behavioral 权重明显高于很多公司。算法会考，但往往不是靠技巧取胜的题，而是看你写得是否干净、是否考虑边界、是否能顺着需求往下走。
二、Coding：题不难，但「怎么做」比「做出来」重要
Uber 很爱出 停车场、Meeting Room、Reservation System 这一类题。比如设计一个停车场系统，支持 park、unpark、checkCar，不同类型车位有不同限制；或者设计一个 meeting reservation system，给定开始和结束时间返回 meetingId，没有空房就抛异常。
import heapq
class ParkingLot:
def __init__(self, capacity_by_type):
# 每种车位类型维护一个可用车位编号的最小堆
self.free = {t: list(range(n)) for t, n in capacity_by_type.items()}
for t in self.free:
heapq.heapify(self.free[t])
self.slot_of = {} # plate -> (type, slot)
def park(self, plate, vtype):
if not self.free.get(vtype):
raise Exception("no spot") # 没空位按需抛异常
slot = heapq.heappop(self.free[vtype])
self.slot_of[plate] = (vtype, slot)
return slot
def unpark(self, plate):
vtype, slot = self.slot_of.pop(plate)
heapq.heappush(self.free[vtype], slot) # 释放后归还编号
def check_car(self, plate):
return self.slot_of.get(plate)
这些题在 LeetCode 上基本是 easy 到 medium，但 Uber 非常在意你 按需求一步步实现。有一轮 onsite 的 coding 很典型：面试官会把后续小问一次性说出来，但 如果你为了方便提前设计一个复杂数据结构，反而会被认为没有按当前问题作答。他们希望你把每一问当成独立小需求，在已有实现上往前推进，而不是一开始就为最终版本铺路。
三、LeetCode 原题不少，但会不断追问
从多场面经看，LeetCode 原题出现频率不低，比如 79、57、153、305、362、729。但 Uber 不满足于你写出标准解，而是不断追问：
| 题号 | 题目 | 典型追问 |
|---|---|---|
| 79 | Word Search | 改 Trie / 多词搜索 |
| 57 | Insert Interval | 基础上支持删除（calendar booking） |
| 153 | Find Min in Rotated Sorted Array | 有重复元素怎么办 |
| 305 | Number of Islands II | 并查集 + 在线加点 |
| 362 | Design Hit Counter | rate limiter 后扩展到分布式 |
| 729 | My Calendar I | 支持取消 / 多重预订 |
有的题会要求在已有实现上 继续扩展功能（calendar booking 加删除）；有的会在 rate limiter 之后讨论 如何扩展到分布式；还有电面重点看你写的 test case，以及当 test case 改变时程序行为是否合理。在 Uber，写完代码只是开始，解释和扩展同样重要。
四、System Design：热力图是入门，但远远不够
Uber driver heatmap 确实是高频题，很多人都会准备，但真实面试里并不是万能答案。有的面试官直接考，有的给一个非常接近但不相同的问题，有的干脆不用。见过的题目还包括：
- Uber Eats 的 search function
- 类似 Robinhood 的 price tracking system
- 甚至 设计 AI chatbot（消息发送、chat history 存储、inference）
有一轮 system design 体验很不好：面试官心里有一个明确解法，架构里包含大量 proxy 和 services，重点讨论 short-term scalability 和 long-term scalability。如果你的设计只是往熟题上套、但抽象层次没对齐，很容易被持续质疑，很难拿到正向 signal。Uber 的 system design 不是你说得通就行，而是非常看你是否真正理解产品问题。
五、Behavioral：Hiring Manager 的权力比想象中大
从多场面经看，Uber 的 Behavioral 非常重视 ownership、collaboration、冲突处理、失败经历，以及你如何面对 blocker。有的 onsite 甚至整整 50 分钟都在问这些，而且追问得非常细。HM 轮的权重很高，技术过了但 HM 不买账，结果一样不乐观。准备时建议按这几个维度各备 2 个 STAR 故事，并想清楚「遇到 blocker 时你具体怎么推进」。
六、总结
Uber 在筛 能在真实工程稳定交付的人：Coding 不卷算法，但极看「按需逐步实现」的工程纪律；System Design 贴业务，要求真正理解产品而非套模板；Behavioral 权重高，HM 决定性强。方向对了，准备会高效很多。
FAQ
Q1：Uber 后端面试要刷 hard 算法吗？
方向有点偏。Uber coding 更偏工程题（停车场 / Meeting Room / Reservation），算法多是 easy-medium 原题（79/57/153/305/362/729），重点在 clean code、边界、按需扩展，而不是 hard 技巧。
Q2：为什么我写出标准解还是被追问？
Uber 看的是「怎么做」。写完只是开始，他们会要求在已有实现上扩展（calendar 加删除、rate limiter 上分布式），并考你的 test case 设计。别一开始就为最终版本过度设计。
Q3：driver heatmap 准备了就够了吗？
不够。heatmap 是入门，真实面试可能考 Uber Eats search、price tracking、AI chatbot，且会深挖 short-term / long-term scalability。关键是真正理解产品问题，而不是往熟题上套。
Q4：怎么准备 Uber 的 HM 行为面？
HM 权重很高。按 ownership / collaboration / 冲突 / 失败 / blocker 各备 STAR 故事，重点讲「面对 blocker 如何具体推进」。如果想要这几类工程题的限时陪练、system design 推演，或需要 VO辅助 / VO代面 的实时对接，可以发岗位 JD 先做题型预测再排练习计划。
正在准备 Uber 面试？
Uber 考的是工程纪律 + 产品理解 + HM 沟通。oavoservice 提供 Uber 全流程陪练：停车场 / Meeting Room / Reservation 工程题限时模拟、heatmap / Uber Eats search system design 推演、HM 行为面演练，也支持 VO辅助 / VO代面 的实时对接。教练含前大厂资深工程师，熟悉 Uber「按需逐步实现 + 持续追问」的评分风格。
立即添加微信 Coding0201，获取 Uber 真题与陪练。
联系方式
- 微信：Coding0201
- Email：[email protected]
- Telegram：@OAVOProxy