OfferForge 导师 Dr. W. — 博士毕业，前 FAANG Senior MLE。研究方向为大规模分布式机器学习系统，曾在顶级国际学术会议发表多篇论文。负责团队学术方向把控与 MLE 面试辅导。
OfferForge 导师 Dr. S. — 前大厂 Senior SDE，精通分布式系统与大规模数据处理。曾在顶级技术会议发表多篇技术报告，专注于系统可扩展性与可靠性。负责课程体系设计与 System Design 面试辅导。
OfferForge 导师 Dr. L. — 前大厂 Senior SDE，深耕分布式系统与微服务架构。在服务治理、事件驱动架构方面有丰富实战经验。负责求职策略制定与 SDE 面试辅导，已帮助多位候选人斩获 Senior 级别 Offer。
最近辅助了大量 Uber VO，整体下来最大的感受并不是题太难。题目本身大多不复杂，但如果你不清楚他们在看什么，很容易在自我感觉还行的情况下被刷掉。趁记忆还比较新，把自己以及身边收集到的多场 Uber 面经整理成一篇，希望能给准备 Uber 的同学一个更真实的预期。
如果你是刷了大量 hard 算法题来准备 Uber，方向其实有点偏。Uber 的面试更像是在问一个问题：你是不是一个能在真实工程里稳定交付的人？Coding 轮更多是工程向的问题，System Design 很贴近业务，Behavioral 的权重也明显高于很多公司。算法会考，但往往不是那种靠技巧取胜的题，而是看你写得是否干净、是否考虑边界、是否能顺着需求往下走。
Uber 很爱出停车场、Meeting Room、Reservation System 这一类题目。比如设计一个停车场系统，支持 park、unpark、checkCar，不同类型车位有不同限制；或者设计一个 meeting reservation system，给定开始和结束时间，返回 meetingId，没有空房就抛异常。这些题放在 Leetcode 上基本都是 easy 到 medium，但 Uber 非常在意你是否按需求一步一步实现。有一轮 onsite 的 coding 非常典型：面试官会把后续的小问一次性说出来，但如果你为了方便以后提前设计一个复杂的数据结构，反而会被认为没有按当前问题作答。他们希望你把每一问当成独立的小需求，在已有实现上往前推进，而不是从一开始就为最终版本铺路。
从多场面经来看，Leetcode 原题出现频率并不低，比如 79、57、153、305、362、729 这些。但 Uber 并不满足于你写出标准解，而是会不断追问。有的题会要求你在已有实现上继续扩展功能，比如在 calendar booking 的基础上支持删除；有的会在 rate limiter 之后讨论如何扩展到分布式；还有电面会重点看你写的 test cases，以及当 test case 改变时，程序行为是否合理。在 Uber，写完代码只是开始，解释、扩展同样重要。
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 并不是你说得通就行，而是非常看你是否真正理解产品问题。