Sure it weeds out "non-programmers" - any programming task (more than "Hello World") does. But how many people who are good programmers and just suck a) under pressure, b) especially when surprised are falsely out-selected?

I once failed to answer what a right join is. I got the (freelancer) job anyway - and of course I knew all along what that is, but when I got that question I had not used any joins in years (doing infrastructure work instead), and under interview pressure I can't think except along narrow lines. I ended up doing most of the complicated SQL queries in the department, with people coming to me because to me that was easy. After failing a very simple interview question on joins.

The same comment could apply to any rejection criteria. At my employer, we do have some data, since we do reinterview candidates after years in-between, especially if they are fresh from college. I can't speak for our organization but yes, basic programming hurdles do reliably weed out bad candidates. This is based on my experience of having done more than 150 technical interviews, all of which were balanced against the feedback of the other interviewers. Failing basic programming problems is a good predictor.

> But how many people who are good programmers and just suck a) under pressure, b) especially when surprised are falsely out-selected?

Any kind of test that is given to candidates has the same risk.

But, let's break it down. Do you want to interview candidates for programming positions and _not_ have them program in some form or fashion during an interview? IMO that's nuts.

"If I roll this d6, what will the average be over time?"

I've asked this to loads of supposed graduates, and apart from the odd one who made the "WTF are these monkeys hiring me for" face, a lot of people can't figure it out from first principles.

But a lot of people choke on it. Also I've had people choke on very basic general knowledge like "think of a large emerging economy in Asia".

Maybe it's nerves, maybe it's thinking too much about a simple problem.

With coding, perhaps the surprise comes from the fact that a FizzBuzz test would seem like quite a powerful test. If you can't do it, you know you can't do it. There's no doubt that you're not a programmer if you can't solve FizzBuzz and its ilk. So why do people apply, knowing they will be tested? That's the real question.

I guess the answer is you learn where you're at when someone asks you something you can't answer. Sometimes it's not where you thought.

I don't mean that I can't solve problems. I mean I can't hold a conversation.

I wonder if the reason so many people fail is because we've essentially put them in an artificial situation that shuts their brain down.

(I have also been dumbfounded by the inability of recent CS graduates to do FizzBizz... I feel like it's not certain our candidates are frequently flawed. Maybe it's our environment.)

That sounds really hard. I'm sorry.

But I can't imagine any interview technique which would work reliably if you're brain dead during the interview.

I'll be honest, that's a really dumb question for testing programming skill.

Still not a great question, maybe. But you grab whatever is in your bag.

(1 * 1/6) + (2 * 1/6) + (3 * 1/6) + (4 * 1/6) + (5 * 1/6) + (6 * 1/6) = 3.5

Of course no actual roll of the die will ever come up 3.5, but as you roll the die more and more times, the average of all results seen so far will begin converging on 3.5 (and given infinite rolls, that's where it would end up).