I had a few opinions about this myself at GDC, so let me elaborate a bit...mainly because i like to hear myself talk.
Let's look at two points here: General Experience and Position Specific.
In general, years experience is a big thing, but weigh overall experience vs time spent as a TA. This is an assumption, right now I think that anyone who's been a TA/TD for an appreciable length of time probably started out as an artists or engineer, just because 5-10 yrs ago, TA/TD wasn't such a prolific thing in games. In 3-5 yrs, this probably won't be true given the rise of TA/TD focused education in various. I've actually interviewed a few people that had 10-15 yrs in games, but only 1.5-2 yrs as a TA, and sometimes that tends to show through when you're asking the TA/TD specific questions. Not saying that the overall yrs experience isn't valuable, but i definitely don't let people rest on that sort of laurel (but that's just because i'm a jerk).
Also i would give a little bit more weight to someone who's worked on different teams/projects/technologies. Personally, getting the opportunity to work with different teams and different technologies has been one of the most valuable experiences of my career just because you get the insight into "how the other halves live", rather than just being the Max/UE3 expert (altho given the state of the industry, that's probably not a bad thing:laugh:).
Scripting/coding experience is an interesting point and a good segue into the position specific stuff. Sounds weird, but i've worked for teams/studios where you actually do have a Technical Art Director who is more of an architecture designer/liason vs implementer. If you're talking about the former, it's probably good enough that they can at least speak intelligently about the constraints placed on engineering but maybe not necessarily have spent time learning how to actually type C++. If you're talking about an implementer tho, well...A little while ago i probably wouldn't have thought too much about it, ie, "have you written MAXScript or MEL? ok cool, that's good enough". Nowadays though it seems like everyone has touched Python and/or C# in some form or fashion, and that's the sort of thing to look out for. Just from talking to folks at GDC, it sounds like people are moving more and more to C# and Python based frameworks, so it seems to me a valuable thing to really KNOW the languages. One of the ideas that bugs me is that "knowledge of syntax implies knowledge of lanuage", which is just not true (ie. how many people have C# or Python on their resumes, but don't know what an Interface or new is?). If someone at the Sr Level has a language on their resume, to me it seems like it's fair game and you should definitely try to gauge the depth of their knowledge, not so much to call them on it, but because you really want to know how useful this person is going to be. It doesn't have to be an extensive test, i mean i can think of a few really simple questions you can ask someone to gauge their Python knowledge, for instance.
This one i think is quite a bit simpler. In this case, I don't know if i would test someone, for this position i'm more interested in what you've actually done. The questions i'd be most interested in getting answered would pertain to how well this person interacts with discipline leads (takes direction), but also how flexible they can be once those parameters are established (thinks for themselves, can work unsupervised, etc).
Yes...hehe no seriously i'd say look everywhere. Sometimes you get that artist in your studio who wants to move into Tech Art (god help them), so why not give them a little training and move them over? It might help with retention and you already have someone who's familiar with your pipes/processes. As i mentioned above, it's also getting easier to find tech art savvy folks in educational institutes (ETC and Digipen come to mind), so it never hurts just to put a call out and see who comes knocking...
I think at the jr/mid-level we usually have an idea of what we need them to do, but we tend to leave implementation up to them, so it's almost like when you start, you're going to be expected to do some design, but we keep the scope limited. Recently we hired a contract rigger and while we did kinda just toss him into the deep end, it was all within his skillset as we perceived it. The whole Jr TA/TA Apprentice thing is definitely an interesting point...Formal training for TAs isn't something we've established, i think the understanding is if you can make a case to the higherups here that you need a certain class or training course, you'll be allowed to take it at least partially on the company's dime.