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

  1. Round 1 · 60 min

    Technical Interview

    Scores Frame budget and profiling, Working with design and art

  2. Round 2 · 60 min

    Coding — the dash that changes with frame rate

    Scores Gameplay programming, Simulation and netcode, Frame budget and profiling

  3. Round 3 · 60 min

    System design — prediction and reconciliation at 120 ms

    Scores Simulation and netcode, Gameplay programming

  4. Round 4 · 60 min

    Incident review — the crash list three weeks before submission

    Scores 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.

CompetencyRound 1Round 2Round 3Round 4
Frame budget and profilingMust-haveScoredScoredNot scoredScored
Gameplay programmingMust-haveNot scoredScoredScoredNot scored
Simulation and netcodeMust-haveNot scoredScoredScoredNot scored
Crashes and certificationNice-to-haveNot scoredNot scoredNot scoredScored
Working with design and artNice-to-haveScoredNot scoredNot scoredNot scored

All Game Developer loops and round plans