So, when production is down, and clients are calling, and revenue is lost, it's okay to say "I'm too stressed to fix this bug?"

I'm sympathetic to complaints about overly technical interviews (I've bombed a few in my day because of stress and/or ignorance), but as others have pointed out, this is FizzBuzz. I'm generally very bad at interview/algorithm puzzles, but I could even figure this one out pretty quickly.

A better metaphor would be those things happening and your boss saying "solve fizzbuzz in 10 minutes or we'll fire you". (or we'll fire you == not getting the job/failing the interview).

The big difference between the two metaphors is that mine has direct impact on your personal life and negative consequences are gonna be seen as your fault, while yours is a company threat - fixing it will get you seen as a hero, not a disgraced villain.

If you're so stressed you can't write fizzbuzz in an interview then how are you going to deal with any workplace stress?

Interview stress and normal workday stress are completely different beasts, in my experience. Coping with one is not always an indicator of the ability to deal with the other.

How are we supposed to interview candidates at all, if their interview specific stress is so crippling? What sort of things can they answer, if not at least FizzBuzz?

Give them a unique programming problem before hand and ask them to bring their solution to the interview, and then discuss the solution with them.

Unless they "cheat" this should give you a good idea of what they're capable of. The cheating should also show up if they cannot explain it or why they wrote it the way they did.

How far beforehand would you suggest? Would walking into the interview, handing them the problem, and then telling them that you'll come back in 10/15 minutes to "start" the interview be acceptable?

Asking someone to solve a problem in the waiting rooms is considerably different then letting them solve the problem in their chosen environment. Probably not as stressful as durring an interview with people watching however.

As noted in another reply to this question, get them to bring in a project and explain it.

Additionally, they could spend some time with the team they'd be working in, pairing (or whatever) with other members and really demonstrating their abilities.

It's not really that difficult to get away from the whole "technical question at the interview" problem, and I'd wager that in the long-term it'd be better for all concerned.

Eh, maybe. Those are fine interviewing techniques, but I am unconvinced that explaining something technical you've done in the past would really be that different (from a stress-induced difficulty standpoint) than FizzBuzz.

That's the whole point of the article/test - there are loads of folks (apparently) who can talk about it but not produce even this simple example when asked to. You probably don't want them.

Yeah, that was my take-away. Any "talk about what you have done" that gets specific enough should be susceptible to the same stress though; I cannot fathom how that wouldn't be the case.

Which is why I wrote the second part: Drag them in for x days, get them to work with existing staff on existing problems. If you have engaged staff, they will weed out the (clue|use)ful and reject the time-wasters.

But that's a very expensive thing to undertake, when you can use FizzBuzz to filter out the timewasters at little to no cost to yourself...

There is no way I would invest my staff's time in doing that if I hadn't even established that they could fizzbuzz yet.

Fortunately there are plenty of employers.

Even Google lets you try again in a year.