Interview Prep & Question Bank

Start by asking for the target naming convention and checking whether other assets reference these files by path. Use pathlib to build a rename plan, print a dry run, and check for name collisions before changing anything. Keep a log so changes can be reviewed and reversed. The useful part of the answer is explaining how you'll protect the existing asset library.

Explain the difference through a task you've worked on. A list keeps a sequence of items; a dictionary lets you look up a value by key. For example, repeatedly finding metadata for 10,000 assets can be much cheaper with dictionary lookups than list scans. Dictionary lookup is typically O(1), rather than literally instant. See Data Structures.

Get the traceback and reproduce the problem with the artist's inputs. Check paths, DCC and Python versions, dependencies, and encoding. Watch how they run the tool as well; an unexpected workflow is useful evidence. Once you've fixed the cause, add a check or test for that case.

Undo lets an artist try the tool without losing control of the scene. In Maya, group undoable operations with cmds.undoInfo(openChunk=True) and close the chunk in a finally block or context manager. Test both the successful path and an error halfway through, so a failure doesn't leave the chunk open.

Compare the time saved with the cost of building, documenting, and supporting the tool. A five-minute daily task across eight artists may justify automation; an occasional task may not. Also check whether the real problem is earlier in the pipeline. Fixing that can be more useful than adding another workaround.

For unit vectors, the dot product tells you how closely two directions align: 1 is the same direction, 0 is perpendicular, and -1 is opposite. Give a practical use, such as a facing check, diffuse lighting, or an edge mask. Explain any normalisation assumptions. The TA maths cheat sheet covers related examples.

The cross product of two non-parallel directions gives a vector perpendicular to both. You can use it to build an orientation basis or calculate a face normal from two edges. Order matters: swapping the inputs reverses the result. That's a useful detail when diagnosing winding or orientation problems.

Start with the visible problem: the DCC and engine may use different axis conventions, and the export settings need to account for that. Check the source orientation, export preset, and import settings together. Once you've found the mismatch, save a shared preset and test it with a simple reference object. See Units & Axes.

A normalised vector has length 1 and keeps its direction. Many lighting and angle calculations assume this, so an unexpected length can change the result. Non-uniform scale is a useful example: normals need the correct transform and normalisation before you use them for lighting.

Break it into placement, orientation, and variation. Choose a distribution that suits the art direction, raycast to the terrain, then align each rock with the surface normal. Add controlled scale and rotation variation. Use a seed so you can reproduce a layout, and expose enough controls for an artist to adjust it.

Walk through the main stages: vertex transformation, rasterisation, fragment or pixel shading, depth testing, and blending. Explain where the material contributes to the final image. Add detail about interpolators, tangent space, or early depth testing where it's relevant to the role, rather than trying to recite the whole pipeline.

Check the normal-map convention first. A mismatch between OpenGL-style Y+ and DirectX-style Y- maps can invert the apparent bumps. Try the green-channel import option or export the expected convention, then compare under a moving light. Also check that the texture is treated as data rather than sRGB colour. The normal map tool has a lit preview for this.

Start with a parent material and instances, exposing the values artists actually need to change. Instances can share a compiled shader when they use the same static parameters. Static switches can create more permutations, so keep them deliberate. Test the workflow with a few representative variants before building all 30.

Overdraw means processing the same screen area multiple times. Large overlapping translucent particles are a useful example. Inspect the effect with a complexity view and GPU timing, then test smaller cards, fewer layers, or tighter geometry around the visible shape. Compare the visual result as well as the frame time.

Colour textures commonly use sRGB encoding, while lighting calculations use linear values. Data textures such as roughness and masks generally shouldn't receive an sRGB conversion. Check the import settings first: a stored roughness value of 0.5 won't remain 0.5 if it's treated as sRGB. Explain which kind of texture you're investigating before changing the setting.

Agree a format the team can read and validate, then test it against existing assets. A name such as SM_Rock_Mossy_01 can include type, subject, variant, and number. Document the rules and add clear validation errors at an appropriate pipeline step. Handle references before renaming existing content. The Naming Forge tool can help draft the validator.

Preserve the broken file, check the available history and backups, and see whether you can restore a working version. Don't promise recovery before checking. Then investigate the cause: an interrupted save, storage issue, plugin, or conflicting edit. Follow up with an appropriate safeguard. Version Control for TAs covers the recovery workflow.

A useful tool fits the artist's task, has sensible defaults, explains errors clearly, and supports undo where appropriate. Watch someone use it without explaining each step. Their pauses and workarounds will show you where the interface or workflow needs attention.

Try the change with a small group first. Keep a recovery path, explain what will change and when, and be available during the rollout. Check whether the new workflow actually helps before expanding it. If you've done this before, talk through what you learned, including anything you'd change next time.

Measure first. In Unreal, stat unit helps you separate game-thread, render-thread, and GPU time. Compare with a known good build, identify what changed, and use the relevant profiler to narrow it down. Choose an optimisation only after you've found the bottleneck. The profiling guide walks through this process.

A draw call asks the graphics system to render geometry with a particular state. Preparing and submitting many calls can cost CPU time, though the impact depends on the engine, hardware, and workload. Investigate instancing, material sections, culling, and HLODs where the profile supports it. Don't assume a particular call count is a universal limit.

LODs still matter where the project's geometry system, materials, or target platforms need them. Nanite changes how you manage some geometry, but it also has streaming, storage, and rendering costs. Check support in the engine version you're using and profile representative content. Explain the trade-off for that project rather than giving a universal answer.

Use a real example where you clarified what each person needed and helped them agree a workable option. Explain the constraints, the alternatives you considered, and how you checked the result. The useful evidence is how you worked together, including any compromise that remained.

Explain what happened, who it affected, how you recovered, and what you changed afterwards. Take responsibility for your part without assigning blame. If you haven't faced this situation, say so and describe the approach you'd take; don't invent an incident to fit the question.

Explain the cost and offer choices. For example: the full effect needs more time or memory, while a smaller version may fit the current budget. Use measurements or estimates you can justify, explain the visual trade-off, and agree priorities with the art director and team.

Start by understanding the current workflow and the reasons behind it. Set up your environment, speak with the people using the pipeline, and choose a small improvement you can test safely. Save broader proposals until you have that context. The Studio Survival guide covers this in more detail.