Building A TA Portfolio
Use your portfolio to show how you solve production problems. The finished image or tool matters, but the breakdown gives a reviewer the context: what you needed, what you tried, and how you checked the result.
On this page
The 90-Second Review The Starter Formula Anatomy Of A Breakdown Showing Code Hosting & Format Classic MistakesMake The First Review Easy
A reviewer may have limited time, so put the useful evidence near the start. Make these things easy to find:
- What did you build? Use a screenshot, short clip, or before-and-after view that shows the tool or system in use.
- How does it work? Link to a breakdown of the problem, approach, and result.
- Can they inspect the implementation? Where you can share code, include a repository link and clear README.
- What were the production constraints? Include budgets, performance measurements, user feedback, or other evidence that influenced the work.
Try opening the portfolio as a new visitor. If any of that takes too much searching, simplify the page.
The Starter Formula: One Tool, One Shader, One Pipeline
A tool, a shader, and a pipeline script can be a useful starter mix. It isn't a hiring formula; choose pieces that show the skills needed for the role you're applying for.
| Piece | What it proves | Examples (steal these) |
|---|---|---|
| One tool | You can turn someone's annoyance into a button | A batch renamer with a UI - an export validator - an auto-LOD script - rebuild any tool from our Tools section inside a DCC |
| One shader | You understand the GPU side of the craft | A dissolve effect - stylised water - triplanar blend material - a master material with sensible parameters - see Shaders & HLSL |
| One pipeline | You can make two programs cooperate | Blender -> Unreal batch exporter with correct scale/axes - a texture-processing watch folder - Houdini HDA driving assets into an engine |
Finish a small, usable version of each piece and explain its limitations. Someone reviewing it should be able to understand what works and how to try it.
Anatomy Of A Breakdown
A breakdown helps the reviewer follow your decisions. This structure is a useful starting point:
- The problem, in one sentence. "Artists were spending ~15 minutes per prop setting up export hierarchies by hand."
- Constraints. Engine version, team size, why the obvious solution wasn't available. Constraints are what make your choices interesting.
- The approach, including what didn't work. Explain what you tried, what you learned, and why you chose the final design.
- The result, with measurements where available. Time saved, triangle count, draw calls, or steps removed can all be useful. Label estimates clearly and explain how you measured them.
- What you'd change next. A short, honest account of the limitations and the next useful improvement.
For example, a shader breakdown could explain that the first version failed because of depth sorting, then show the test that exposed it and the fix. That gives a reviewer evidence of your reasoning without relying on a claim that everything worked first time.
Sharing Your Code
- If you're able to share the code, include a public repository with a screenshot, a short explanation, and installation steps. A clear README helps someone decide whether to look further.
- Pin your most relevant repositories and make your own contribution clear in tutorial-based work.
- Explain why a decision was made where the code alone doesn't make it obvious. Clear names, focused functions, and useful docstrings make the work easier to review.
- Student projects are worth showing. Make them readable, explain what you've learned, and be honest about the parts you'd improve.
Hosting & Format
A simple website or ArtStation page can hold the visuals, with a repository link for code. For an interactive tool, a short video often explains more than a still image. Add captions or on-screen text so it also makes sense without audio.
Make the work accessible from the CV link without a login or a request for access. Check the links in the exported PDF as well.
The Classic Mistakes
| Mistake | Why it hurts |
|---|---|
| Twenty pieces, no breakdowns | Doesn't explain the technical work or your decisions |
| "Proficient in Python, Maya, Houdini, Unreal, Unity, Blender..." | Needs examples showing where and how you used those skills |
| Only tutorial results | Explain which parts came from the tutorial and what you changed, tested, or extended yourself |
| Hiding the failures | Explain what an unsuccessful approach taught you and why you changed direction |
| No video of tools | Include a short clip showing how the tool works, alongside the screenshots |
| Waiting until it's "ready" | Publish a few clear pieces when they're ready to review, then improve the presentation with feedback |