Here are some questions where I always enjoy the answers to:
If you could make a game or a software tool, regardless of time and resources… what would it be? How would your initial plan look? What resources and tech would you employ and how?
I then usually give an example of my own pet project, which is an isometric sort-of-open-world game like Rogue or Ultima. I describe the tech, the major classes, the risks I identified and the approach I take to implementation.
If you could learn something related to your career, what would it be? Why do you think it’s useful? How would you go about it and set your learning direction?
I think both questions cover a lot of what I want in a TA. And both questions offer great opportunities to dig deeper. They’re also both suited for an interview that unfolds like a regular conversation.
I want TAs to think not just as engineers, but also as people who can deliver a product (like a script). This involves planning time and resources, understanding requirements, and planning the technical approach they take. I also watch out for motivation. Usually people are quite passionate about the tool or game they always wanted to make.
The second question tells me how a TA might approach getting into a new engine, or into a new DCC tool, or learn new techniques. Having TAs who have a good approach to learning makes mentoring much easier and efficient. And I consider being able to learn new things one of the core TA skills. If I have to spoon feed you all the time, then I can’t really need you on my team, as we have to be independent.
Questions I consider useless:
“Your biggest weakness” - there is so much coaching these days around the question, the answer you get won’t be the truth. Also, I’m concerned about weaknesses related to the role I have to fill. But those weaknesses you rarely find by asking this question.
I also dislike asking logic puzzle questions. Most of them are artificial, and personally, I don’t care how people solve problems as long as they solve them. I’m quite pragmatic here. In real life you will either puzzle it out, google it, refer to the manuals, prototype or iterate on it, bounce ideas off fellow TAs … or do a combination of all of those.