Engineering IC interview prep.

A game programmer is judged on real-time engineering (frame-budget discipline, memory + cache literacy, threading), engine depth (C++ + engine subsystems + the game loop), specialty fluency (graphics / networking / gameplay / tools / AI), and shipped-title ownership (the feature owned through...

What interviewers look for

  • Can the candidate run a real-time systems-design loop end-to-end: state the frame budget, define data layout + memory plan, pick the threading model, deep-dive a bottleneck - not just describe the high-level system?
  • Do they speak C++ + memory + cache fluently - move semantics, allocators, AoS vs SoA, false sharing, branch prediction - not just 'use std::vector'?
  • Can they debug under real-time pressure: profile, identify CPU-bound vs GPU-bound vs memory-bound, hypothesise + validate, fix without regressing other systems - not retreat into theory?
  • Do they have specialty depth (graphics: GPU pipeline, deferred vs forward, shadows; networking: server-auth + client prediction + lag comp; gameplay: state machines + AI + physics) and know the tradeoffs?
  • Are they shipped-title aware - cert process, day-zero patches, live-ops, postmortem culture - not just 'I built a feature in a tech demo'?
  • Do they collaborate cross-discipline (design, art, audio, production) and respect the tradeoffs - or push pure-engineer purity at the cost of the game?

Behavioural questions to expect

  1. Walk me through your CV.

    What it tests: Story coherence + genuine fit for a gaming-studio engineering seat. Teams want evidence of shipped game work (or strong demo / mod / jam work), C++ + real-time discipline, and specialty signal - not generic SWE 'I want to make games'.

  2. Tell me about your most technically impactful project on a game.

    What it tests: Depth of engineering ownership + real-time discipline. Tests whether the candidate frames problem -> design (with tradeoffs) -> deep technical work (measured, profiled) -> shipped outcome - not just 'we made a cool demo'.

  3. Tell me about a weakness, a failure, or feedback you've received and worked on.

    What it tests: Self-awareness + engineering discipline. Cross-role canonical. Game engineering mistakes (a shipped stutter, a memory leak that hit cert, an over-engineered system designers couldn't tune) shape teams + games.

  4. Why gaming engineering - and why this firm's studio vs another game studio or non-game tech?

    What it tests: Authentic fit for the real-time + creative-collaboration + shipped-title engineering seat. Tests whether the candidate has a real reason to be in games specifically - frame budget, engine craft, working with designers + artists - not 'tech jobs are tight + games are fun'.

  5. Which engineering area would you want to focus on, and why?

    What it tests: Genuine fit + grasp of how game engineering sub-specialties differ (gameplay / engine / graphics / networking / tools / AI / audio / animation). Tests whether the candidate has a reasoned preference.

  6. Why this firm?

    What it tests: Whether the candidate has done the homework. Bar: studio-specific evidence from titles, engine, tech blog, GDC talks, postmortems, and people - not generic 'cool studio'.

  7. How would you describe this firm's engineering organisation + tech stack in your own words?

    What it tests: Whether the candidate has internalized HOW the studio builds + ships games - engine, platforms, team shape, live-ops posture, profiling + cert culture.

  8. How does engineering actually drive value at a game studio like this firm?

    What it tests: Whether the candidate understands game-studio engineering economics: engine + tools leverage every artist + designer + animator on the team; perf + reliability protect player experience + reviews; live-ops engineering compounds revenue + retention; bad engineering compounds cost across the whole studio.

Technical concepts to master

C++ + memory + cache + data-oriented design

AoS vs SoA (array of structs vs struct of arrays)
AoS groups fields of one entity together (cache-friendly when accessing all fields); SoA groups one field across all entities (cache-friendly when iterating one field over many entities).
Custom allocators (pool / arena / stack / linear)
Pool: fixed-size blocks, free in any order. Arena / stack: bump-pointer allocate, free all at once (per-frame). Linear: simplest; no individual free.
Move semantics + RAII + value types
Move avoids copies for transferable resources; RAII ties lifetime to scope; prefer value types + small-buffer optimisation over heap allocation.
False sharing + cache lines
When two threads write to different fields on the same cache line, the line ping-pongs between cores - massive slowdown despite no logical contention.

Engine architecture + game loop + threading

The game loop - fixed vs variable timestep
Variable: simulate with last frame's dt - simple, but physics + networking break at variable rates. Fixed: simulate in fixed dt (e.g. 60Hz) with interpolation for render - canonical for physics + multiplayer.
Threading model - main + render + job system
Main thread runs gameplay + AI tick; render thread issues GPU commands; job system fans out per-frame work (animation, physics, particle) and joins before render.
ECS (entity-component-system)
Entities are IDs; components are pure data; systems iterate components and apply transforms. Cache-friendly + parallelisable + composable.
Asset streaming + memory budgeting
Stream assets in / out by zone / distance to fit memory budget; avoid hitches by streaming async + on dedicated thread, with priority + prefetch.

Graphics + GPU pipeline + rendering

GPU pipeline stages
Vertex shader -> tessellation (optional) -> geometry shader (optional) -> rasterisation -> fragment / pixel shader -> output merger; compute shaders run alongside for non-pixel work.
Deferred vs forward vs forward+ rendering
Forward: shade per object per light (cheap for few lights, transparency-friendly). Deferred: write geometry to G-buffer, shade with all lights in screen space (many lights cheap, transparency hard). Forward+: tile-based light culling, balances both.
Draw-call cost + batching + instancing
Each draw call has CPU + driver cost (~10-100 us); reduce via batching (combine static geometry) + instancing (one draw, many instances) + indirect draws.
Shadows + post-processing + temporal techniques
Cascaded shadow maps (open-world sun); shadow-map filtering (PCSS / VSM); post-process (tonemap, bloom, SSAO, motion blur); temporal AA + temporal upsample (TAA / TAAU / FSR / DLSS).

Networking + multiplayer + live-ops

Server-authoritative + client-side prediction + lag compensation
Server holds truth (cheat-resistant); client predicts locally for responsive feel; server reconciles + corrects; lag-comp rewinds for hit detection.
Deterministic lockstep + rollback
All clients simulate the same deterministic state given the same inputs; sync inputs only (tiny bandwidth); rollback + re-simulate on input arrival for fighting games.
Tick rate + bandwidth + delta encoding
Server tick rate (20-60 Hz typical) trades CPU + bandwidth for responsiveness; delta-encode state changes; prioritise + cull by interest / distance.
Live-ops + post-launch engineering
Patches + hotfixes + seasons + battle pass + back-compat with old clients + telemetry-driven balance tweaks; live-game eng is its own discipline.

Practical drills

  • You're building a 60fps third-person action game on console. Walk me through how you'd budget the 16.67 ms / frame across the major systems (gameplay, render, animation, physics, AI, audio, streaming) and identify where the perf risks live.
  • Design the netcode stack for a 32-player competitive shooter on console + PC, target 60fps client + 60Hz server tick. Walk me through it.
  • Overnight, a build dropped from a steady 60fps to 40fps on PS5. Walk me through how you'd diagnose + fix.

Smart-question anchors

  • Engine + platform - engine maturity, platform mix, where the tech is heading
  • Team + scope - team shape, what the role would own in 6-12 months, mentorship
  • Perf culture - profiling discipline, perf budget enforcement, CI perf testing, frame-rate hold history
  • Cross-discipline - working with design + art + animation + audio, decision-making process
  • Live-ops + cert - patch cadence, cert experience, hotfix mechanics, postmortem culture

Related roles

Sourced from

Ready to Generate Your Own Prep?

Drop your CV and a job description on the home page. A couple of minutes later you get a report with everything you need to land the job.

Generate my first prep