If you're interviewing with FizzBuzz, you're doing something wrong

FizzBuzz is a stupid question that got way too popular. It's an interview question that turned into a meme, essentially.

Before you ask this, or any question, you need to first understand what you're looking for. In this case, are you asking it as a sanity check (i.e., are you remotely competent?) or as an evaluative question (i.e., how good are you at ___?).

I've done hundreds of programming interviews, lots of interview coaching, and lots of hiring consulting. This question is just not good.

You might not need to sanity check.

This question became popularized as a sanity check. But do you really need to sanity check?

If I were hiring people to stock a room and they needed to lift 100 lbs, I'd test them with 100 lbs weights. I wouldn't give them 20 lbs weights for an "sanity check". That's a waste of both people's time.

Maybe you can offer a little wiggle room on the bar, because people can be trained. But you don't necessarily need to set a low initial bar. It's okay if you can't distinguish between the bad and really bad people. You're going to reject them both eventually.

It's not a good sanity check.

The problem with FizzBuzz is that it looks like there's something "interesting" to the algorithm. After all, it can't just be a coincidence that 3 means Fizz, 5 means Buzz, and 3 and 5 mean the concatenation of Fizz and Buzz.

A smart person who values a great solution will chase that "interesting" solution, which doesn't really exist (see the answer -- and the ridiculous number of comments: Gayle Laakmann McDowell's answer to Are there really programmers with computer science degrees who cannot pass the FizzBuzz test?). Wouldn't it suck if your "sanity check" was actually cutting some smart coders who care about good solutions?

I've interviewed lots of people who do just this: because this is an interview, they assume I'm going to ask something challenging. This doesn't mean that they overcomplicate things in the real world.

If you want a sanity check question, then make sure it's truly a sanity check question. Here's one, off the top of my head:

Given an integer, write a program to check if the digits are in sorted order.

That's pretty straightforward with a tiny bit of thinking, right? Sanity check. There you go.

It can't be more than a sanity check.

Many people argue that FizzBuzz is more than just a sanity check. That it tells you something about the candidate's ability to write readable, optimal, or extensible code. That does matter -- I agree.

But FizzBuzz isn't a good way to do this. The differences in optimality, extensibility, and readability are so minor that it depends a lot on your assumptions and your interpretation of the problem.

Approach A:

  1. if i % 3 == 0 and i % 5 == 0:
     print "FizzBuzz"
    else if i % 3 == 0:
     print "Fizz"
    else if i % 5 == 0: 
     print "Buzz"
     print i

Approach B:

  1. s = ""
    if i % 3 == 0: 
     s = "Fizz"
    if i % 5 == 0:
     s += "Buzz"
    if s == "":
     s = str(i)
    print s

Personally, I find approach A to be both more readability and extensible. After all, if you change the requirement to "print Foo when i is divisible by 3 and 5", then it's easy to update the code. And, it is most clearly maps to the problem statement, in my opinion.

Others though argue that approach B is better. If you added additional requirements (print Foo if it's divisibly by 7), it'd be easier to update this. Also, it shows a "3 maps to Fizz and 5 maps to Buzz" logic.

I disagree on the readability and extensibility of approach B, but those people aren't wrong. They're just looking at the problem from a different but equally valid perspective.

If you envision the problem as being a sequence of "divisibility by N -> print S" requirements, then approach B is maybe better.

But if you envision it as possibly a coincidence that there's a relationship between the string for {3 and 5} and the string for each, then approach A is maybe better.

How I interpret minor little wording things tells you nothing about my ability to write extensible, readable, optimal code. Connecting these things feels like an ink blot test to me.


Tell me, what do you see? Do you see optimal code?

Tell me, what do you see? Do you see optimal code?

Maybe you can learn something about me out of the discussion of different approaches. Fine. But you're probably not going to look at my approach with an open mind, and if you're really looking for optimality and readability and extensibility, ask a much more complex question.

There are so many better questions.

FizzBuzz is not the worst question ever. It's just not a good question. It doesn't serve well as a sanity check (you might actually reject your best people) and it doesn't serve well to look at more important factors.

Want one that does both?

Given a group of people with their birth years and death years, find the year with the highest population.

It's a sanity check. If someone can't come up with any solution to this problem, that's a bad sign. You can reject the clear no's.

But, it's more than a sanity check! You can also develop solutions which are more optimal. The code is a bit more interesting -- not super difficult, but considerably more interesting than a for loop with basic mod checks.

Plus, this is a really overdone question. When candidates hear this, you'll be sending a powerful signal -- much more powerful than the signal from their performance -- that you couldn't come up with or find a more interesting question. You're just repeating this question because you heard somewhere that it's a good question.

It's not.