Opens this plan in Hirezen, where one click makes it a position.
Game Developer interview questionsIncident review — the crash list three weeks before submission round
A 60 min interview plan with a time-boxed script, what each question is for, and the signals to score against. Key skills: Crash triage and console certification before a release: ranking crash buckets by players affected and severity rather than by report count, telling a memory leak from fragmentation in a long session on base hardware, making saves survive suspend and power loss, and deciding with one other engineer what the submitted build fixes and what it does not..
Rank the buckets
What this section is for
Purpose
Runs over a three-page triage pack sent 24 hours ahead, for build 0.9.412 of a game shipping on PC and consoles, three weeks before its first console submission. Page one lists crash buckets from seven days of QA, a closed PC playtest and console soak rigs, each with reports, distinct machines and the top of the callstack. Write them to this composition: (1) 1,380 reports from 9 machines — the audio assertion `voiceCount < 256` firing during an automated rapid level-reload test; assertions are compiled out of shipping builds, where the voice pool steals its oldest voice instead; (2) 212 reports from 188 machines — an access violation in `PlayerHUD::OnInventoryChanged`, reached through the event dispatcher, after a player quits to the main menu and starts another session; (3) 96 reports from 94 base-model console dev kits — out of memory: a 64 MB allocation failed while the texture streaming pool tried to grow, in sessions between 2 h 05 min and 3 h 40 min long; (4) 41 reports from 39 PCs — GPU device removed, with 37 of the 39 on one graphics driver version; (5) 17 reports from 17 consoles — a crash on resume from suspend, in the online session code, using a session handle the platform invalidated during suspend; (6) 6 reports from 6 PCs — a stack overflow in the save-file parser at boot, every one from a player who kept a save from the previous playtest build, and each of those players crashes again on every launch. Page two is the internal pre-certification checklist QA ran against the platform requirements, with three failures: suspending the console during a save and resuming leaves a save the game reports as corrupt; signing the active user out during gameplay leaves the game running with no user; disconnecting the controller during gameplay neither pauses nor prompts. Everything else on the checklist passes. Page three is memory telemetry from three of the crashed sessions: after the first level load, 620 MB free with a largest free block of 540 MB; total free memory falls by about 110 MB an hour; the largest free block falls faster and is under 64 MB by the two-hour mark while about 400 MB is still free; at the crash, between 217 and 391 MB is free. Bucket 1 leads by count and is the red herring for this deadline; bucket 6 is the smallest and the worst. Put 70 minutes in the diary; the questions at the end are extra to the 60.
I'm [YOUR_NAME], and I look after stability and release at [COMPANY_NAME]. For this hour you're one of two engineers who own this crash list, three weeks before we submit to the console platforms. You've had the pack since yesterday.
What this section is for
Purpose
Makes the candidate an owner of the list rather than a reviewer of someone else's, so every answer is a decision with a deadline attached.
We'll rank the list, go deep on one bucket, then decide what goes into the build we submit. There's no single right order here, but there are wrong ones.
What this section is for
Purpose
Lays out the hour so the candidate can pace their answers, and signals that the ranking will be judged on its reasons rather than matched against a key.
Rank these six for the next three weeks. For each one, tell me what the report already tells you, what you still need to know, and who it hurts when the game ships.
What this question is for, and what to listen for
Purpose
The separator is whether the candidate ranks by players and severity rather than by report count, and whether they read distinct machines beside reports before anything else.
Signals to score
- Reads distinct machines beside reports first, and sees that bucket 1 is nine rigs relaunching in a loop
- Checks bucket 1 against the shipping configuration — an assertion compiled out — and files the voice leak without putting it at the top
- Ranks bucket 6 at or near the top despite six reports, because a crash on every launch locks that player out of the game and every player with an old save meets it
- Ranks bucket 2 high because 188 machines means ordinary play, and names the likely cause: a destroyed HUD still subscribed to inventory events
- Treats bucket 5 as a submission blocker whatever its count, because resuming from suspend is something the platform checks
- Treats bucket 4 as a driver fault to confirm, work around or warn about, and to report to the vendor, rather than as the team's own bug
- Treats bucket 3 as a memory problem on base hardware that needs allocation data over the session, not a larger pool
- Asks for what the reports lack — symbols, the build behind each report, full memory dumps for bucket 3, how many testers kept old saves
- Says what fixed will mean for each bucket in the next build — absent over a stated number of sessions or soak hours, not one clean run
Follow-up questions
- Bucket 1 has more reports than the other five together. Why isn't it first?
- Six reports. Why would bucket 6 get your time this week?
- What does 188 machines tell you that 212 reports doesn't?
- Is bucket 4 your bug?
- How will you know bucket 2 is fixed?
Out of memory at two hours
What this section is for
Purpose
One bucket in depth. Memory on fixed hardware is part of the frame budget that only fails late, so this section reads whether the candidate can tell a leak from fragmentation and refuses to wait two hours for every attempt.
Bucket 3. Page three has the memory telemetry from three of those sessions.
What this section is for
Purpose
Points at the telemetry without interpreting it, so reading total free memory against the largest free block is the candidate's move.
The allocation that failed was 64 MB, with between 217 and 391 MB free. Tell me what is happening to memory in these sessions, how you would find the cause before submission without waiting two hours per attempt, and what you would change.
What this question is for, and what to listen for
Purpose
Tests memory work on base hardware: reading two curves that fail for different reasons, making a slow failure fast to reproduce, and changing the allocation pattern rather than the size of the pool that happened to fail.
Signals to score
- Says two things are happening: total free memory falling about 110 MB an hour, which is growth or a leak, and the largest free block falling faster, which is fragmentation
- Explains how a 64 MB request fails with hundreds of megabytes free
- Asks whether the streaming pool needs to grow at runtime at all, and proposes reserving it at its budgeted size once, early, while a large contiguous block exists
- Proposes snapshots of live allocations with callstacks at intervals, diffed by category between the first hour and the second, to find what grows
- Makes the failure fast: a soak script that loops level loads and returns to the menu, or a debug option that holds back memory so the ceiling arrives early
- Raises bucket 2's destroyed-but-subscribed HUD as something that may keep objects alive on every return to the menu, as a hypothesis with a test rather than a conclusion
- Separates long-lived allocations from transient ones — separate heaps or pools, fixed-size blocks for small objects — so churn cannot break up the space large blocks need
- Sets a memory budget per category on the base console, enforced by a soak run that fails when a category exceeds it
- Confirms the fix with sessions longer than the longest crash, several times over, not one short run
Follow-up questions
- There are 300 MB free and a 64 MB allocation fails. How?
- Does this pool need to grow while the game is running?
- How do you make a two-hour crash happen in ten minutes?
- Could bucket 2 be part of this?
- How long does the confirming soak run, and why that long?
What goes into the submitted build
What this section is for
Purpose
The decision. Capacity and the date are fixed, so the answer has to include what will not be done — and the section reads whether the candidate says so early, in writing, to the person who owns the date.
Three weeks. You and one other engineer own this list; everyone else is finishing content. The submission slot is already booked.
What this section is for
Purpose
Makes capacity and the deadline concrete, so a plan that fixes everything is visibly not a plan.
You have the three pre-check failures and the six buckets you ranked. Tell me what the build you submit fixes, what it doesn't, how you will know the fixes hold, and who hears what from you this week.
What this question is for, and what to listen for
Purpose
Tests shipping judgment where platform requirements meet a crash list: which failures would most likely cost a resubmission, how a save survives suspend and power loss, and whether what will not be done is said out loud before the last week.
Signals to score
- Puts the three pre-check failures and the resume crash in the submitted build, because a failed submission costs a whole cycle the date cannot absorb
- Makes saving atomic — write the new save separately and replace the old one only once the write is complete and verified, or use the platform's transactional save — and keeps the previous save as a fallback
- Handles sign-out by returning to the title screen or the platform's user prompt, and pauses with a prompt on controller disconnect, tested on every screen including loading and menus
- Includes the old-save boot crash and the HUD crash, each with a test that runs on every build
- Takes the memory fix that can be proved in time — the reserved pool — and states plainly how long a session can run if the leak is still open
- Writes down the audio assertion and the driver crash as known and deferred, with the driver crash sent to the vendor
- Names exit criteria: the pre-certification checklist re-run on the final candidate build, soak runs on base consoles, fixed buckets absent across a stated number of sessions
- Tells the producer this week, in writing, what will be fixed, what will not, and what would move the date
- Keeps the last days for re-checking a candidate build rather than for fixing, and says what gets cut if the first week slips
Follow-up questions
- Which of these would you still be fixing the night before submission?
- Power is lost halfway through writing a save. What does the player have after reboot?
- The user signs out on a loading screen. What does your fix do there?
- What do you tell the producer on Monday?
- Only one memory fix can make it in. Which one, and what do you say about the other?
That's the list. What would you like to ask me about how we ship — who runs pre-certification, how many submissions our last game needed, how we watched crashes after launch?
What this section is for
Purpose
Candidates who have been through a release ask about pre-certification and crash monitoring after launch; candidates who have not ask about the platforms' development kits. Naming the topics makes the choice the signal.
Before you go, one true thing: [name a current, unflattering fact about your own release process — a save system never tested against power loss, a crash reporter nobody triages weekly, a submission that failed on something already known]. It would be yours to help fix.
What this section is for
Purpose
Ends on a specific, true weakness, which is the strongest pitch to the candidate this round is for and a fair warning to one who is not. Check that it is still true before the interview.
Game Developer interviews — common questions
- Who is this Game Developer interview plan for?
- It is written for the interviewer, not the candidate: the hiring manager, engineer or panel member running the Incident review — the crash list three weeks before submission round for a Game Developer role. It gives you a 60 min script to follow in the conversation — 3 questions with what each one is for and the signals to score against — so you are not writing the round from scratch the night before.
- What does the Incident review — the crash list three weeks before submission round assess?
- This round is focused on: Crash triage and console certification before a release: ranking crash buckets by players affected and severity rather than by report count, telling a memory leak from fragmentation in a long session on base hardware, making saves survive suspend and power loss, and deciding with one other engineer what the submitted build fixes and what it does not.. It works through Rank the buckets, Out of memory at two hours and What goes into the submitted build, scoring against 27 observable signals, with follow-up prompts on all 3 questions for going deeper where an answer is thin.
- How is the 60 min split up?
- Rank the buckets (20 min), Out of memory at two hours (18 min), What goes into the submitted build (22 min). The timings are there so the round stays on schedule and every candidate gets the same shape of interview — which is what makes two candidates comparable afterwards.
- What other rounds should I run for a Game Developer?
A single round does not cover a whole role. The other rounds in this library for a Game Developer: