Not fluently. A lot of strong Technical Artists came in from the art side and picked up scripting because they got tired of doing the same thing by hand for the four hundredth time.

You do need to be able to read code and follow its logic, and you should have written something yourself, even if it is only a handful of lines.

Not a professional one. Plenty of people in this discipline came from computer science or engineering and worked out what artists need by sitting next to them and paying attention.

What you do need is to be able to look at a piece of art and have some sense of what went into making it, and to care whether the thing you build makes that process better. Most of this job is spent in service of people doing creative work. If that side of it holds no interest for you, the work will be frustrating regardless of how good your technical skills are.

Game art, animation, VFX, technical art, computer science, engineering, or a related field. We also take people who have no relevant degree but do have a portfolio that shows the work. What you have made matters more to us than where you studied.

No. This is a graduate program designed for people who have never worked in games. Mod work, game jams, university projects, and freelance work are all relevant experiences as far as we are concerned. If you have done an internship or worked on something that shipped, tell us about it, but it is not something we screen for.

There are five stages. Every stage happens online, so there is no travel and no day off to visit an office. You hear from us either way at every stage. 

1. Application and portfolio review
2. Online written assessment 
3. Recorded video answers.
4. Take-home task
5. Final interview

An outstanding portfolio is the first thing we look at, and it should show the work and how you got there. It does not have to be an art portfolio. Tools, scripts, rigs, shaders all count.

In addition to a portfolio there are two things you need:

• Comfort in at least one content-creation package or game engine. Maya, Blender, Houdini, Substance, Unreal Engine, or whatever you happened to learn.
• Some scripting. It does not need to be much, but you should be able to read code and have written something.

Technical Art is a job people arrive at from many directions. Some come from art and learn to script their way out of the repetitive parts. Some come from computer science and find they enjoy working on art features. Some come from student teams, where they end up fixing everyone else's exports and writing a tool so it never has to happen again. Some are self-taught and made games in their spare time long before anyone paid them for it. What we are looking for is a passion for making games and for how they get made.

We take applications from a wide range of degree backgrounds, and from people with no degree at all who can show us the work instead.

This is the question every Technical Art applicant asks, so here is a specific answer.

Show the problem, not just the result. A rig is more interesting to us when accompanied by a note about what it had to survive. A tool is more interesting with the before-and-after: how long the task used to take, how long it takes now, and what broke along the way. Three pieces you can explain in depth tell us far more than twenty you cannot.

If you built something for another artist, tell us whether they used it and what they said about it.  If the work was made with other people, say who did what. Team projects, student projects, and jam entries are all welcome. We are not trying to trip anyone up, but we do need to know which parts were yours. Being vague about it is the most common reason a promising portfolio does not survive review. Unfinished work is fine when you say what you learned from it and what you would do next.