Game Developer interview loops

A game developer, in the programming sense this page uses, is a game programmer: a software engineer who writes the code a video game is built from — the gameplay the player controls, the engine systems beneath it, the networking of an online game, and the tools designers and artists build the game with.

As of October 2026 the title covers several jobs, and none of the studio postings read for this page is titled game developer. A gameplay programmer builds what the player does: an Epic Games posting has its senior gameplay programmer working with designers, animators and artists on player mechanics, abilities, progression and vehicles, and chasing bugs in gameplay, performance, memory and networking (Epic Games). An engine programmer works beneath the gameplay: a Supercell posting has its senior engine programmer on the foundations of the company's own engine, which all its games run on — memory, threading, asset loading — and on the layer that hides the differences between iOS, Android, Windows and macOS (Supercell). A network programmer keeps players' machines in agreement: a Ubisoft posting for a network programming lead on Rainbow Six Siege covers replication, client prediction and reconciliation, lag compensation and dedicated servers (Ubisoft). Tools programming can sit under a different title: a Naughty Dog posting for a core tech programmer has the programmer building the tools and asset pipeline the studio's artists and designers use, and working with those artists and designers directly (Naughty Dog). On a game run as a live service the job continues after launch: a Scopely posting for the mobile game Monopoly GO! has its senior engineer owning features into live operation, working on the tools for running the game and on its content pipelines, and tracking down what goes wrong after release (Scopely). And at an independent studio one engineer may do several of these at once: a League of Geeks posting for a new PC and console project runs from gameplay code to how fast the game renders, and makes the same engineer responsible for profiling CPU and GPU work to find where the game hitches or runs over its budget, on PC and on console (League of Geeks). The loop below is written for a programmer who works across gameplay and performance on a real-time game for PC and consoles, with online play or with it planned, where a late frame or a late input is felt, rather than for an engine or rendering specialist, or for live operations on a mobile game.

This programmer's job is 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.

Whether a studio wants its programmers using AI tools and whether it allows them in the interview are separate questions. A Supercell engine posting open in October 2026 asks for someone who already uses AI tools in their daily work, and says nothing about AI in the interview (Supercell). Ubisoft's guidance for candidates welcomes AI tools for rehearsing beforehand, but keeps them out of interviews, and out of technical and coding tests unless a test allows them (Ubisoft, as of October 2026). None of the plans below says either way, and allowing an assistant would change what each of the four rounds measures. The technical interview hands its capture over at the start and credits a candidate who reads from it that the frame is waiting on the GPU, that the draw calls can wait and that the sixteen long frames come from three causes, all of which an assistant given the capture could read for them. The coding round lets the candidate look anything up without saying whether that includes an assistant; it credits defects found in the file before anyone points to them, and most of its hour is code the candidate writes, which would become code they direct and check. The system design round and the incident review send their packs 24 hours ahead, and neither pack says what in it matters: the design sheet describes inputs replayed at the wrong timestep without calling that a bug, and the crash list runs by report count, though its biggest bucket can wait and its smallest is the worst. An assistant given a pack overnight could do that reading. Each round also turns on a decision the candidate defends out loud: what to offer the art lead for the market's volumetric fog, what a designer may not tune, which parts of a new grapple ability can be predicted, what the submitted build leaves out. So decide before the loop starts, and tell the candidate which rounds, and which packs, an assistant may be used on.

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.

Further reading, as of October 2026. Glenn Fiedler's Fix Your Timestep! (Gaffer On Games, 2004) explains how a simulation stepped at a fixed rate catches up after a slow frame, and why capping the steps it may take in one frame trades a spiral of ever-longer frames for a moment of slow motion; the capture in the technical interview has physics taking extra steps in the frames after each hitch, and the plan credits the candidate who says why. The Game Loop chapter of Robert Nystrom's Game Programming Patterns, free to read on the web, follows a game loop from one that runs at the speed of the machine, through one that scales each update by the time elapsed and so lets two networked players, one on a fast machine and one on a slow one, disagree about where a bullet is, to one with a fixed update step; the dash in the coding round moves a fixed distance every frame, so it covers 3 m at 30 frames a second and about 14 m at 144, and the plan asks the candidate whether they would step it at a fixed rate. Gabriel Gambetta's Fast-Paced Multiplayer series takes client-side prediction and server reconciliation, entity interpolation and lag compensation in turn, and the system design round credits all of them in a single dash, from the button press to what the other five players see. Jason Gregory's Game Engine Architecture (fourth edition, CRC Press, 2026) has sections in its first volume on memory management, leak detection and in-game memory statistics, the subjects the incident review draws on when a 64 MB allocation fails on a base console two hours into a session with hundreds of megabytes still free.