It is said that an overwhelming majority of applicants for some programming jobs fail the FizzBuzz test. As part of a simple warmup exercise, I asked my computer systems class (a required course for CS majors, usually taken in the 3rd year) to implement FizzBuzz in C. The problem statement was, I think, the standard one:
Write a C program that prints the numbers from 1 to 100 except that for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz” and for numbers which are multiples of both three and five print “FizzBuzz”. Each number or string should be on its own line.
Out of 152 submissions, one failed to compile since the student had for some reason commented out main(). Out of the remaining 151 submissions, 26 did not produce precisely the expected output. If we ignore whitespace-related issues (extra newline at the start, no newline at the end, etc.), 17 submissions were still incorrect. I looked at each of them:
- Six submissions had what I would characterize as string bugs instead of logic bugs: printing strings like “The number 51 is Fizz” instead of “Fizz”; “Fizzbuzz” or “FissBuzz” instead of “FizzBuzz”; failing to print lines with just the numbers; etc.
- Four submissions printed a “FizzBuzz” line corresponding to zero instead of starting at one. One of these also neglected to print a line corresponding to 100. An additional submission left off the line corresponding to 100.
- Four submissions never printed “FizzBuzz” at all due to logic errors, but did print “Fizz” and “Buzz” properly.
- One submission printed an extra “Fizz” line every time “FizzBuzz” was printed.
- One submission had a logic error that defies explanation.
While I feel strongly that all third-year students in my program should be able to write a correct FizzBuzz, I was still happy to see that nobody failed the basic task of determining multiples of 3 and 5 and that all of the incorrect solutions had more or less the correct shape. Of course, writing this code at home or in the lab, with plenty of time, is far easier than trying to put it up on a whiteboard in the first 15 minutes of a job interview.
13 responses to “FizzBuzz Bugs”
I love blog posts about FizzBuzz, it’s always entertaining how shocked people are by it and reading about how dysfunctional most corporate IT departments are.
So I must say I’m quite disappointed with this post John!
Please publish the one with the logic error that defies explanation 🙂
Also, it would be interesting to have some students try writing that on paper, instead of in the lab, to mimic closely the job interview environment.
I found that FizzBuzz becomes pretty simple if you use two ‘boolean’ (ints for C) variables to detect Fizz and Buzz cases.
Hi Boris, I’m curious why two bools instead of just one? Anyway, FizzBuzz is intended to be easy — its purpose is to rapidly weed out people who cannot program at all.
Hi Vasil, I’m not sure if I’m allowed to post my students’ code. Anyway, it was not a big deal, just some convoluted logic that produced strange output. I agree about the high-pressure environment and might put FizzBuzz on an exam for that reason.
Magnus, I’m one of those people who is shocked by the FizzBuzz posts– all of my industrial experience has been in high-functioning groups where it is inconceivable that anyone could fail this test.
John, I think condition “if (is_fizz && is_buzz)” absolutely corresponds to problem statement, so using two variables makes code self-descriptive.
When I start programming, I also make mistakes coding FizzBuzz. This problem requires understanding of a specification and ability to write clear code. It also requires some meditation – thoughts like ‘oh, it is simple, I code it without even thinking’ fails first attempt to write it.
Hi Boris, I see, thanks. I used a single flag variable in my solution but I think probably a collection of if-else statements without any flags might be a tiny bit cleaner.
> One of these also neglected to print a line corresponding to 100
Well in his defense, when reading your instructions (“Write a C program that prints the numbers from 1 to 100”), I wouldn’t be 100% sure whether the upper bound should be included or excluded. I’d probably go for included, but I wouldn’t bet my life on it considering how many unclear program specs I’ve read in my life. Is that a conventional thing in English?
It’s the same for me with “inferior to” and “superior to”: I’m a French native speaker and in my maths (and science) curriculum we’ve always been told to use either “superior or equal” or “strictly superior”, because just “superior” is ambiguous. So I don’t really know how to handle these.
It’s interesting to see how you’d iterate over a range in different languages: for example in Python you’d use xrange(n + 1), Scala provides ‘to’ or ‘until’ depending on whether you want the upper bound or not, and Haskell provides the double dot notation 1..n which is inclusive.
putStr $ foldr (++) “” (map (\i -> (if (i `mod` 15) == 0 then “FizzBuzz” else if (i `mod` 3) == 0 then “Fizz” else if (i `mod` 5) == 0 then “Buzz” else (show i)) ++ “\n”) [1 .. 100])
is one of the better arguments for Haskell I know of.
… or an argument that Haskell is secretly perl, possibly
I did it this year on my written exam for second year programming students (studying computing, which is more applied than CS). I don’t remember the ratios but some of the answers were depressing (no loops in sight, or no answer at all). Logic errors somewhere were quite frequent. I didn’t care about syntax or things like is 100 included or not. But given that not all of our students took the programming (its a selective for some of our routes, and mandatory for others) and the ones left should be more interested in programming it’s still depressing how many struggle with such a simple issue.
Hi Adrien, I believe that almost every English speaker would interpret “from 1 to 100” as “from 1 to 100, inclusive.” In fact the non-inclusion of the upper bound in Python’s range() has caused several bugs for me. But of course you are right that this specification could be the root of some of the bugs.
Alex: +1
Paul, thanks for the data point. A broad study of the fizzbuzz capabilities of students in computing-related majors would be pretty interesting! Also of computing-related faculty.
I would venture to say that many fail this test due to the problems simplicity and humans natural tendency to only accept answers they are expecting.
Explanation: This test is simple and so it is only natural for people to try and think of clever ways to solve it. Because they can wrap their head around it they try to do something which isn’t boring so they can impress the interviewer. Naturally when to stretch you fail. (note it isn’t bad to fail, it just isn’t preferred in many interviews)
Also many people have such a difficult time breaking out of their own mindset when they have a solution already in mind that they tend to be very critical of answers not exactly matching theirs. When in fact the answer may in effect be the same or may in fact be better. (note: I am guilty of this just as much as anyone else)