Uber 机器学习工程师面试实录 2026：真实面经完整复盘

公司：Uber 岗位：机器学习工程师 (MLE) 面试形式：Virtual Onsite 结果：Pass → Offer

✅ 数组/字符串操作类

一道题给出两个整数数组 nums1 和 nums2，要求找出一组下标 (i, j) 使得 nums1[i] + nums2[j] == target。这是典型的“两个数之和”变种题，可以用哈希表记录一个数组中所有数的补数以实现线性查找。

在另一道题中，给定两个整数数组，求出任意两个数字（不要求索引相同）前缀字符串相同的最大长度。例如 123 和 1234 的前缀为 123，长度为 3。这类题需要将整数转为字符串后，进行两两比较前缀长度，也可以用 Trie 树加速。

有一题是关于字符串精简规则的模拟题，字符串只包含字符 A 和 P，且遵循如下变化规则：两个连续的 P 会变成一个 A，若 P 紧跟在 A 后会变成 P，两个 A 相邻则会互相抵消。每轮都要根据规则进行变换，直到字符串被完全清除或者无法再变化，题目要求计算需要多少轮。

另一道题要求对一段英文文本按照给定的最大宽度进行分段，要求每行居中对齐（centered），不能超过宽度限制。这是一个字符串操作题，重点是掌握如何分行、计算左右 padding，并保持对齐效果一致。

还有一道题是给定两个等长的数组，要求返回一个索引，使得对应位置两个数相除的结果最大。遍历数组并在除法过程中判断是否除数为零，然后比较最大值即可，逻辑简单但考察代码细节处理。

在前缀最大匹配题中，输入是两个数字数组，目标是找出任意一对（不要求索引相同）中前缀匹配最长的两个数字，并输出匹配长度。这种问题适合暴力枚举每一对数字，或者提前预处理后缀数组、使用 Trie 优化匹配。

✅ 模拟题（中到高难）

有一道大模拟题给出一个矩阵，以及五种操作命令：翻转行、翻转列、旋转矩阵、交换行、交换列。命令以字符串数组形式给出，每种指令都需要在矩阵上对应模拟操作。虽然算法不难，但实现起来代码量较大，逻辑也要清晰处理每种变换。

在图书馆借书系统的模拟题中，用户会以特定操作序列与图书馆交互，如借书、还书、查询等。题目本身没有算法难度，但需要维护多个哈希表或字典结构来追踪每本书、每个用户的状态，并妥善处理操作边界，属于典型的业务逻辑题。

另一道经典的系统设计题模拟内存分配器的行为。内存被抽象为一个一维数组，支持 alloc（按 8 字节对齐分配一段连续空间）与 erase（按 ID 释放指定段）操作。题目要求在处理内存分配时考虑对齐原则，并在擦除时释放对应空间。整个模拟过程中，边界条件复杂，需要细致处理。

一道非常典型的模拟题给定一个奇数大小的二维矩阵，其中每个格子填有 0、1 或 2，题目要求将该矩阵改造成一个形似 “Y” 字的图案，且只能使用矩阵中已有的两种数字。为此需要枚举所有可能的 “Y” 图案（总共六种组合），并逐一与原矩阵对比，最终找出最少需要修改多少个格子才能变换成功。

课程调度题是 Leetcode Course Schedule III 的变种，要求在选课时考虑课程时间区间限制，同时加了“每个时间点只能选最多 X 门课”以及“课程之间分组有优先级”等限制。这题适合用堆加贪心做局部最优选择，但因为限制条件多，也有可能需要 DP 来做全局最优决策。

最后有一道题处理的是一个闭环图，每个节点通过边相连且图一定构成一个环。要求从任意一个节点出发，顺时针遍历整个图并输出路径。由于图结构特殊，题目可视作链表式遍历的变形，重点在于如何从给定边恢复环并按顺序遍历。

✅ 简单数学/逻辑题

有道简单的字符串统计题要求计算一个由 U 和 D 组成的字符串中，向上（U）和向下（D）操作的差值。只需遍历字符串并统计各自数量，最后做减法即可得出结果。

一题关于无人机送货的模拟问题，给出多个补给点，目标是找出送货路径，使得每次选择最近的补给点。虽然听起来复杂，但实质上是一个贪心问题，只要按最近点依次前进即可，不需要考虑动态规划或路径合并。

有一道数组排序题涉及四个维度：胜场（wins）、平局（draws）、得分（score）和失分（concede），要求按照这四个维度的优先级依次排序。这是一道稳定的多关键字排序题，难点在于如何定义排序规则和保证次级关键字正确使用。

二、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 并不是你说得通就行，而是非常看你是否真正理解产品问题。

数组与双指针：LeetCode 15、16、42、11

Uber 对数组题的考察明显比很多公司更偏进阶版本。常见的是 LeetCode 15 Three Sum 和 LeetCode 16 Three Sum Closest，这类题非常适合考察你是否能在排序后正确使用双指针，并处理重复元素。LeetCode 11 Container With Most Water 和 LeetCode 42 Trapping Rain Water 在 Uber 面试中出现频率很高，因为它们不仅考思路，还考你是否能解释清楚为什么指针移动是单调有效的。Uber 面试官通常会对 O(n²) 解法比较敏感，如果你没有主动优化，往往会被直接追问。

滑动窗口与字符串：LeetCode 76、567、424

字符串题在 Uber 面试中非常常见，但难点往往集中在窗口状态维护是否准确。LeetCode 3 Longest Substring Without Repeating Characters 是 Uber 的经典开场题之一，很多面试官会用它快速判断你的基本功。LeetCode 76 Minimum Window Substring 是 Uber 偏爱的上限题，特别适合考察你是否能写出无 bug 的滑动窗口逻辑。LeetCode 567 Permutation in String 和 LeetCode 424 Longest Repeating Character Replacement 都是窗口计数的变体，Uber 会通过这些题看你是否真的理解窗口收缩的触发条件，而不是机械套模板。

HashMap + 前缀思想：LeetCode 560、525、128、347

Uber 非常喜欢通过 HashMap 题来考察候选人的建模能力和复杂度意识。LeetCode 560 Subarray Sum Equals K 是 Uber 的老高频题，面试官很看重你是否能自然想到前缀和 + HashMap，而不是暴力枚举。LeetCode 525 Contiguous Array 是同一模型的进阶版本，重点在于你是否能把 0/1 转换成数学问题。LeetCode 128 Longest Consecutive Sequence 和 LeetCode 347 Top K Frequent Elements 则更多考察你是否能避免排序，直接利用 Hash 结构把复杂度压到 O(n)。

DFS / BFS 与网格图：LeetCode 200、695、994、286

Uber 的图题很少抽象成图论定义，而是几乎都包装成二维网格或业务场景。LeetCode 200 Number of Islands 是必刷题，但 Uber 常常会加 follow-up，比如改成最大岛屿面积（LeetCode 695）或者多源扩散（LeetCode 994 Rotting Oranges）。LeetCode 286 Walls and Gates 也是 Uber 非常偏爱的题型，本质是多源 BFS，能很好地考察你是否真正理解 BFS 的层级含义。Uber 面试官通常会关注你 visited 的处理是否合理，以及是否存在重复遍历的问题。

二叉树与递归：LeetCode 236、124、543、199

树题在 Uber 面试中不算最多，但一旦出现，往往是偏分析和递归语义的题。LeetCode 236 Lowest Common Ancestor 是 Uber 的常客，面试官很喜欢追问你递归返回值的含义。LeetCode 124 Binary Tree Maximum Path Sum 是一道区分度很高的题，Uber 会用它考察你是否能区分对父节点有用的路径和全局最优解。LeetCode 543 Diameter of Binary Tree 和 LeetCode 199 Binary Tree Right Side View 则分别代表 DFS 和 BFS 的经典应用，重点还是在递归与层级遍历的清晰度。

栈与单调结构：LeetCode 20、739、84

相比很多传统公司，Uber 对单调栈的接受度更高。LeetCode 20 Valid Parentheses 虽然基础，但常被作为热身题。LeetCode 739 Daily Temperatures 是 Uber 的高频题之一，非常适合考察你是否能理解单调性的意义。LeetCode 84 Largest Rectangle in Histogram 属于难度偏上的题，但在 Uber 的 Senior 或表现很好的 NG 面试中并不罕见，如果你能写出思路清晰的解法，往往会给面试官留下很深的印象。

动态规划：LeetCode 53、198、300、322

Uber 会考 DP，但整体偏向一维或简单二维 DP。LeetCode 53 Maximum Subarray 是出现频率极高的题，很多时候是作为数组题的 follow-up。LeetCode 198 House Robber 和 LeetCode 300 Longest Increasing Subsequence 都是 Uber 非常喜欢的经典模型，尤其是 LIS，常常会从 O(n²) 追问到 O(n log n)。LeetCode 322 Coin Change 则更偏基础 DP，重点在于你是否能讲清楚状态转移逻辑。

VO - Coding 1

Coding1 基本和 phone screen 一样的节奏，也是先聊项目再做题。这一轮的题更偏 algorithm，是一个经典变形题，类似给一组 intervals，返回重叠最多的时间段，先讲了 sweep line 的思路，然后写了 code。写完之后 interviewer 开始加条件，比如 intervals 是 streaming 的怎么办、如果要支持删除怎么办，慢慢就变成一个更像 real-world system 的问题。这里感觉他们比较看你能不能把一个 leetcode 题扩展成 production-level 设计

VO - Coding 2

Coding2 说是 Depth in Specialization，但实际体验下来还是 coding + 一点设计。这轮题是一个 OOP 设计题，大概是设计一个 ride dispatch system，支持 driver 和 rider 的匹配。一开始先定义了几个 core class，比如 Driver、Rider、Trip，然后设计了一个 matching service。面试官会不断问为什么这样设计，比如如果以后要支持 carpool 怎么扩展，或者 surge pricing 应该放在哪一层。这里重点不是写特别多代码，而是看你的 abstraction 和 extensibility

VO - Architecture

System Design 是 Uber Eats home page feed design，这个题确实最近挺高频的。一开始先 clarify 需求，比如是 personalized feed 还是 generic feed，latency 要求是多少，QPS 大概多少。然后给了一个比较经典的 backend feed 架构：client 请求进来之后，先经过 API gateway，然后进入 feed service。feed service 会从多个 upstream service 拉数据，比如 restaurant service、promotion service、inventory service，然后做 aggregation 和排序。排序这里不涉及 ML，就是基于一些规则，比如距离、评分、是否在营业、是否有优惠等等。

后面 interviewer 会一直 deep dive，比如 feed 是 pull-based 还是 push-based，一开始说 pull，然后被问如果用户很多会不会压力很大，就讨论了 pre-compute + fanout-on-write 的方案，比如提前给活跃用户生成一部分 feed 存在 cache 里。还聊到 caching，比如用 Redis 存 feed，如何做 invalidation，比如 restaurant 下架、库存变化的时候怎么更新。还有 consistency 问题，比如用户看到的餐厅已经关门了怎么办，这里就要在 read path 做一次实时校验。

再往后会聊 scaling，比如如果是全球业务，怎么做 multi-region deployment，如何保证低延迟，以及不同城市的数据隔离。整体就是一个很典型的 backend system design，更偏 data aggregation + caching + scalability，没有涉及 ML。

面试总结

成功经验

充分准备高频题：Uber 的面试题目集中在经典算法和数据结构上，提前准备 LeetCode 高频题非常有必要。
Behavioral 故事要准备充分：使用 STAR 框架准备 5-8 个核心故事，覆盖 Leadership、Conflict、Innovation 等场景。
沟通表达要清晰：解题过程中要主动与面试官沟通思路，不要闷头写代码。
边界条件要主动讨论：面试官很看重候选人对 edge cases 的考虑。

面试注意事项

时间管理：每轮 45-60 分钟，需要合理分配时间给题目、讨论和 follow-up 问题。

技术深度：Uber 的面试官对技术细节要求很高，边界条件、性能优化、系统设计能力都是考察重点。

💡 需要面试辅导？

如果你对准备技术面试感到迷茫，或者想要个性化的面试指导和简历优化，欢迎联系 Interview Coach Pro 获取一对一辅导服务。