I came across this post today and wasn’t sure what to make of it. In my current job and my previous one, interviewing potential hires for programming was part of my job. I can’t say I ever used “FizzBuzz” types of questions on candidates, and I’m not sure that would tell me the sort of things I need to know about someone. I find myself asking a lot more design questions and process questions with perhaps one or two programming questions thrown in. But before even getting to that stage, I have to feel good about their resume. I think the majority of people give you enough information in their resume that you can figure out whether a phone screen is worthwhile in a relatively short period of time.
These types of “tests” are good basic things to figure out about a candidate, but they are FAR from a complete picture. Personally, I’d put it more to the fact that the candidate wasn’t prepared to take a test for the job, and its hard for inexperienced coders to just sit and write code out on paper – no matter how simple – they need to be in front of a screen where they can experiment.
I was always more interested in HOW the person thought and HOW they solved problems they didn’t know the answer to. I want people who I can say “Go solve problem X” and they come back with a couple solutions in a short period of time. They might not be perfect solutions, but that’s where the group-mind gets together and does the polishing. Those folks are far more valuable than people who can just spew loops.
I’m with you on being interested in how people solve problems.
You’re probably right about the candidates not being prepared to take a test. I’m just not sure how anyone in this day and age who was looking for a job as a programmer could go into an interview not expecting to write some code. The vast majority of places where I was a programmer asked me to write some during the interview process. Even when I interview testers they have to show some ability to write SQL queries. Every programming candidate I see has to write some.