Skip to content
The Technical ArtistArt. Code. Pipelines. Games.
Home/Tech Art/For Hiring Managers
tech art
for managers
send this up the chain

Hiring A Technical Artist

guide~3 min read

Start by identifying the work you need a technical artist to own. This guide covers choosing a specialisation, writing a useful job description, assessing the work, and supporting the person once they join.

On this page What You're Buying When You Need One Writing The Posting Evaluating Candidates Keeping Them

What A TA Can Help With

A TA can improve asset workflows, build validation, investigate performance, and help artists and engineers agree practical constraints. For example, saving eight artists 20 minutes a day adds up to roughly 13 hours over a five-day week. Use that sort of calculation to understand the value of the work you actually need.

Without clear ownership, pipeline support often falls across artists and engineers alongside their main work. Look at how much time that takes and where recurring problems remain. That will help you decide whether a dedicated role is justified.

When You Need One

  • A growing art team can justify dedicated tooling support, but headcount alone isn't a reliable threshold. Look at repeated work, support demand, and delivery risk.
  • Any custom pipeline (your own engine, unusual DCC mix, heavy outsourcing intake) moves the threshold earlier.
  • Recurring manual exports, late asset integration, and repeated performance surprises are useful signals. Gather examples and estimate their cost before deciding what the first TA should own.

Write A Clear Job Description

Shader authoring, pipeline engineering, and character rigging are three different specialisations. A role can span more than one, but asking for deep expertise in all three may hide what you actually need. Make the primary responsibility clear.

Write down what the person should achieve in their first three months. Export and validation work points towards pipeline skills; material libraries towards shader expertise; deformation work towards rigging or technical animation. Build the requirements around those tasks.

  • Keep essential requirements focused. Separate what the person must know on arrival from what they can learn. Explain how each requirement relates to the work.
  • Name the first project. "Your first quarter: rebuild our Blender->Unreal export path" attracts exactly the people who like that problem - self-selection does your screening.
  • Assess relevant work. A degree can provide context, but practical projects and clear breakdowns may demonstrate the skills you need just as well.
  • Post the salary band. TA salaries are opaque (we wrote a whole page on it); ranges get you candidates who'd otherwise not risk the process.

Evaluating Candidates When You're Not Technical

  • Ask for the reasoning behind the result. Look for constraints, alternatives, measurements, and the candidate's own contribution. A polished image alone doesn't tell you how the work was done.
  • Ask about users. 'Tell me about a tool people used, what feedback they gave you, and what you changed.' This opens a useful discussion about both implementation and support.
  • Include an artist and an engineer. Each can explore a different part of the role. Agree the assessment criteria beforehand so the feedback is consistent.
  • Keep any test proportionate. Explain the scope and time limit, consider payment, and offer a way to discuss existing work where appropriate.

Keeping Them

Give the role clear priorities, time for maintenance, and a fair progression path. A TA taking requests from several departments needs someone to resolve competing demands. Discuss training and community events as part of development, and make sure the salary and level reflect the responsibilities.

The short version, for forwarding

Define the work, keep the requirements relevant, share the salary band, and assess practical evidence. Once the person joins, give them a manageable backlog and the support needed to deliver it.