Went through EA's senior engineer loop twice in my career, different studios, different teams, and the system design round has a pretty consistent flavor. Writing this up because the advice floating around is mostly generic and EA's context is actually specific enough to matter.
The setup. You get one system design round in the onsite, 60 minutes, one or two interviewers. The problem is almost always game-adjacent or at least live-service adjacent. Common prompts I've seen or heard about: Design a player progression/XP system for a live game Design a notification/event fanout system for a multiplayer title Design a leaderboard service at scale (this one comes up a lot) Design a game telemetry/analytics ingestion pipeline
Notice the pattern. These aren't generic "design Twitter" or "design a URL shortener" questions. They're anchored in the domain. You should know what makes game traffic patterns different from typical web apps: spiky concurrency around launches and events, lots of write bursts, need for eventual consistency in some places (fine if the leaderboard lags by 30s) and strong consistency in others (player inventory, purchases).
What they're evaluating at senior / L5 level. At this level EA expects you to drive the problem. Don't wait to be guided. Clarify requirements quickly, state your constraints out loud, propose a design, then proactively bring up tradeoffs. They're watching to see if you self-organize or need hand-holding.
A common failure mode I saw when I was on a hiring loop there: candidates who knew distributed systems cold but treated the problem as a whiteboard exercise rather than an actual product. "What would you do if player count 10x'd next month?" is a real business scenario, not a hypothetical. Treat it like one.
Depth they expect. Somewhere between breadth-first and a deep-dive into one component. Sketch the overall architecture, then go deep on the highest-risk component. For a leaderboard: go deep on the write path and the Redis sorted set approach. Skip spending 15 minutes on auth, they know you know that.
Things that hurt candidates. Jumping to "we'll use Kafka" without justifying why. Not knowing rough latency numbers or order-of-magnitude estimates. Not knowing when eventual consistency is acceptable vs. not.
Preparing a Redis sorted set walkthrough and a basic event fanout sketch will cover a large fraction of what they'll ask at the senior level.