Role: Game Developer, real-time gamesFull interview loop
Four rounds for a game developer on a real-time game: a frame capture, a frame-rate bug, rubber-banding at 120 ms, and the crash list before submission.
4 rounds · 4 h
For a studio shipping a real-time game — action, shooter, sports, anything where a late frame or a late input is felt — on PC and consoles, with online play or with it on the roadmap. The loop hires a programmer who will work across gameplay and performance, the generalist a small or mid-sized team usually needs, rather than a rendering or engine specialist. There is no round on shaders, rendering techniques or engine architecture; a team hiring for those needs a different loop.
The rounds follow a feature outward from the frame. The technical interview starts inside one frame on the minimum-spec PC and ends in a meeting with the art lead about the last millisecond. The coding round is a dash a designer keeps retuning, correct at 60 frames a second and wrong at every other rate. The design round sends that kind of movement over a 120 ms connection where client and server each believe they are right. The incident review is the build three weeks before it goes to the platform holders, with a crash list that ranks the wrong way by count.
Frame budget and profiling is read in three rounds, because it is the competency easiest to talk about convincingly and hardest to fake with evidence on the table. Each read comes from a different side: a capture read cold, the cost of code the candidate has just written, and memory that runs out after two hours on a base console. Gameplay programming is read twice — a component with a designer's ticket, then an ability that has to be predicted across a network — and so is simulation and netcode, first as frame-rate independence inside one function and then as the same problem between two machines.
Two trade-offs are deliberate. Crashes and certification is a nice-to-have scored once, so the loop will prefer a candidate who reads a capture well and has never been through a console submission over one who knows the checklist and cannot find a hitch. Within six months of submission, make it a must and give it a second read — in the coding round, ask what the dash does when the console suspends halfway through it. Working with design and art is read once too, in the technical interview, because a frame budget is where disciplines disagree most concretely; a team whose programmers sit inside feature teams may want a second read. And the loop assumes online play. If your game has none, replace round three with a round of your own on replays or save and load rather than dropping it, since it also carries the second read of gameplay programming.
Rounds
Round 1 · 60 min
Technical InterviewScores Frame budget and profiling, Working with design and art
Round 2 · 60 min
Coding — the dash that changes with frame rateScores Gameplay programming, Simulation and netcode, Frame budget and profiling
Round 3 · 60 min
System design — prediction and reconciliation at 120 msScores Simulation and netcode, Gameplay programming
Round 4 · 60 min
Incident review — the crash list three weeks before submissionScores Crashes and certification, Frame budget and profiling
What each round scores
Every must-have is scored in at least two rounds, so no single interview decides it.
| Competency | Round 1 | Round 2 | Round 3 | Round 4 |
|---|---|---|---|---|
| Frame budget and profilingMust-have | Scored | Scored | Not scored | Scored |
| Gameplay programmingMust-have | Not scored | Scored | Scored | Not scored |
| Simulation and netcodeMust-have | Not scored | Scored | Scored | Not scored |
| Crashes and certificationNice-to-have | Not scored | Not scored | Not scored | Scored |
| Working with design and artNice-to-have | Scored | Not scored | Not scored | Not scored |