Opens this plan in Hirezen, where one click makes it a position.
Game Developer interview questionsSystem design — prediction and reconciliation at 120 ms round
A 60 min interview plan with a time-boxed script, what each question is for, and the signals to score against. Key skills: Multiplayer netcode design with client-side prediction and server reconciliation: reading a playtest netlog to tell rubber-banding from remote stutter, replaying inputs with the timestep they were simulated with, keeping cooldowns and stamina in the reconciled state, deciding what the server trusts and how hits are resolved, and structuring a new ability so it can be predicted..
Two complaints, one log
What this section is for
Purpose
Runs over a two-page pack sent 24 hours ahead: a design sheet for how movement and the dash are networked today, and a netlog summary from a playtest. Write both to this composition. The game is a 3v3 online arena on dedicated servers ticking at 30 Hz, with clients rendering at 60–144 fps; the dash covers 6 m in 0.2 s, has a 1.5 s cooldown and costs 25 stamina, and sprinting drains stamina. The design sheet, as numbered points: (1) every rendered frame the client sends its input with a sequence number and that frame's delta time, and the server moves the player by the delta the client sent; (2) the server applies inputs as they arrive and sends a snapshot 30 times a second carrying the player's position and the last input sequence it processed; (3) on each snapshot the client resets to the server's position and replays every input the server has not yet processed — deliberately correct in structure — but uses the current frame's delta time for every replayed input; (4) the client starts a dash the moment the button is pressed, and the server checks the cooldown against the arrival time of the previous dash input; stamina and cooldowns are not in the snapshot; (5) other players are drawn at their position in the newest snapshot as soon as it arrives; (6) the server resolves a dash-strike against targets' current server positions; (7) corrections under 10 cm are blended over 100 ms and larger ones snap — deliberately correct. The netlog summary covers ten minutes at a simulated 120 ms round trip with ±20 ms jitter and 1% packet loss: local-player corrections per minute while walking 0.6 (median 3 cm), while sprinting 1.4 (median 9 cm), and during or within a second after a dash 41 (median 0.7 m, largest 3.9 m); 212 dash attempts, 23 refused by the server as "cooldown not elapsed", every one within 60 ms of the client's cooldown ending; one annotated trace in which inputs simulated with deltas of 6.9, 7.0, 16.8 and 7.1 ms are replayed at 7.1 ms each; testers' notes reading "my character rubber-bands when I dash" and "other players stutter"; and 31% of dash-strikes that connected on the attacker's screen not registered by the server. The remote stutter is a real bug and the red herring for the rubber-banding; the 30 Hz snapshot rate and the small-correction blend are fine. Allow 70 minutes in the calendar; the exchange at the end falls outside the 60.
I'm [YOUR_NAME], and I work on multiplayer at [COMPANY_NAME]. This is a design hour, and it starts from a playtest rather than a blank board — you've had the design sheet and the netlog since yesterday.
What this section is for
Purpose
Tells the candidate the design will be grounded in evidence they have already read, so the first answer is about the pack rather than a prepared architecture.
Treat the design sheet as what the code does today. When I ask you to redesign it later, you can change anything except the dedicated server and the snapshot rate.
What this section is for
Purpose
Fixes the constraints early, so nobody spends the hour buying a faster tick or a peer-to-peer model instead of designing within the game's real limits.
Testers have two complaints: their own character rubber-bands when they dash, and other players stutter. Tell me every cause you can find in this pack, which complaint each one explains, and what order you would fix them in.
What this question is for, and what to listen for
Purpose
Separates candidates who match causes to symptoms from candidates who recite netcode techniques. The two complaints have different causes, and the corrections that happen while merely walking are the clue most people skip.
Signals to score
- Separates the complaints at once: remote stutter is how other players are drawn; rubber-banding is the local prediction disagreeing with the server
- Reads the corrections while walking as proof the replay does not reproduce the server's movement, since the same inputs through the same code should agree to well under a centimetre
- Finds the replay applying the current frame's delta to every input, in the trace, and says the error grows with speed and with hitches
- Explains the 23 refused dashes: the cooldown is measured between arrival times that jitter, so a dash the client allowed arrives early, after the client has already moved for a round trip
- Names stamina and cooldowns missing from the snapshot, so resetting position leaves the client predicting from state the server never had
- Flags that the server moves players by a delta the client sends, as a cheating hole as well as a source of disagreement
- Explains the stutter as snapshots drawn the moment they arrive, with jitter and loss, and proposes drawing other players slightly in the past between snapshots
- Treats the 31% of unregistered strikes as a separate fairness problem — hits resolved against positions the attacker had not yet seen — not as part of the rubber-banding
- Keeps what is right: the reset-and-replay structure and the blend for small corrections
- Orders the fixes by what players feel and by which fixes the others depend on
Follow-up questions
- Walking corrections are 3 cm and nobody can see them. Why do they matter?
- Every refused dash came within 60 ms of the client's cooldown ending. What does that tell you?
- After a refused dash, what does the client believe about its stamina, and for how long?
- Will interpolating other players fix my rubber-banding?
- What could a modified client do with the delta time it sends?
One dash, from button to screen
What this section is for
Purpose
The design question. The candidate redesigns movement and the dash within the fixed constraints, and the section is scored on whether they can hold three clocks at once — the client's, the server's, and the past that other players are shown — and put trust where it belongs.
Now design it properly. Same dedicated server, same 30 snapshots a second, the same dash the designers wrote.
What this section is for
Purpose
Restates the constraints so the design stays about what is simulated where, not about the budget for servers.
Walk me through one dash on your design, from the button press to the moment the other five players see it, and at each step tell me what the server trusts, what the client predicts, and what happens when they disagree.
What this question is for, and what to listen for
Purpose
Tests the design at the level of timelines and state: when each input is simulated, what is restored on a correction, and who gets the benefit of the doubt when two screens disagree about a hit.
Signals to score
- Samples input into fixed simulation ticks with sequence numbers, so client and server run the same movement code with the same step
- Keeps the client ahead of the server by about half the round trip plus a small buffer, so inputs arrive before their tick, and says how that lead adjusts
- Buffers inputs on the server and repeats the last input when one is missing
- Measures the dash's cooldown and stamina cost in ticks of the input stream, so jitter cannot make a legal dash early
- Puts every piece of state that decides future movement — position, velocity, stamina, cooldowns, dash progress — into what the snapshot restores
- On a correction, restores that state at the acknowledged tick, replays unprocessed inputs, and hides small leftover error in a visual offset that decays, with the snap threshold stated
- Validates on the server without trusting client timing or position, and says what a refused dash looks like to the player
- Draws other players about 100 ms in the past between snapshots, and says what they see of the dash
- Resolves the dash-strike by rewinding targets to what the attacker saw, with a cap on how far back, and says who that is unfair to
- Names what the next playtest measures to show the design worked
Follow-up questions
- Where is the client in time compared to the server, and why there?
- An input packet is lost. What does the server do on that tick?
- What exactly do you restore before replaying?
- The attacker saw a hit; on the target's screen they had already dashed away. Who wins?
- How far back would you let the server rewind, and why stop there?
The grapple
What this section is for
Purpose
A new ability that moves another player — the one thing client prediction cannot own — so the question becomes how gameplay code is structured when two machines have to agree about it, and whether designers can build the next ability without a network programmer beside them.
Design has a new ability for one character: fire a hook, and if it catches an opposing player within 15 metres, pull them two metres toward you over a quarter of a second.
What this section is for
Purpose
Introduces the case where the caster's input changes someone else's movement, without saying what makes it hard.
Give me the shape of the grapple's code — the structure, not the maths — so it runs the same on client and server, predicts what it can, and lets a designer make the next ability like it without a network programmer.
What this question is for, and what to listen for
Purpose
Reads gameplay programming under network constraints: abilities as state and rules over ticks that both sides run, a clean line between what the caster can predict and what only the server decides, and a pattern designers can follow instead of a special case.
Signals to score
- Structures the ability as tick-driven state with explicit phases — fire, travel, attached, pull, recover — rather than timers and callbacks spread across frames
- Runs the same ability code on client and server, with the server deciding whether the hook caught anyone
- Predicts the caster's side — animation, the hook leaving, the cooldown — and waits for the server before moving another player
- Says the pulled player's client must replay with the pull in its state, or its own prediction fights the pull for a round trip
- Makes a wrong prediction look deliberate — the hook visibly misses or retracts — instead of a snap
- Keeps range, pull distance and pull time in data both sides load, and checks client and server have the same version
- Gives designers a pattern: which phases may be predicted, which need the server, and a rule that ability logic runs on ticks, never on rendered frames
- Tests the ability by feeding the same tick inputs to a simulated client and server and comparing state tick by tick
Follow-up questions
- Which part of the grapple can the caster's screen show before the server answers?
- On the target's screen they dashed out of range 80 ms ago. Does the hook catch them?
- What does the pulled player feel, and is it fair?
- Next month the designer wants an ability that swaps two players' positions. What does your structure make easy, and what does it forbid?
- How do you know the client and server loaded the same range?
Your questions now. Ask me anything about the networking in our game — why the tick rate is what it is, the last rubber-banding bug that reached players, who decides how much a hit favours the attacker.
What this section is for
Purpose
Candidates who have shipped online play ask about tick rates, trust and hit-resolution policy; candidates who have not ask which networking library is used. Naming the topics makes their choice the signal.
One honest thing before we finish: [name one true, current weakness in your own netcode — a value the server still trusts from the client, a correction rate nobody measures, an ability that only feels right on a local network]. That comes with the job.
What this section is for
Purpose
A true and specific admission is the pitch that works on the candidate this round is meant to find, and it deters one who wanted the netcode finished. Make sure it is still true.
Game Developer interviews — common questions
- Who is this Game Developer interview plan for?
- It is written for the interviewer, not the candidate: the hiring manager, engineer or panel member running the System design — prediction and reconciliation at 120 ms round for a Game Developer role. It gives you a 60 min script to follow in the conversation — 3 questions with what each one is for and the signals to score against — so you are not writing the round from scratch the night before.
- What does the System design — prediction and reconciliation at 120 ms round assess?
- This round is focused on: Multiplayer netcode design with client-side prediction and server reconciliation: reading a playtest netlog to tell rubber-banding from remote stutter, replaying inputs with the timestep they were simulated with, keeping cooldowns and stamina in the reconciled state, deciding what the server trusts and how hits are resolved, and structuring a new ability so it can be predicted.. It works through Two complaints, one log, One dash, from button to screen and The grapple, scoring against 28 observable signals, with follow-up prompts on all 3 questions for going deeper where an answer is thin.
- How is the 60 min split up?
- Two complaints, one log (20 min), One dash, from button to screen (22 min), The grapple (18 min). The timings are there so the round stays on schedule and every candidate gets the same shape of interview — which is what makes two candidates comparable afterwards.
- What other rounds should I run for a Game Developer?
A single round does not cover a whole role. The other rounds in this library for a Game Developer: