Uber SWE / MLE VO：Coding、Design 和实验题怎么拆

💡 核心要点 (Key Takeaways)

• Uber coding 题经常带地图、时间窗口、组织结构和动态状态，不能只套标准题模板。
• MLE / DS 方向要准备 marketplace 实验、switchback、guardrail 和 rollout。
• Senior / Staff 要把 system design 和 leadership collaboration 一起准备。

Uber 题型的共同特征

Uber 的题经常来自真实业务对象：路线、组织结构、日志窗口、用户事件、派单、支付、实验。题目本身未必深，但状态定义和边界条件很多。候选人如果只找相似 LeetCode，容易在 follow-up 中失去方向。

Coding 必练题型

从本地面经看，Uber coding 可以优先练四类：图方向、树/组织结构、时间窗口、动态计数。每类题都要准备异常数据和生产化追问。

• 图方向：minimum edge reversal away from root，follow-up 做所有 root 的 reroot DP。
• 组织结构：manager 下属查询、多层 subordinate、cycle、重复员工和权限。
• 时间窗口：daily logs 连续出现、shortest subarray with k distinct、在线 cart 统计。
• 动态计数：first / kth non-repeated user、primary/secondary sum update。

MLE / Scientist 要补实验设计

Uber 的 marketplace 场景有明显干扰：乘客、司机、区域、时间窗口会互相影响。准备实验题时，不要只说普通 A/B test，要能解释 switchback、geo/time bucket、treatment contamination、seasonality、guardrail metric 和 rollback。

System Design 的表达重点

Uber 系统设计可以围绕派单、实时位置、支付、行为日志和 marketplace 平台准备。回答时要强调实时性、可靠性、峰值流量、数据一致性、监控和故障降级，而不是只画服务方框。

VO 前 48 小时怎么压缩

如果已经约到 Uber VO，建议最后两天只做三件事：一次 coding mock 找流程漏洞，一次 marketplace design mock 找取舍漏洞，一次 BQ / leadership mock 找表达漏洞。不要临时开大量新题。

follow-up 延伸的练法

Uber 面试官喜欢延伸题目，follow-up 延伸的练习和基础题本身一样重要。每类 coding 题做完基础 case 后不要停，再花 3 分钟做三件事：第一，列出面试官可能延伸的 2-3 个方向，比如改输入规模、加新约束、换目标，minimum edge reversal 做完就延伸所有 root 的 reroot DP；第二，对每个延伸说明代码哪部分要改、哪些不变量保持、哪些被破坏、复杂度怎么变；第三，挑最可能的那个延伸真改代码，改完重跑旧测试，确认基础 case 没坏。练习时维护一份「题目变体清单」：每类题记录基础 case、常见延伸和你的改法。时间紧时不必覆盖所有延伸，每类题只固定 1-2 个最可能的延伸，把「代码哪部分要改」的答案练到流利；列延伸时优先改输入规模或加约束的方向，纯「换一道类似题」的延伸在面试里出现得少。每类题练完再做一次限时复练：25 分钟内完成基础 case 加一个延伸，检验节奏是否跟得上面试。面试里遇到延伸，你不是在做新题，而是在翻你准备好的清单。

BQ 和 leadership 题的准备

Uber SWE / MLE 的 VO 通常包含行为面和 leadership 题，准备质量直接决定评价下限。建议提前准备三个故事：一个被依赖卡住后推动解决的、一个通过讨论改变技术方向的、一个自己犯错后恢复的。每个故事按 STAR 组织：背景和目的一句，你做过的 2-3 个动作（强调你自己的判断而不是团队动作），结果（没有数字就讲过程和后续），最后一句反思。同一故事可以用于协作、冲突、失败类问题，只是侧重点不同。面试前把每个故事出声读两遍并计时，超过 3 分钟就删；每个故事再备一个一句话版本，「我做了 X，结果是 Y」，收尾总结时用，防止时间不够跑题。Staff 级候选人还要多准备一层：在故事里体现你如何影响跨团队决策、如何在有限权限下推动结果。面试官想听的是判断，不是长叙事；如果某个问题答不出具体动作，说明这个故事还没准备好，现场想不出故事时不要编，先说最接近的经历，再说明差别和你会怎么处理。