Never. Edit (4/20/2017): Well, maybe in limited circumstances.
FizzBuzz is a “simple” programming interview question. There’s a few variants but it goes something like this:
Tell me pseudocode that, for numbers from 1 to 100: Print "Fizz" for numbers evenly divisible by 3. Print "Buzz" for numbers evenly divisible by 5. Print "FizzBuzz" next to numbers that are evenly divisible by 3 and 5. Otherwise print the number
Why you should not ask this question
It’s “so simple” that interviewers are usually looking for the perfect answer immediately as the first words out of your mouth. But let’s be honest, if the interviewee has never seen it before they’re probably going to say something that makes them look less than perfect, whether it’s taking too long, saying something that’s actually wrong, or even something that’s just suboptimal.
To test this, I asked two former colleagues of mine this question, and they both very quickly came up with a 3 branch solution: if number evenly divisible by 15, print fizzbuzz, otherwise if it’s evenly divisible by 5, print buzz, otherwise if it’s evenly divisible by 3, print fizz.
An interviewer could have taken issue with:
- “evenly divisible” – how is this determined?
- What about printing the numbers?
Anything less than immediate perfection makes the interviewee look like they’re not that sharp. But this is clearly not the case – one of them had a PhD in math, the other had a Master’s degree in math, and both had achieved among the highest levels of technical leadership at our former employer (and both were stellar programmers).
The problem is with the expectations. Who can achieve immediate perfection, especially in a relatively high-stress situation like an interview? Next to no one. So how do you ace this question? Either be really, really fast at thinking through code flows, or have seen it before.
Right answer, correct algorithm
IMO, if you’re asked this question, it’s probably more of a litmus test for you than for them; it’s an indicator you probably don’t want to work for this company. So, I think it’s an opportunity to (gently) educate them. You could tell them that you read this article :), that because it’s well specified and easily testable it’s a perfect candidate for a TDD approach, that you would write the 100 lines of expected output, and modify your code until it matched. Then, if there was any discussion about performance, you would use appropriate performance testing to evaluate the options.
Or, you could go down the road of telling one simple, correct algorithm:
# print includes a newline, console.log style for (i = 1; i <= 100; ++i) if (i % 15 == 0) print "FizzBuzz" else if (i % 5 == 0) print "Buzz" else if (i % 3 == 0) print "Fizz" else print i
I recently had a conversation about FizzBuzz with a person who used it during interviews with junior programmers. With the right expectation, namely that the answer may not be immediately correct, it could be a potentially valuable tool to see how a junior developer is able to work through the problem. On the other hand, he mentioned that since it is used with such prevalence, it loses its value as a thought exercise because junior programmers have probably already seen it. So, there could be value in asking junior programmers to develop FizzBuzz, but only if they have not seen it before. Perhaps ask if they have seen FizzBuzz – if the answer is yes, move on. If no, go ahead and ask, and expect that there will be some imperfections.