Game Developer interview loops

A game developer — or game programmer, as many job ads put it — is hired to make a game behave the same way for every player on every machine it promises to run on. That is narrower and harder than knowing an engine. The frame has a fixed budget, 16.7 or 33.3 milliseconds on the weakest hardware the store page lists, and every system in the game draws from it. Gameplay has to act the same at 30 frames a second and at 144, and across a network where two machines disagree about the present. And the build has to survive hours of play, a suspended console and a platform's certification checks. The rounds below read those things, along with the designer-facing work that sits inside them.

Interviews for the role tend to go wrong in two ways. Engine questions reward whoever happens to use the interviewer's engine, and a candidate can explain a draw call or a quaternion without ever having found a hitch. Meanwhile the defects that decide whether a game ships depend on timing — a spike every six seconds, a dash that is shorter on a handheld, a correction that only appears at 120 ms, a crash after two hours — and none of them show up in a whiteboard answer. So each round works from something a studio's own tools produce whatever the engine: a profiler capture, a gameplay component with a test harness, a netlog, a crash triage pack. A candidate from Unity, Unreal or an in-house engine meets the same material, and nothing in the loop scores knowing one engine's API.

A loop is a set of round plans in order. Each round scores one to three competencies, every must-have is scored in at least two rounds, and the debrief is held competency by competency rather than round by round, so no single interview decides the hire. How these plans work covers the rest of the method.