Game Developer interview questionsTechnical Interview round

Purpose

Tells a candidate who prepared for engine trivia that the hour is about reading evidence, so the first minutes go into the page rather than into recalling definitions.

Purpose

Gives permission to read quietly, and says without pointing that some lines are fine — so setting the draw-call count aside is the candidate's call rather than the interviewer's.

Purpose

The separator is whether the candidate reads the wait. Every thread's work fits inside 16.7 ms except the GPU's, and the game thread spends a third of the frame waiting for it — so the largest CPU number on the page, animation, is the one that changes nothing today.

Signals to score

• Calls the frame GPU-bound from the 6.0 ms the game thread spends waiting, before proposing any change
• Says that cutting animation or AI time will not move the median until the GPU is under budget, and explains why
• Works out how much the GPU has to give back — at least 1.2 ms, and more as headroom for heavier moments — instead of "as much as possible"
• Goes through the GPU passes by cost with a mechanism for each: a coarser fog volume leaning on temporal reprojection, shorter or fewer shadow cascades, distant cascades updated less often, transparency at reduced resolution
• Places the 4,850 draw calls on the render thread, and notes that thread has headroom and is waiting as well
• Asks whether dynamic resolution ships on, and treats it as a floor under the frame rate rather than the fix
• Says what the development build and the markers add, and that they inflate CPU timings more than GPU ones
• Names the next limit once the GPU fits — the game thread at 12.1 ms with every NPC animated every frame — and what they would change there
• Checks the result with a second capture of the same scene on the same machine, not with a number from their own PC

Follow-up questions

• The game thread spends 6.0 ms doing nothing. What is it waiting for?
• Animation is the biggest number on the game thread. Halve it tomorrow — what happens to the median?
• 4,850 draw calls sounds like a lot. Is it your problem this week?
• How much does the GPU have to give back, and why not exactly 1.2 ms?
• Once the GPU is under budget, which thread do you expect to be the limit next?

Purpose

Turns the candidate toward the frames players feel without saying how many causes the table holds.

Purpose

Tests whether the candidate groups hitches by mechanism and thread rather than by size, and whether they know which hitches recur and which happen once a session.

Signals to score

• Sorts the sixteen into garbage collection and a blocking load on the game thread and pipeline state compilation on the render thread, and treats the slow physics frames after them as a consequence rather than a fourth cause
• Ties the five-to-six-second rhythm to 162 KB allocated per frame, and points at nameplate text and query lists rather than at the collector
• Removes the allocations — text rebuilt only when its value changes, query buffers reused — and treats an incremental collector as spreading the pause, not removing it
• Notices that `market_props` loads, unloads at 0:27 and loads again, and proposes loading it ahead of the market and holding it while the district is loaded
• Names pipeline states compiled on first use and proposes compiling them during loading from a list recorded in playtests
• Says the compile hitch is worst on a player's first session and that a warm driver cache hides it, so the reproduction clears the cache
• Explains the frames after each spike: the fixed-step accumulator owes the simulation the lost time, runs extra physics steps and makes the next frame long too; names the four-step cap and the slow motion it trades for
• Separates what recurs every few seconds from what happens once a session, and orders the work by what players feel
• Says what to capture next for each group — allocations with callstacks, a load log naming who requested the package, a list of states compiled at runtime

Follow-up questions

• Eleven spikes, five to six seconds apart. What sets that rhythm?
• Would switching on an incremental collector fix this?
• The same package loads twice in fifteen seconds. Why would it?
• You run the route again and the fountain hitch is gone. Fixed?
• Why are the frames right after a spike slow as well?

Purpose

Separates candidates who compare distributions across repeated runs on target hardware from candidates who quote one median, and asks for the gate that keeps a fix fixed.

Signals to score

• Captures on the minimum-spec machine in a build configuration close to shipping, not in the editor or on a workstation
• Repeats a scripted route several times and compares distributions — median, p99, frames over 33.3 ms — rather than one run's median
• States the run-to-run spread before calling a difference real
• Measures with the conditions players get: vsync and dynamic resolution as they ship, and a cleared shader cache for the first-session case
• Adds a long run for what a minute cannot show — memory over hours, collections growing more frequent as the heap fills
• Looks at frame pacing, the gaps between presented frames, and not only at average cost
• Turns the capture into per-system budgets for this scene, checked by an automated run on target hardware every night
• Says who hears about a failed nightly run and what happens to the change that caused it

Follow-up questions

• You measured 16.2 ms on your own PC. What does that tell me?
• One run, median 16.4 ms. Ship it?
• What would a two-hour run find that a one-minute run cannot?
• Who notices, three weeks from now, if someone adds a second fog volume to the market?

Purpose

Puts the remaining cost on work owned by two named disciplines, so the round cannot close on a purely technical answer.

Purpose

Reads collaboration over a budget. The strongest candidates arrive with options priced in milliseconds and pictures, ask what a feature is for before proposing a cheaper version of it, and leave with an agreed number rather than a cut.

Signals to score

• Brings the costs in a form both people can use — milliseconds per feature on the minimum-spec machine, and screenshots of cheaper versions taken on that machine
• Asks what the fog does for the market before proposing how to make it cheaper
• Asks the designer what the finale needs from 180 NPCs, and whether the ones far from the camera need to be full characters
• Offers priced options: a coarser fog volume, fog tuned for the Medium preset, distant NPCs animated less often or drawn as impostors, nameplates only within range
• Does not quietly downgrade either feature, and does not pass the decision up without options
• Proposes a written budget for the scene that both agree to and the nightly capture enforces
• Says who decides if neither person will move, and what they bring to that person

Follow-up questions

• The art lead says the fog is not negotiable. What next?
• Why not turn the fog down at the Medium preset and tell nobody?
• What does the designer need from the crowd, and how do you find out?
• Who makes the call if neither of them will move?