上个月刚结束我的 Uber loop。目标是 L5 backend。分享一些笔记，因为我花了两周 Google 这些，结果大多都是过时信息。
system design 轮是 60 分钟，一个面试官，没有旁听的 co-interviewer。他们会发你一个类似 Coderpad 的共享文档，但主要是画框图和讲思路。
我的题目在 rides/logistics 方向（不想说得太具体）。设定是：设计一个核心 dispatcher 组件，能在大规模下做实时分配。尽量从他们的业务视角来想，Uber 的面试题几乎总是基于他们真实系统在做的事。
他们真正看重的点： 一开始先做估算。不用精确算数，但在你开始设计前会先问「how many ride requests per second in SF at 5pm Friday?（周五下午 5 点，旧金山每秒大概有多少个打车请求？）」。 数据模型。他们想看你怎么思考实体：Driver state、rider state、trip state、time to live。 主动指出瓶颈。别等他们来问「where does this fall over?（这个方案会在哪些地方撑不住、崩掉？）」。 横向扩展：你的队列或存储的分片策略。提到了 geohashing，对基于位置的业务很合理。 故障模式。dispatcher 在分配过程中崩了怎么办？at-least-once vs at-most-once 语义。
我面试前刷了经典的 Leetcode 题「design Uber（设计 Uber）」，说实话这在术语表达上有帮助，但真实面试会在一个点上挖得更深，而不是把整个面都扫一遍。
整体感觉挺协作的。我过度设计时面试官两次 push back，我觉得很公平。这其实是个好信号：不要一上来就 gold-plate，展示你知道什么时候该停。
总共 5 轮：coding x2，system design x1，behavioral x1，hiring manager x1。HM 轮意外地很技术。他问的是我过去项目里做过哪些取舍，不只是 STAR-method 那套。
如果你目标是 L5 SWE，system design 备考建议留出 3-4 周。我用的是 Donne Martin 的 system design primer 加 Uber 的 engineering blog。这个 blog 真的挺有用，他们写过 dispatch stack 和 Kafka 的使用。