上个月我在 Roblox 面了 L5 system design。一开始准备时找不到多少具体信息，所以写个实话版拆解。
这一轮 60 分钟，单个 interviewer。他们让我设计一个实时 leaderboard 系统，要扛住数百万并发用户。乍看很经典，但 Roblox 的语境很重要：他们会强推 UGC 平台场景，所以我得考虑多个游戏各自有 leaderboard 状态，按 game ID 做 partition，并把更新 fan-out 给在线的玩家。
他们真正看重的： Consistency vs. availability 的取舍。他们要你给明确答案，不喜欢“看情况”的打太极。 怎么处理 hot partition。自然会聊到 Redis sorted sets，但他们会追问：当某个游戏有 500k 并发玩家时怎么办。 读写比的推理。我说 leaderboard 展示是 20:1 的读多写少，他们看起来挺满意，因为我有理由，不是瞎猜。 故障模式：如果 cache 层挂了，游戏客户端怎么优雅降级。
没那么重要的： API 设计得完美。他们几乎没怎么碰 REST/gRPC 的问题。 精确到最后一个 TB 的容量计算。有理有据的粗估就够了。
我在一家小公司是 L5 对标（staff title，但按 headcount 调整）。他们在流程里定位我挺准确。有个我注意到的点：interviewer 提了好几次他们内部的分布式 key-value store。别慌，就算他们提到你不了解的内部系统也没关系。把它映射到一个等价的开源工具，然后说“我先假设语义类似 X”，继续往下就行。
整体氛围偏协作，不是找茬。我在持久化层卡了大概 90 秒，interviewer 给了个提示，也没有搞得很尴尬。
全流程是 phone screen、1 小时 coding、system design、两轮 behavioral。debrief call 一周内就来了。San Mateo 办公室，hybrid（这个岗位要求每周 3 天到岗）。