I think part of the key with giving FizzBuzz is telling the candidate that any working solution is AOK and meaning it, in other words the dumbest brute force loop is a successful answer. My suspicion is that more candidates than one would expect get hung up worrying about giving some sort of clever answer to impress the interviewer that they bobble it up a bit.

That said, for FizzBuzz proper, one should have dozens of solutions memorized for these situations, but for similarly easy questions the candidate might not have come across that might end up being a big deal.

> My suspicion is that more candidates than one would expect get hung up worrying about giving some sort of clever answer to impress the interviewer that they bobble it up a bit.

I've definitely felt that pressure as an interviewee. It's pretty disheartening to write a simple and obviously correct implementation only to have the interviewer express their disappointment that you didn't use a particular optimization.

The most fun technical questions I've had start with making a functional algorithm and then massaging it to meet whatever time/space complexity requirements are asked for. Sometimes it results in a complete rewrite and that's ok, the real world works like that too.

> It's pretty disheartening to write a simple and obviously correct implementation only to have the interviewer express their disappointment that you didn't use a particular optimization.

I almost always preface whiteboard coding sessions with "I'm going to write some dumb, slow code and then we can make it faster if you want. Sound OK?" I've never had anyone disagree with this, but if they tell you they want you to go straight to the clever solution, hey, now you know what they're looking for.

Even still, sometimes it helps just getting a solution down in order to step back and figure out the clever solution.

Plus, you can "scale up" the interview to harder questions so you can test the candidate without making them feel bad by bombing a touch problem at the very start of the interview.

Well, that is just it. Certainly 100% of the people I have ever worked with, even the bad ones, can write a for loop and an if statement. I mistrust the process more than I mistrust the people, though I suppose maybe the same bad people and endlessly interviewing.

50% of working programmers can't write a for loop? Does that square with your experience outside of interviewing?

I don't quite buy the whole fizz-buzz story, though I don't have an adequate explanation for what could cause these kinds of failure rates. Something seems very off.

>50% of working programmers can't write a for loop? Does that square with your experience outside of interviewing?

Not 50% of working programmers, but of the programmer applicant pool. The applicants who can find jobs quickly aren't in the pool very long, and so it's dominated by the fakers and those who otherwise shouldn't be there. ... Which should make the reported phenomenon a little more believable.