I love FizzBuzz. The great thing about it is that it's easy to write code that works so candidates can feel happy that they've 'passed' but flexible enough that people's solutions will differ. And that's what you want in an interview situation - working code that you can talk to the candidate about. If you question what they've done and the candidate can explain and defend their decisions then you can figure out if they'll be able to speak up and contribute to technical discussions, to communicate their ideas and comment on other people's solutions. That's the sign of a good developer (in my opinion).
If a person cannot do FizzBuzz, they cannot program. But a lot of terrible programmers are fully proficient at the FizzBuzz level of programming. I don't think it really provides a useful venue for assessing skill beyond bare minimum levels. I have another interview question that I use for chemistry matching, but it's more algorithmic than coding.
Even a simple solution to FizzBuzz can lead to interesting discussions. Why did the candidate use nested ifs rather than a cascade or a switch, why did they use a modulus operator instead of division, why didn't they bother to catch errors if a non-integer value was passed to their function, how could you efficiently make the code scale to work with a bigint, what would you do if the code required abstraction so the parameters could be defined at runtime, and so on pretty much ad infinitum.
The beauty of FizzBuzz is that while it's obvious it can lead to interesting places. If a candidate just knows a way or two to implement it they'll quickly run out of things to say when you're talking about their solution. Discussing a solution and improving it is a skill you want in a developer. FizzBuzz can discover how competent they are at that. The way I use FizzBuzz isn't really about finding out if someone can code. It's about something bigger than that.
Where's the fun in the simple straightforward implementation ? How would you judge a candidate that, on the spot, decided to go with a new way to solve it just so (s)he could see if it worked out well. For example ... something like this ?
print '\n'.join(("fizz" if x % 3 == 0 else "") + ("buzz" if x % 5 == 0 else "") or str(x) for x in range(1, 100))
or even:
from __future__ import print_function
map(print, (("fizz" if x % 3 == 0 else "") + ("buzz" if x % 5 == 0 else "") or str(x) for x in range(1, 100)))
What if they come up with a solution, you have no idea why it works, but it works ?
Sadly, I expect most interviewers would react very negatively. I've already learned never to demonstrate actual programming ability, even when asked. Instead, answer every question the way you would answer physics problems in high school. You know, the problems asked by the teacher who has a bachelor in biology.
People are even justifying this with "clean code" arguments and the like. "Why aren't you using the framework ?". "Is that the best way to write such a complex thing". Worst of all : "what does that mean ?". You don't want to be asked those questions, it will not end well.
Interviewers who can't program will then start arguments about how programs should be designed/written, and the answer boils down to "design by committee, manned 90% by people who cannot pass FizzBuzz". Of course, best to leave out the second part if you point this out and instead add "ask for feedback".
