最近看到有人说 Uber SDE 面试比较「水」，亲身走完一轮并不这么觉得。流程紧凑，OA 和电面尤其容易翻车，Onsite 五轮连打也很耗精力。按真实顺序记一下。
OA｜70 分钟 4 道 Coding
形式是 70 分钟内完成 4 道题。我体感大概 2 Easy、1 Medium、1 Hard，Hard 出在第 3 题。时间非常紧，难度梯度明显，后面两道会明显吃力。
建议先扫一遍，Easy / Medium 先落分，再回头啃 Hard。一上来卡在难题上，很容易心态不稳，后面时间也不够用。题型偏经典，网上能找到类似方向，可以提前针对性练手感和时间分配。
高频题型：滑动窗口（找最长满足条件的子数组）、图论（课程表、最短路）、合并区间、二分查找变体。有人碰到的是给一个整数数组和数字 K，找最长子数组使得其中任意两个数的差的绝对值小于等于 K，暴力 O(n⁴) 能想到，但要优化到 O(n) 得用双端单调队列维护区间最大最小值。
Phone Screen
这轮我之前没太当回事，以为就是走流程。结果面试官上来先聊了十五分钟我的项目，问得非常具体——为什么选这个架构、当时有没有考虑过别的方案、瓶颈在哪里、怎么测的性能提升。
我在讲某个微服务拆分的决策时有点虚，说”大家当时觉得这样比较好”，面试官直接接了一句”那你自己是什么判断”——我才意识到他要听的是我个人的技术决策逻辑，不是团队共识。
简历上每个项目要准备到能接三层追问的程度，不然这轮很容易露馅。
Onsite 五轮
五轮连轴，我提前一天就休息到位，但到第四轮的时候还是明显感觉脑子在降速。这种感觉很难用练题来弥补，状态管理是真实变量。
第一轮：Coding
题目是在一个二维网格里找最大的子矩形，使得它的四条边上的格子全部是 1。O(n²) 的暴力思路能想到，但要优化要用到单调栈或者预处理每行的高度。
我当时先给了 O(n³) 的解法，面试官让我继续优化，我说到了用”每行当作直方图高度”这个思路，然后往单调栈方向推，最终写出了 O(n²) 的解法。面试官没有明确说好或不好，只是说”还有没有更好的”，我说理论上可以再优化但时间内写不完，他点头让我继续。
第二轮：Coding
这轮出的是 Uber 自动驾驶组的题，完全不是 LC 套路。
题目一：地图范围是 [-180,180]×[-180,180]，有一个目标机器人。给一个 API，输入是正方形左下角坐标和边长，返回目标是否在这个正方形里。要求用最少的 API 调用次数精确定位目标。
我一看这题结构就反应过来了——四叉树二分。每轮把当前正方形切成四个子区，扫前三个，哪个返回 true 就进哪个，如果三个都 false 那目标一定在第四个（不用调用）。边长缩到精度阈值（1e-5）就返回中心坐标。每轮最多调用 3 次，总调用约 75 次以内。
FOLLOW-UP是：如果有多个机器人怎么解决。
题目二：API 改成”区域内至少一个机器人就返回 true”，要求找出所有机器人坐标。
这下不能用唯一性跳过第四象限了，得独立检查所有四个子区，改成 DFS 递归——对每个子区调用 API，返回 true 就递归进去，到达精度阈值就记录当前中心点。设机器人数为 K，复杂度 O(K·log(范围/精度))，递归栈深度约 26 层。
面试官追问了两个边界：如果两个机器人非常近会不会漏？如果 API 有延迟怎么优化调用次数？我说精度够细就不会漏，延迟的话可以并行四个子区的调用再汇总结果，用异步 API 而不是串行调用。
这轮聊得挺顺，面试官最后说”你的思路很清楚”，是五轮里唯一给了正向反馈的。
第三轮：System Design
Uber 的系统设计聚焦在高吞吐量的实时系统——调度系统、位置追踪、支付处理，非常贴近他们的真实业务。
我碰到的题目是设计实时打车调度系统：用户发起请求，匹配最近的司机，考虑实时位置更新、高并发匹配、异常处理。
我从 clarify 开始——DAU 多少、QPS 峰值、延迟要求、地理范围。面试官给了”10M 日活、峰值 10 万 QPS、匹配延迟要在 500ms 以内”。
架构上我分了四层：位置服务（司机实时上报位置，写入 Redis 的 Geohash 索引，高写入频率用 Redis Cluster 分片）→ 匹配服务（查附近司机、按距离和评分排序）→ 调度服务（预订单分配、幂等处理）→ 通知服务（Kafka 异步推送）。
追问最多的是 Geohash 的精度怎么选和热点区域（比如机场）怎么处理。我说 Geohash 精度根据搜索半径动态调整，热点区域可以用额外的本地缓存或者专用集群隔离流量。
第四轮：项目深挖
第四轮了，现在脑子已经开始有点转不过来。面试官拿着我的简历，选了一个我觉得最有把握的分布式系统项目开始问。前几个问题我都答得比较顺，但聊到”如果要重新设计这个系统你会改什么”的时候我停了一下太久。
后来我说”我当时有一个决策现在回头看是偏保守的——选了强一致性，但其实这个场景可以接受最终一致性，用最终一致性能显著降低延迟”。面试官接着问”那你当时为什么做这个保守决策”，我说当时对业务的 SLA 要求没吃透，偏向了保险的选择。
第五轮：Behavioral
HM 轮，围绕 Uber 的 culture values 来问，高频问题是：
你是怎么驱动一个跨团队的复杂项目落地的；遇到过技术决策上的分歧怎么处理；做过最有影响力的一个优化是什么，具体量化数据是什么。
Uber 非常看重候选人有没有在规模化场景下驱动过有可量化结果的事情，BQ 回答里具体的数字和指标是加分项，不要停在”我们提升了性能”，要说清楚提升了多少、怎么测的。
关于拿下 Uber SDE 的建议和经验分享
这次 Uber 能比较顺地走完，OA 阶段我找了 InterviewShow 做OA助攻，Onsite 前也用他们的 mock 过了几轮。对时间紧的 CodeSignal 题和项目深挖、系统设计的追问节奏，提前过一遍会踏实很多。
如果你也在准备 Uber 或其他大厂的 OA / VO，又觉得一个人抓重点比较难，可以去了解一下他们的助攻和模拟。按自己的节奏来就好。