我职业生涯里面过两次 EA 的 senior engineer 全流程，不同 studio、不同团队，但 system design 这一轮的风格非常一致。写下来是因为网上的建议大多很泛，但 EA 的语境其实具体到会影响答题。
基本设置。 onsite 里有一轮 system design，60 分钟，1-2 位面试官。题目几乎总是和游戏相关，至少也是 live-service 相关。我见过或听过的常见题： 设计一个 live game 的玩家成长/XP 系统 设计一个多人游戏的通知/事件 fanout 系统 设计一个大规模 leaderboard service（这题很常见） 设计一个游戏 telemetry/analytics ingestion pipeline
你会发现规律：这些不是那种泛泛的「design Twitter（设计 Twitter）」或「design a URL shortener（设计一个短链接服务）」题。题目是贴着领域来的。你要知道游戏流量和一般 web app 的差异：上线和活动期间并发尖峰、写入 burst 很多、某些地方允许 eventual consistency（leaderboard 慢 30 秒也行），另一些地方必须强一致（玩家库存、购买）。
他们在 senior / L5 level 看什么。 这个级别 EA 期待你主导问题。不要等别人牵着走。快速澄清需求，明确说出约束，给方案，然后主动讲 tradeoff。他们在看你能不能自我组织，而不是需要手把手。
我在那边做 hiring loop 时看到的常见翻车点：候选人分布式系统很强，但把题当成白板练习而不是一个真实产品。「What would you do if player count 10x'd next month?（如果下个月玩家数暴涨 10 倍，你会怎么做？）」是一个真实业务场景，不是纯假设。要按业务场景来答。
期望的深度。 介于 breadth-first 和对某个组件深挖之间。先画整体架构，再深挖最高风险的组件。比如 leaderboard，就深挖写入路径和 Redis sorted set 方案。别花 15 分钟讲 auth，他们知道你会。
扣分点。 上来就说「我们用 Kafka」但解释不出为什么。不知道大概的 latency 数字或数量级估算。不知道什么时候 eventual consistency 可以接受、什么时候不行。
准备一套 Redis sorted set 的讲解和一个基础 event fanout 草图，基本能覆盖 senior 级别的大部分题。