How the interviewer opens it
“Design a backend for a real-time multiplayer game. Players join matches, send actions, and see the game state change. Keep play responsive and fair when connections have delays or fail.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Game rules
- Scale
- Match entry
- Read:write mix
- Message sizes
- Latency and network quality
- Authority and availability
- Disconnects
- Durability
- Client platform and exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Create or join a match in a suitable region
- Accept player actions and share authoritative game state
- Enforce legal actions and fair hit decisions
- Support reconnects and store final match results
Usually out of scope
- Chat and voice
- Skill-based match selection
- Physics engine implementation
- Seamless match recovery after a server failure
- Account service implementation
What interviewers ask about
- Where a match runs
- Every player must reach the same match owner. Server capacity depends on tick cost and network traffic, not only player count.
- Player actions under delay
- Players need immediate feedback, but the server must decide valid state. Lost or late packets must not delay newer useful state.
- Fair hit decisions
- Players see different versions of the same moment. Unlimited correction for delay gives slow or dishonest clients an unfair advantage.
- Disconnects and match completion
- A reconnect can overlap an old connection. A lost result response can cause retries after the match already ends.
Common mistakes
- Treats live play as ordinary database reads and writes.
- Trusts client positions, hit reports, or timestamps.
- Ignores the difference between local feedback and server confirmation.
- Promises fair play across all delays without a limit on late actions.
- Provides reconnect support without a deadline, neutral input, or rejection of the old connection.
- Adds seamless failover before defining ownership, tick budgets, and result durability.
The bar by level
- Senior (L5/E5)
- Separates session control from live play. Explains prediction, reconciliation, packet loss, bounded hit correction, connection replacement, and idempotent results. Applies the latency target to eligible players.
- Staff (L6+/E6+)
- Defines ownership during partitions and server updates. Derives capacity from tick cost and bandwidth. Chooses explicit fairness limits and overload behavior. Explains the cost of seamless recovery.