如果你正在准备大厂面试，Uber 大概率在你的清单上：它的面试有自己的脾气——算法题偏爱图论，系统设计几乎必考自家业务，L4 以上还会多出一轮机器编码，而最后的 Bar Raiser 专门深挖你的项目。本文把 Glassdoor 上的候选人反馈、LeetCode 讨论区里反复出现的 Uber 高频题、levels.fyi 的薪水数据和 Uber 官方招聘页的信息拼在一起，还原一个真实的 Uber SDE 面试全貌。
先说结论：Uber 面经难在哪
Glassdoor 上 Uber 软件工程师岗位的面试难度评分为 3.2（满分 5 分），正面体验占比 47%，平均约 21 天出结果，样本为 434 份候选人反馈；高级软件工程师的难度评分是 3.3，正面体验 44%，平均约 20 天，样本 93 份。真正让不少候选人意外的是三点：第一，代码必须能跑，Uber 的编码轮在 CodeSignal 上进行，写伪代码、只讲思路是过不了关的；第二，系统设计和算法一样重要，而且题目高度贴合打车与外卖业务；第三，行为面不是走过场，Bar Raiser 会把你的一个项目从头问到尾。所以 Uber 的正确打法是算法加系统设计双线并行、项目故事提前打磨，而不是只刷题。
招聘流程全景：从投递到 offer 的五道关
Uber 的软件工程师招聘流程在 2026 年已经比较固定，全程通常在四到六周走完，个别候选人反馈拖到两个月。Uber 内部招聘正在从集中式向按具体团队招人过渡，轮次组合会因团队和级别略有浮动，招募人员会在流程开始时告诉你本轮的具体安排。
第一关是简历筛选与 recruiter 电话，约 30 到 45 分钟。Recruiter 会核对你的背景与岗位的匹配度，聊你为什么想来 Uber，以及对薪资的预期，这一轮还会决定你的面试循环往哪个方向倾斜。准备一个两分钟左右的自我介绍，讲清楚你做过什么、为什么适合这个团队，比背诵公司介绍有用得多。Uber 的业务线包括出行、外卖、杂货和货运，提前想好自己想去哪个方向，回答会更有针对性。
第二关是线上测评（OA）或技术电话面，两者不一定都出现。应届生和实习生通常先收到 CodeSignal 上的 OA，约 70 到 90 分钟、四道算法题，难度递增；有经验的候选人有时跳过 OA，直接进入约一小时的技术电话面，在 CodeSignal 上现场写一到两道中等难度算法题，代码同样要求能编译运行。
第三关是线上 onsite，一般为四到六轮、总计四到五个半小时，通常在同一天或拆成两天完成。常见组合是两轮编码、一轮系统设计、一轮与 hiring manager 的协作与领导力对话，再加一轮 Bar Raiser；Senior 及以上级别常会增加项目深挖或第二轮设计，应届生循环则通常去掉分布式系统设计、增加编码轮。全部轮次结束后由招聘委员会复核，决定一般在三到五个工作日内给出。
第四关是团队匹配。多数候选人面试时就对应某个团队，也有先过面试再匹配团队的情况，后者可能再延长一到两周，期间 recruiter 的反馈节奏会变慢。第五关是 offer 与谈判，级别定档在这一阶段基本锁定，薪水谈判空间主要在签字费和股票数量上。整个流程里 recruiter 的风格差异很大，有候选人反馈 recruiter 会提前分享准备资料、把所有轮次一次排好，也有反馈说等待期间几乎没有消息；每一轮结束后主动确认下一步时间点，是性价比很高的习惯。
OA 与电话面：CodeSignal 上最容易翻车的地方
Uber 的第一道技术关卡可能是整个流程里单位时间压力最大的一轮。CodeSignal OA 约 70 到 90 分钟、四道题，前两道通常是数组与字符串类的热身题，后两道经常是图论或动态规划，难度可能达到 Hard。评分看的是通过的测试用例与运行效率，暴力解法即使逻辑正确也可能因为超时而拿不到分。社区里流传至少做对三道才比较稳，但这只是候选人之间的经验之谈，官方并没有公布分数线。
电话面相对温和一些，约一小时，一到两道 LeetCode 中等难度题，面试官通常比较互动，会把这一轮当成协作解题而不是单向考核。CodeSignal 的调试功能有限，写代码前先想清楚边界条件，写完后自己跑几个测试用例，包括空输入、单元素和重复元素。
准备 OA 有两个实用建议：把图论和动态规划的模板练到能默写的程度，因为 OA 后两道题最可能出现在这两个方向；练题时给自己掐表，模拟 70 分钟四道题的节奏，先把能拿分的题做对，再回头啃难题。OA 的成绩通常只决定你能不能进入下一轮，目标就是稳稳通过，而不是追求满分。
高频算法题：图与滑动窗口是基本盘
Uber 的算法题有鲜明的业务烙印：它的核心产品就是地图上的实时匹配——派单、路径、动态定价，本质上都是图遍历、流式聚合与滑动窗口问题。LeetCode 讨论区里与 Uber 关联最频繁的题型高度集中在图论，其次是滑动窗口、堆与哈希表，动态规划在 Senior 轮次出现得更多。下面列出的题目，都是在公开的 Uber 高频题统计与候选人反馈中被多次提到的，并非 Uber 官方公布的题库，刷的时候要按题型准备，而不是只背这几道题的答案。
图论是重中之重。多位候选人提到、在 LeetCode 频率统计中排位最高的包括 Bus Routes（公交路线，最短换乘）、Alien Dictionary（外星字典，拓扑排序）、Number of Islands（岛屿数量）及其变体 Number of Islands II（并查集动态连通）、Course Schedule（课程表，环检测）、Clone Graph（克隆图）。图题常带一点 Uber 的业务包装，本质还是 BFS、DFS、拓扑排序与并查集，认出题型比记住原题更重要。
滑动窗口与堆是第二梯队。Design Hit Counter 与 Find Median from Data Stream 在多个高频榜单上都出现过，前者直接对应 Uber 内部的实时指标统计场景，后者是堆的经典应用。Longest Continuous Subarray With Absolute Diff Less Than or Equal to Limit 也被多位候选人提到出现在电话面，Top K Frequent Elements 则出现在 Glassdoor 上的一份 Senior 面经里，面试官要求候选人同时讲最小堆与桶排序两种做法。LRU Cache 是机器编码与算法轮都可能出现的常客，要练到能一次写对。
树、动态规划与字符串题构成第三梯队。Kth Smallest Element in a BST、Binary Tree Right Side View、Lowest Common Ancestor of a BST 在中级（SWE II）循环里出现较多；动态规划在 Senior 循环里更常见，有候选人反馈遇到二维 DP 难题和回文相关的 Hard 题。个别榜单上还列有 Minimum Edge Reversals、Find the Closest Palindrome 这类 Hard 题，说明 onsite 确实可能出现 Hard 题，尤其是在 L5 及以上循环里。
准备策略上，建议按“图论优先、滑动窗口与堆次之、树与 DP 补齐”的顺序分配时间。刷题时不要只追求通过，Uber 的面试官会要求你讲清楚时间与空间复杂度，并追问 follow-up：如果输入变成流式数据怎么办、如果规模扩大十倍怎么办。能主动讲出优化方向和边界情况的候选人，更容易拿到强评价。
系统设计：为什么几乎必考“设计一个 Uber”
如果说算法轮考的是基本功，系统设计轮考的就是你能不能把基本功用到真实业务上。Uber 的系统设计轮最常见的题目就是“设计一个 Uber”或者“设计 Uber Eats”，Glassdoor 上就有候选人反馈被要求设计 Uber Eats 的购物车服务。面试官通常不要求你面面俱到，而是希望你在一个子问题上挖得够深：位置索引、派单匹配、行程生命周期，三选一讲透。
位置索引是第一个关键点。司机每隔几秒上报一次位置，Uber 内部使用基于网格的位置索引，早期用 Google 的 S2 单元，后来发展出自家的六边形网格系统 H3（2018 年开源）。面试里不需要复述 H3 的实现细节，但要能讲清楚为什么需要把地图切成格子：没有索引，每次找附近司机都要全表扫描；有了格子，查询就缩小到几个相邻单元。
派单匹配是第二个关键点，也是最能体现 Uber 业务理解的部分。Uber 早期是“派给最近的司机”，后来改成批量匹配：在收到请求后的几秒内，把附近的乘客与司机放在一批里统一考虑，以降低整体等待时间。匹配的排序依据是预计到达时间（ETA），而不是直线距离，因为路网与实时路况会让“最近”不等于“最快”。还要讲清防重复派单的机制：司机状态的原子切换，保证一个司机不会同时接到两个乘客。
动态定价（surge pricing）是第三个常考点。它的本质是供需信号：同一地理格子内乘客需求超过司机供给时价格上浮，既让部分乘客选择等待，也吸引附近空闲司机向高需求区域移动。设计上按格子计算供需比、定期重新计算、用短 TTL 缓存结果即可。行程本身则是一个状态机：已请求、已匹配、司机前往中、行程中、已完成，支付与评分通常可以声明在范围之外。
系统设计轮的另一个高频变体是设计 Uber Eats 相关服务，比如购物车服务、商家出餐与配送调度。思路是相通的：先问清范围，再给需求与量级估算，然后画出核心模块，最后选深水区展开。Senior 候选人还会被要求讲扩展性与取舍：按区域分片、内存中保存实时位置、区域故障时如何不丢失进行中的行程。
机器编码轮：L4 以上要过的第二道设计关
不少候选人准备 Uber 时只练了算法和系统设计，到了现场才发现还有一轮机器编码（machine coding），这是 Uber 面试里很有特色的一环。从 L4 开始，循环里常常会出现一轮低层级设计，要求你在一小时内写出真正能跑的类与接口。多位候选人反馈的题目包括设计停车场、会议调度器、Uber Eats 购物车与计价引擎，考察面向对象设计、并发安全与可扩展性。
这一轮的评分维度与算法轮不同。面试官会看你的类划分是否合理、接口是否清晰、代码是否考虑了线程安全，比如两个乘客同时抢同一辆车时怎么办，定价策略要不要用策略模式切换 surge 定价与标准定价。准备时建议用自己最熟悉的语言完整实现两到三个经典机器编码题：停车场、电梯调度、缓存系统，重点是 45 分钟内写出结构清晰、可测试的代码。面试中先花五分钟讲清类图与接口，再动手写代码。
行为面与 Bar Raiser：项目深挖才是分水岭
Uber 的行为面由两轮组成：一轮是与 hiring manager 的协作与领导力对话，约 75 分钟；另一轮是 Bar Raiser，约一小时，由一位与招聘团队无直接利益关系的面试官主持。两轮都会深挖你的过往项目，但 Bar Raiser 尤其以“反向深挖”著称：选定你简历上的一个项目，从架构、取舍、量化结果一路追问，问题常常是“如果重做一次你会改什么”“当时为什么没选另一个方案”。
准备行为面最有效的方法是提前写好五到六个项目故事，每个故事都按 STAR 结构准备：背景、你的任务、你采取的行动、量化的结果。重点挑那些能体现规模、难度与影响力的项目。故事里要讲清楚你是怎么推动事情落地的，而不只是你参与了什么。
Glassdoor 上反复出现的行为问题还包括：举一个你帮助别人的例子、讲一次工作中的冲突以及你是怎么处理的、讲一次你主导的、结果不如预期的项目。回答时不要只讲“我们团队”，要明确讲“我做了什么决定、为什么这样决定、结果如何衡量”。简历上写的每一个系统、每一次优化，都要能讲出当时的约束、备选方案与最终取舍，讲不出来的内容宁可不写上简历。
难度横向对比与通过率体感
把 Uber 放在大厂坐标系里看，它的难度定位比较清晰。算法轮以 LeetCode 中等难度为主，Senior 循环会出现 Hard 题，整体难度低于以 Hard 题著称的个别公司。系统设计与机器编码两轮是 Uber 的特色，准备不足的候选人容易在这里丢分。Glassdoor 的数据也印证了这一点：难度评分 3.2 到 3.3，正面体验不到一半，说明不少候选人觉得过程偏硬或者反馈节奏不够友好。
多数成功候选人的准备周期在六到十周，其中算法与系统设计各占约四成，行为面与项目深挖占约两成。如果你已经有大厂面试经验，Uber 的循环上手会快一些；如果是第一次面大厂，建议把准备周期拉长到八周以上，重点补系统设计与机器编码这两块短板。另外，Uber 的招聘节奏受业务与编制影响，不同季度、不同团队的通过率会有波动，保持与其他公司的面试并行是更稳妥的策略。
薪水包：级别、口径与谈判空间
Uber 的工程师级别从 L3 到 L8，L3 是 Software Engineer I，L4 是 Software Engineer II，L5 分为两个子级：L5a 是 Senior Software Engineer，L5b 是 Staff Software Engineer，L6 是 Senior Staff Software Engineer，L7 是 Principal Engineer。Uber 官方并不公布级别与职级的对照表，以上对应关系来自 levels.fyi 的整理与招聘帖文：Senior 岗位通常要求六年以上经验，Staff 要求九年以上，Senior Staff 要求十年以上。L5a 到 L5b 是 Uber 薪水跃升最大的一级，offer 阶段定到 L5b 还是 L5a，对总包的影响比同级内的谈判更大。
总包数字方面，不同来源的 levels.fyi 汇总存在明显出入，需要并列说明。一份 2026 年 11 月的汇总（美国，2,943 份报告）给出的中位总包是：L3 约 19.2 万美元，L4 约 27.7 万美元，L5a 约 36.9 万美元，L5b 约 60.5 万美元，L6 约 79.7 万美元，整体中位约 30 万美元。另一份同样标注来源为 levels.fyi 的汇总给出的数字更高：L3 约 20.3 万美元，L4 约 27.8 万美元，L5a 约 42.1 万美元，L5b 约 62 万美元，L6 约 80.6 万美元，L7 约 138 万美元。两份汇总的 L5a 相差约 5 万美元，差异可能来自统计时间、样本范围与口径不同，本文无法核实哪一份更准确，谈薪时请以 levels.fyi 官网的实时页面为准，不要把任何一个数字当成承诺。
基本工资（base）有官方招聘帖文可查，相对可靠。Uber 在旧金山、西雅图、桑尼维尔与纽约的 Software Engineer I 岗位公布的 base 范围是 15 万到 15.8 万美元；Senior Software Engineer（L5）在旧金山、桑尼维尔与纽约的 base 范围是 20.2 万到 22.4 万美元；Staff 岗位的 base 范围是 23.2 万到 25.8 万美元；Senior Staff（L6）岗位的 base 范围是 26.7 万到 29.7 万美元。完整总包由 base、年度奖金与限制性股票（RSU）三部分组成，从 Staff 级别开始，股票成为占比最大的部分；签字费通常是谈判中弹性最大的部分。levels.fyi 的数据是候选人自报的 offer 数据，会随股价波动，而且不同城市、不同团队的数字差异很大，谈 offer 时一定要问清 base、奖金目标、股票总额与归属期这四项再比较。
准备时间线：八周计划怎么排
八周计划可以按下面的节奏准备。第一到第二周打基础：每天两到三道 LeetCode，以图论、滑动窗口与堆为主，同时整理项目故事，挑出三个最能讲的项目写成 STAR 稿。第三到第四周上强度：算法题量加到每天三到四道，加入动态规划与树题，开始系统设计的理论学习，重点理解地理位置索引、派单匹配与动态定价。第五到第六周做模拟：每周至少两次完整模拟面试，一次算法、一次系统设计，用 CodeSignal 的环境练手，行为面做一次 mock。第七周查漏补缺，第八周调整状态、减少新题量。
如果时间只有四周，建议砍掉一半的题量，但不要砍掉系统设计与行为面的准备：每天两道算法题保持手感，每周两次系统设计模拟，项目故事提前写好并反复讲熟。时间再紧张，也不要跳过在 CodeSignal 上练习的环节，因为“代码必须能跑”是 Uber 与很多公司最大的不同。
常见失误与避坑清单
第一，只刷算法、不准备系统设计。Uber 的系统设计轮权重很高，完全不准备等于主动放弃一轮，至少把“设计 Uber”的完整思路演练两遍。第二，代码写不出来能跑的版本。Uber 的编码轮要求代码编译通过并跑过测试用例，只讲思路是过不了关的，平时练题就要养成写完自测的习惯。第三，项目故事讲不清楚。Bar Raiser 会追问技术细节与量化结果，简历上答不上来的内容会直接拉低评价。第四，忽略机器编码轮。L4 以上的候选人要额外准备面向对象设计题，停车场、会议调度器、购物车这几类经典题至少完整实现一遍。第五，谈薪时只看总包数字。Uber 的总包里股票占比很高，要问清股票总额、归属期与签字费，分开比较再做决定；同时要确认级别定档，L5a 与 L5b 的总包差距远大于同级内的谈判空间。第六，流程中途断联。Uber 的 recruiter 反馈节奏不稳定，每轮结束后主动确认下一步时间点。
结尾总结
Uber 的 SDE 面试是一套“算法加业务理解”的组合拳：图论与滑动窗口是算法轮的基本盘，系统设计几乎必考自家业务场景，机器编码轮考验你写真正能跑的面向对象代码，而 Bar Raiser 则用项目深挖来区分“做过”和“真懂”。它的难度不在某一道难题上，而在轮次多、覆盖广，任何一块短板都可能成为被淘汰的原因。好消息是，这些考察点都是可以系统准备的：八周时间，按图论优先的顺序刷题，把“设计 Uber”练到能脱稿讲完，把项目故事打磨到能回答三层追问，再提前适应 CodeSignal 的环境。薪水方面，记住级别定档是最重要的变量，谈 offer 时以 levels.fyi 的实时数据为参考。祝你面试顺利，拿到理想的 offer。
本文信息来自公开渠道整理，仅供参考，不构成求职保证。
暂无评论内容