Thank you for the honest reply. I was hoping someone who uses these techniques in their hiring process would explain what they find so useful about it.

I've hired many programmers before myself and I've never used such a rigorous process. I'm just curious why it has become so popular, There's got to be a reason, right?

You have just self-identified your bad attitude. If you think this is "draconian and insulting", just wait until your knee deep in digital shit with customers barking at you all day long.

Actually my bad attitude has left me with a list of references from customers and managers who'd be happy to tell you that they've been satisfied with my work. Some of them are my best evangelists.

What I find insulting is ignorance. In my original comment I mention that it's the rigidity with which the process is enforced which is insulting. I think it's ignorant of the interviewer to not bother reading a candidates' source code when they offer it (the same for their website, etc). You validate that by saying that it doesn't matter what code a candidate has written prior to the interview. That is exactly the ignorance I have a problem with.

I suspect that if the goal of this process is to understand what a person's attitude, knowledge, skills and such are really like then reading their source code and blog posts would be the first step in getting to know them.

I don't care what you've done before, your state of mind, or even if your code ever runs or compiles. If you're any good at all, I'll find out. If you're a poser, I'll find that out, too. And if you don't want to play along, then either you're a poser avoiding exposure or a prima donna who is saving me a lot of suffering down the road.

I find that reading someone's commit history in a project can be very illuminating. The logs alone can give you a sense of their commitment to a project, what kind of work they prefer, and even a cursory glance at their skill level (are they fixing small bugs, introducing bugs, reverting a lot?). If you have time to sit down and read a few patches you can certainly see how well they follow coding conventions, whether they understand control and data structures, and perhaps even algorithms if that's what you're looking for. You can learn a lot from the code a person writes.

What I was having a hard time understanding is what kind of things can white-board (or pencil and paper) problems tell you. After reading your other comments, I think I have an idea. You want to know if they can talk freely about time vs space constraints, optimization, basic control structures, and data structures. You want to know if they know the fundamentals. I can appreciate that.

What I still don't understand about your process is how the candidates' previous code contributions and experiences do not matter. Can you not get the answers you seek from reading their code? If it wasn't just Joe Programmer but Larry Wall or Peter Norvig, would that change your opinion?

I just don't think it's a universally applicable tool, but I find many companies that seem to think it is the only way to screen candidates. I think that some flexibility is necessary because you're dealing with human beings. The hiring process isn't an exact science IMO. Just like Agile isn't the ONE TRUE WAY to develop software I don't think you'll find a single process that will find you the best employees.