Code tests - What do they test?

So recently I had a recruiter set me up with an interview in a completely different industry (the financial industry) than my native industry (Internet). My understanding was I was coming as a senior, experienced PhD, with a background in making real systems work and scale. I wasn't particularly interested in a new job in the financial industry, but it sounded intriguing and they sounded like they really wanted me to check it out.

Things went swimmingly till I was asked to do a 2 hour timed code test. I balked, saying that I wasn't sure what they were going to learn from it, catching the HR person quite off guard. Long story short, they decided I wasn't "gung-ho" enough for the job, and we both moved on.

Well this whole thing got me thinking, what are code tests good for? I basically see 3 categories of job candidates, senior, intermediate and junior and the usefulness of code tests vary wildly from senior to junior. I think that HR folks need to be trained to handle each type differently. First off identifying the types:

1. Senior - Years of experience (3 or more, but not hard and fast), example sites (a portfolio), production code to look at. Blog or tweets related to the field.
2. Intermediate - Years of experience (less than 3, but not hard and fast), some example sites they worked on as a team but not many (a thin portfolio).
3. Junior - Years of experience (less than 1, right out of school), very few or no examples.

If the HR person can't identify the person then don't give a code test right away, do a screening interview (< 30 minutes)

Once you have the person in/around a category (nothing is black and white) I think you handle all 3 differently.

1. Senior - no code tests, respect their experience. Get another senior developer to interview (on the phone) to determine if the candidate is experienced, and most importantly has the right experience for the job. Make sure to ask about things that are key to your product/business, example: If you run a high traffic website, make sure to ask about cache-semantics, and/or eventual consistency.
2. Intermediate - maybe give a code test (I wouldn't). Understand that a code test will be no more useful than a good interview at figuring out the candidate's skill set.
3. Junior - by all means give a code test. The candidate has no reason to expect not to get a test, they have no proof of their ability.

So I think code tests are useful in some instances, but no matter what I think a good interview (not even a long one) will be able to determine a lot more than a code test. To be honest an interview is easier on the candidate, and the engineer who would have to grade the code test (boring, tedious work). The plus of an interview is that you get to feel out the candidate on culture as well, find out if they are funny, moody, easily frustrated...

One other thing is to consider the ordering of the process. I think a code test (as you can probably guess from above), should not be an initial step. With this finance company I had a 15 minute interview with an HR person and then was supposed to take a test. I had yet to know what the job would be (what tech is used, what Artificial Intelligence is used, if any, what the big problems are, in short, how fun the job would be for me), and I was being asked to devote 2 hours out of my (busy) life to do a timed test (which stressed me out).

So I think the best way to handle the process is to do some sort of screening interview with an engineer first. This is for the hiring company and the candidate! Both will have a much better idea of each other's interest level after that. Remember the candidate is interviewing you as much as you are interviewing the candidate. This especially goes for the highly experienced, highly skilled candidates.

So that is it, I guess that could be classified as a rant, but it is not a very aggressive one...