最近辅助了大量 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，没有空房就抛异常。这些题放在 Leetcode 上基本都是 easy 到 medium，但 Uber 非常在意你是否按需求一步一步实现。有一轮 onsite 的 coding 非常典型：面试官会把后续的小问一次性说出来，但如果你为了方便以后提前设计一个复杂的数据结构，反而会被认为没有按当前问题作答。他们希望你把每一问当成独立的小需求，在已有实现上往前推进，而不是从一开始就为最终版本铺路。

三、Leetcode 原题不少

从多场面经来看，Leetcode 原题出现频率并不低，比如 79、57、153、305、362、729 这些。但 Uber 并不满足于你写出标准解，而是会不断追问。有的题会要求你在已有实现上继续扩展功能，比如在 calendar booking 的基础上支持删除；有的会在 rate limiter 之后讨论如何扩展到分布式；还有电面会重点看你写的 test cases，以及当 test case 改变时，程序行为是否合理。在 Uber，写完代码只是开始，解释、扩展同样重要。

四、System Design：热力图是入门，但远远不够

Uber driver heatmap 确实是高频题，很多人都会准备，但真实面试里并不是万能答案。有的面试官会直接考，有的会给一个非常接近但并不相同的问题，有的干脆完全不用。System Design 中见过的题目包括 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 分钟都在问这些，而且追问得非常细。