Interview Prep & Question Bank

The pattern they want: safety before cleverness. A strong answer does a dry run first - walk with pathlib, build old->new pairs, print the plan, check for collisions (two files mapping to the same new name), then rename with a log file so it's reversible. Bonus points for asking what the target convention is and whether anything references these files by path (materials will break). The worst answer is a one-liner that renames on the first pass - it says you've never destroyed an asset library. People who have destroyed one always dry-run.

The pattern: ground it in an asset problem, not textbook definitions. "A list is ordered stuff, a dict is lookup by key - the moment it mattered was when my validator went from checking 100 assets to 10,000: finding an asset's metadata in a list is a linear scan, in a dict it's instant." An interviewer hearing O(n)-vs-O(1) expressed through an actual scaling story checks two boxes at once. See Data Structures.

The pattern: reproduce, don't speculate. Get the traceback (and if there isn't one, add logging so there is). The classic causes list itself: hardcoded paths, different DCC/Python version, missing module, locale/encoding, and the artist doing something wonderful you never imagined - which, a strong candidate notes, is data, not user error. Mentioning you'd fix the crash and add the guard rail that makes it impossible shows tool-owner thinking rather than script-writer thinking.

The pattern: artist empathy first, API second. Artists trust tools exactly until the first time ctrl+Z doesn't work; one broken undo and your tool is "that thing that ate my scene." In Maya: wrap the operation in an undo chunk (cmds.undoInfo(openChunk=True) / closeChunk in a try/finally, or a context manager) so the whole tool action reverts as one step. Knowing that it must be try/finally - so a mid-operation crash doesn't leave the chunk open - is the senior-flavored detail.

The pattern: tools have costs - writing, documenting, maintaining, supporting. Strong answer includes some form of the arithmetic: a task done twice a year by one person for ten minutes never pays back automation; a daily 5-minute task done by eight artists pays back in a week. Also strong: "when the real fix is upstream" - a tool that patches around a broken process cements the broken process. This question separates people who love writing tools from people who love solving problems; studios want the second kind.

The pattern: "how aligned two directions are" - then immediately cash it in with uses: facing checks (is the enemy in front of me: dot(forward, toTarget) > 0), Lambert lighting (dot(N, L) is literally diffuse shading), fresnel-ish edge masks (1 - dot(N, V)), and culling. Values: 1 = same direction, 0 = perpendicular, -1 = opposite. Nobody cares if you can recite the cosine formula; everyone cares that you know it's the "how much does this face that" function. Our TA math cheat sheet covers the whole family.

The pattern: it falls straight out of the dot product - normalize both vectors, take their dot, and acos the result: theta = acos(dot(normalize(a), normalize(b))). The honest follow-up that scores points: most of the time you don't actually want the angle, you want the dot itself - it's cheaper and it's already what feeds lighting and facing checks - so only reach for acos when you genuinely need degrees, like a spotlight cone or clamping a joint's twist. Two gotchas worth saying out loud: clamp the dot to [-1, 1] before acos, or floating-point drift a hair past 1.0 hands you a NaN; and acos only gives the unsigned 0-180 angle - if you need to know which way to rotate, use atan2(length(cross(a,b)), dot(a,b)) with a reference axis in 3D, or atan2(cross, dot) in 2D, which is also better-behaved right near 0 and 180 where acos gets numerically mushy. The TA math cheat sheet has the rest of the family.

The pattern: "give me two directions, I'll give you the perpendicular" - the make-me-an-axis function. Uses on tap: building a look-at basis (forward x up -> right), computing face normals from two edges, winding/side tests. Mentioning that order matters (axb = -bxa) and that this is why normals sometimes point the wrong way after mirroring is exactly the kind of production scar tissue interviewers listen for.

The pattern: this is a communication test wearing a math costume. Strong answer avoids the word "matrix" entirely: "Blender thinks 'up' is Z, the engine thinks forward is a different axis - the exporter has to translate between the two world views and it guessed wrong. It's a settings fix, not a you-problem - here's the export preset." Then, to the interviewer, briefly: axis conventions differ per package (Z-up vs Y-up, left- vs right-handed) and the fix belongs in a shared export preset so no artist ever thinks about it again. See Units & Axes.

The pattern: length 1, direction preserved - and we care because half the useful math (dot for angles, direction comparisons, stable interpolation) silently assumes unit length and gives garbage otherwise. The production example that lands: lighting that subtly breaks after non-uniform scaling, because the normals scaled too and nobody renormalized. "Normalize before you trust a direction" is a fine motto to say out loud.

The pattern: decompose into scatter -> orient -> vary. Scatter with jittered or blue-noise distribution (pure random clumps - mention it and win a point), raycast down to find the surface, orient to the hit normal (align the rock's up to it - quaternion from-to, or slerp partway so cliff rocks don't glue to the wall), then vary scale/rotation with a seeded random so it's art-directable and reproducible. Saying "seeded, so the art director can reroll until they like it" demonstrates you've met an art director.

The pattern: the elevator version, told with confidence: vertices get transformed by the vertex shader (object -> world -> view -> clip space), hardware rasterizes triangles into fragments, the pixel shader computes each fragment's color, depth testing decides who wins, blending composites the rest. Depth of detail should match the role - a shader TA should be comfortable adding where tangent space, interpolators, and early-Z fit; a generalist just needs the stages in order and where "my shader" plugs in (usually: the pixel shader).

The pattern: answer it in three beats: rasterization turns screen-space triangles into pixel fragments, it interpolates vertex data like UVs and normals for the pixel shader, and it is fast because GPUs are built around asking "which pixels does this triangle cover?" rather than ray tracing's "which triangle does this pixel hit?" Add one practical detail if needed: this is where aliasing shows up, and tiny triangles can be wasteful because the hardware shades in pixel quads. That is enough to sound grounded; if they push, talk MSAA/TAA, LODs, and Nanite. See Performance for where that bites in practice.

The pattern: instant diagnosis - green channel convention. OpenGL-style (Y+) vs DirectX-style (Y-) normal maps differ only in which way green points; use the wrong one and bumps become dents under lighting. Fixes: flip green on import (Unreal has a checkbox) or re-export in the right convention. Extra credit: sRGB must be OFF on normal maps (it's data, not color) - the two issues travel together and both are worth checking. Our PBR Map Generator has a lit material preview for exactly this.

The pattern: master material + instances, and the reasoning why: instances share the compiled shader, so you get 30 looks for one permutation's compile cost and far cheaper switching. Design the master's parameters like a product (few, named for artists, sensible ranges), resist the everything-material that grows 40 switches - each static switch multiplies permutations. This question is really "do you understand shader permutation cost and artist UX at the same time," which is the shader-TA job in one sentence.

The pattern: shading the same pixel multiple times - and the canonical crime scene is transparent stuff: particles, foliage cards, UI. The story version wins: "someone's smoke effect was 12 huge overlapping billboards; the GPU shaded every screen pixel 12 times and the frame died. Fix: fewer/smaller cards, tighter geometry around the visible puff, cutout instead of translucency where possible." Knowing view-mode tools exist (Unreal's Shader Complexity view) shows you debug with instruments, not vibes.

The pattern: color textures are stored gamma-encoded (sRGB) so precision goes where eyes look; math must happen in linear. The bug: data textures (roughness, masks, normal maps) imported with sRGB on get silently gamma-shifted - your 0.5 roughness isn't 0.5 anymore. Rule of thumb worth saying verbatim: "if it's color, sRGB on; if it's numbers, sRGB off." This is among the most common real-world TA bugs, and interviewers ask it because candidates who've actually shipped textures answer in one breath.

The pattern: conventions fail socially, not technically - so a strong answer spends as much time on adoption as format. Format: type prefix, name, variant, suffix (SM_Rock_Mossy_01), sortable, regex-validatable, no spaces or case-sensitivity landmines. Adoption: document it where people look, validate it at the door (pre-submit hook - nobody reads docs, everyone reads error messages), and never rename retroactively without handling references. Mentioning that you'd generate the regex once and wire it into a pre-submit validator - so enforcement is automatic, not a code-review chore - is the whole point.

The pattern: triage order - calm the artist ("we can get yesterday's version back" is sentence one), recover from version control (this is why the studio uses it; see Version Control for TAs), then investigate cause: crashed save? disk full? plugin writing garbage? two people editing the same binary file? A senior-flavored close: whatever the cause, the follow-up is a guard rail - autosave settings, exclusive checkout on binaries, or a validation step - so this category of morning never happens again.

The pattern: artists route around tools that are slower than the manual way, that fail without explaining themselves, or that break undo. Good tools: one obvious button, defaults that match the 90% case, errors written in artist ("this mesh has no UVs - unwrap it first" not IndexError), undoable, and fast enough to feel free. The meta-answer that lands: "I watch someone use it without me talking. Wherever they hesitate, that's my bug."

The pattern: pilot with one friendly team, keep the old path working during transition, write the two-line "what changed and why you'll like it" message, announce the date, be extremely present the first week. Never break workflows silently on a Friday. This question is asked because everyone senior has a story about the time somebody (possibly themselves) did exactly that; if you have the story, tell it - postmortem honesty is senior signal.

The pattern: measure before touching anything. First question: CPU-bound or GPU-bound? (stat unit in Unreal - game/draw/GPU times point at the culprit.) Then bisect: what changed this week - new content drop, new feature, new level chunk? Version control history is a profiler too. Then the appropriate deep tool (GPU profiler, Insights). The anti-pattern the interviewer is screening for: "I'd reduce the texture sizes" - an answer chosen before the question (what's slow?) was asked. Our profiling guide is this answer, long form.

The pattern: a draw call is the CPU telling the GPU "draw this thing with this state" - and each one carries CPU overhead: state setup, validation, submission. 5,000 of them can leave the GPU idle while the CPU queues paperwork. Remedies, in TA-actionable order: instancing (same mesh many times -> one call), merging materials/atlasing (fewer state changes), HLODs/culling (draw less). Knowing that materials multiply draw calls per mesh section is the practical detail that shows engine time.

The pattern: nuance over cheerleading. Yes-and: Nanite changes the budget conversation for opaque static meshes, but masked/translucent materials, skeletal meshes (mostly), and lower-end platforms still live in LOD land; and Nanite has its own costs (disk, streaming, overdraw behaviors). The senior signal is treating any engine feature as a trade-off with a domain of applicability, not a religion. "It depends, and here's what it depends on" - then actually listing the dependencies - is the whole game.

The pattern: this is the job. Strong answers show translation, not victory: you dug for what each side actually needed (artist: iteration speed; engineer: memory ceiling), found the both-ways option (streaming, budgets per biome, a preview mode), and - crucially - neither side "lost." If your story ends "and so the engineer gave in," you told a war story when they asked for a peace story. Prepare one real example before every interview; this question appears in some costume every single time.

The pattern: blameless-postmortem structure, applied to yourself: what happened, impact, root cause, the fix, the guard rail. No deflection ("QA should have caught it") and no self-flagellation either - just ownership plus systems thinking. If you're junior and have no such story, say so and describe what you'd do; but honestly, if you've written tools, you have the story. Everyone has the story.

The pattern: never a bare no - a costed yes. "We can do that; it costs X days and it bumps Y. Or here's 80% of the effect for 20% of the cost - want to see both?" ADs live in trade-offs all day; give them the trade-off and let them decide with real numbers. The candidates who fail this question describe either capitulation or confrontation. The job is the third thing: translation with a price tag.

The pattern: learn before fixing. Ship something tiny in week one (environment proof-of-life), map the pipeline as it is - including the weird parts, which are weird for reasons - and interview the artists about their most annoying daily task. The answer interviewers dread: "I'd start modernizing the pipeline." The pipeline you're about to modernize was built under constraints you haven't met yet. Our Studio Survival guide is the long version.