FizzBuzz Still Works

by Joey deVilla on November 15, 2012

The Sorting Hat

I recently interviewed some programmers for a couple of available positions at CTS, the startup crazy enough to take me as its CTO. The interviews started with me giving the candidate a quick overview of the company and the software that we’re hiring people to implement, after which it would be the candidate’s turn to tell his or her story. With the introductions out of the way — usually at the ten- or fifteen-minute mark of the hour-long session, I ran each candidate through the now-infamous “FizzBuzz” programming test:

Write a program that prints out the numbers from 1 through 100, but…

  • For numbers that are multiples of 3, print “Fizz” instead of the number.
  • For numbers that are multiples of 5, print “Buzz” instead of the number
  • For numbers that are multiples of both 3 and 5, print “FizzBuzz” instead of the number.

That’s it!

This was the “sorting hat”: the interview took different tacks depending on whether the candidate could or couldn’t pass this test.

I asked each candidate to do the exercise in the programming language of their choice, with pen and paper rather than on a computer. By requiring them to use pen and paper rather than letting them use a computer, I prevented them from simply Googling a solution. It would also force them to actually think about the solution rather than simply go through the “type in some code / run it and see what happens / type in some more code” cycle. In exchange for taking away the ability for candidates to verify their code, I would be a little more forgiving than the compiler or interpreter, letting missing semicolons or similarly small errors slide.

The candidates sat at my desk and wrote out their code while I kept an eye on the time, with the intention of invoking the Mercy Rule at the ten-minute mark. They were free to ask any questions during the session; the most common was “Is there some sort of trick in the wording of the assignment?” (there isn’t), and the most unusual was “Do you think I should use a loop?”, which nearly made me end the interview right then and there. Had any of them asked to see what some sample output would look like, I would have shown them a text file containing the first 35 lines of output from a working FizzBuzz program.

The interviews concluded last week, after which we tallied the results: 40% of the candidates passed the FizzBuzz test. Worse still, I had to invoke the Mercy Rule for one candidate who hit the ten-minute mark without a solution.

The Legend of FizzBuzz

I was surprised to find that only one of the candidates had heard of FizzBuzz. I was under the impression that that it had worked its way into the developer world’s collective consciousness since Imran Ghory wrote about the test back in January 2007:

On occasion you meet a developer who seems like a solid programmer. They know their theory, they know their language. They can have a reasonable conversation about programming. But once it comes down to actually producing code they just don’t seem to be able to do it well.

You would probably think they’re a good developer if you’ld never seen them code. This is why you have to ask people to write code for you if you really want to see how good they are. It doesn’t matter if their CV looks great or they talk a great talk. If they can’t write code well you probably don’t want them on your team.

After a fair bit of trial and error I’ve come to discover that people who struggle to code don’t just struggle on big problems, or even smallish problems (i.e. write a implementation of a linked list). They struggle with tiny problems.

So I set out to develop questions that can identify this kind of developer and came up with a class of questions I call “FizzBuzz Questions” named after a game children often play (or are made to play) in schools in the UK.

Ghory’s post caught the attention of one of the bright lights of the Ruby and Hacker News community, Reg “Raganwald” Braithwaite. Reg wrote an article titled Don’t Overthink FizzBuzz, which in turn was read by 800-pound gorilla of tech blogging, Jeff “Coding Horror” Atwood.  It prompted Atwood to ask why many people who call themselves programmers can’t program. From there, FizzBuzz took on a life of its own — just do a search on the term “FizzBuzz”; there are now lots of blog entries on the topic (including this one now).

In Dave Fayram’s recent article on FizzBuzz (where he took it to strange new heights, using monoids), he observed that FizzBuzz incorporates elements that programs typically perform:

  1. Iterating over a group of entities,
  2. accumulating data about that group,
  3. providing a sane alternative if no data is available, and
  4. producing output that is meaningful to the user.
If you can’t write a program that does all of the above in its most basic form, you can’t program. It’s that simple. Needless to say, anyone who didn’t pass FizzBuzz didn’t pass the interview.

My FizzBuzz Solution

I can’t go fairly judge other programmers with FizzBuzz without going through the test myself. I implemented it in Ruby, my go-to language for hammering out quick solutions, and in the spirit of fairness to those I interviewed, I did it with pen and paper on the first day of the interviews (and confirmed it by entering and running it):

I consider myself a half-decent programmer, and I’m pleased that I could bang out this solution on paper in five minutes. My favourite candidates from our interviews also wrote up their solutions in about the same time.

A Forty Percent Pass Rate?!

Okay, the picture above shows a 33% pass rate. Close enough.

How is it that only 40% of the candidates could write FizzBuzz? Consider that:

  • All the candidates had some kind of college- or university-level computer programming education; many had computer science certificates or degrees.
  • The candidates had varying degrees of work experience, ranging from years to decades.
  • Each candidate could point to a sizeable, completed project on which they worked.
  • All the candidates came to us pre-screened by a recruiting company.

A whopping sixty percent of the candidates made it past these “filters” and still failed FizzBuzz, and I’m not sure how. I have some guesses:

  • Moving away from programming: Some of them may have started as developers initially, but over time, their work changed. They still hold some kind of programming-related title and their work still has something to do with the applications they were hired to develop, but these days, most of their job involves tasks outside the realm of actually writing code.
  • “Copy and paste, adjust to taste”-style programming: Also known as “Coding by Googling”,  this is when a developer writes applications by searching for code that’s similar to the problem that s/he’s trying to solve, copy-and-pastes it, and then tweaks it as needed. I get the feeling that a lot of client-side JavaScript is coded this way. This is one of the reasons I insisted that the FizzBuzz exercise be done on paper rather than with a computer.
  • Overspecialization: It could be that some candidates have simply been writing the same kind of program over and over, and now do their work “on autopilot”. I’ve heard that FizzBuzz is pretty good at catching this sort of developer unaware.

If you’re interviewing prospective developers, you may want to hit them with the FizzBuzz test and make them do it on paper or on a whiteboard. The test may be “old news” — Imran wrote about it at the start of 2007; that’s twenty internet years ago! — but apparently, it still works for sorting out people who just can’t code.

Be sure to read the follow-up article, Further Into FizzBuzz!

{ 69 comments… read them below or add one }

51 Wesley Kerfoot November 16, 2012 at 2:08 am

Here’s a solution I banged out in Racket:
(define fizzbuzz
(let ([eqmod? (λ (k) (λ (n) (eq? 0 (modulo n k))))])
(map (λ (n)
(match n
[(? (eqmod? 15)) "FizzBuzz"]
[(? (eqmod? 5)) "Buzz"]
[(? (eqmod? 3)) "Fizz"]
[_ n]))
(stream->list (in-range 101)))))

As for the whole thing about the modulus, well, I would expect most programmers to know a little bit about discrete math, enough to know that the remainder of 2 numbers divided by each other is “mod”. However as was said, you don’t really need to know that, you can just do isInteger(n/3) and define isInteger as floor(n) == n. If they don’t know what floor or ceiling are, then I suppose they could try converting it to an integer in whatever language they use (knowing that it will truncate anything after a decimal point) and compare it to the original number, but I think that’s an extremely fragile solution.

Knowing about this stuff — mod, floor, etc… has USES. Anyone who doesn’t know what they are cannot know much, if anything about computer science imho.

52 Jaime November 16, 2012 at 6:44 am

I don’t think that the only outcome is to know wether someone can program or not.

If you watch someone going to this process, making questions, checking the code, writing clear code or obscure algorithms, that also gives a lot of valuable feedback on how someone thinks and if he is a good fit on your team.

Maybe you want someone that cares about not using modulus. Or return the value instead of printing it right away. Or cares about performance, so stores all the FizzBuzz values in a constant array. Or have a very clean code. Etc…
You can also start there and then complicate the process. What if we change to accept an array as the input? Should that be checked to ensure they are integers? What if the FizzBuzz values needs to be returned in some form of HashMap? Etc…

It not (necessarily) a Boolean test. It can be the start of a discussion.

53 Dan Q November 16, 2012 at 9:34 am

I also chose Ruby for my implementation, but I went for something a little more concise (or “icky”, I suppose):

puts (1..100).collect{|i| f = ((i % 3) == 0); b = ((i % 5) == 0); (f && b ? ‘FizzBuzz’ : (f ? ‘Fizz’ : (b ? ‘Buzz’ : i)))}.join(“\n”)

54 Latermuse November 16, 2012 at 11:47 am

Here is my solution in Haskell:

main = mapM_ checkX fizzList
fizzList= [1..100]
checkX x
| x `mod` 15 == 0 = putStrLn “FizzBuzz”
| x `mod` 3 == 0 = putStrLn “Fizz”
| x `mod` 5 == 0 = putStrLn “Buzz”
| otherwise = putStrLn $ show x

55 Edict of Nantes November 16, 2012 at 1:42 pm

I’m surprised to hear that you wait until the candidate is sitting before you to administer this type of filter. Most SF Bay Area startups do a technical phone screen after the preliminary phone screen by the recruiter. I have never encountered FizzBuzz, but I have been asked in phone screens to write functions to calculate the Fibonnacci series, reverse a linked list, scan a given text to see if it contains any words from a given list of words, return words from a given corpus that match a given prefix, etc… On site interview tasks can be much more difficult, including writing distributed programs.

I suspect as you grow and have multiple team members interview candidates on-site that you will start doing technical phone screens.

56 Rob Conery November 16, 2012 at 2:31 pm

I would fail that test. I would fail it for a number of reasons – the first of which is what *you* perceive to be a “good programmer”. I don’t want to sound negative, but I would urge you to reconsider what you’re doing. You probably sent some very good talent out the door.

Here’s my point: these are *people*, not machines! I find the attitude of “let’s see how good you are at writing this arbitrary bit of gotcha code under the gun” soooooo very Enterprisey, where arbitrary metrics can somehow convey what the worker will do for you.

I can’t tell you the number of programmers I’ve hired “on a hunch” – that didn’t know the basics of what I needed them to do. But I could see the light in their eyes, I could *feel* their need to WIN – and you know what? They were the best damn employees I ever had.

You know who were the worst? The ultra-geek engineers that could kick out FizBuzz in minutes.

I wish this mentality would shift. I just hired a person here at Tekpub who I now couldn’t imagine doing business without. You know what he was doing when I hired him? REAL ESTATE APPRAISAL. Why did I hire him? Because he was smart and motivated. He picked up *everything* I needed him to know with 2 weeks – and he did it on his own because he *wanted it*.

Anyway – sorry Joey if I’m coming off negative. I have a soft spot for these kinds of posts that translate to “OMFG Look how DUMB these kids are!”.


57 Patrick Helm November 16, 2012 at 2:44 pm

Quick && dirty incoming:{|e| (e % 3 == 0 && e % 5 == 0) ? “FizzBuzz” : e}.map{|e| e % 3 == 0 ? “Fizz” : e}.map{|e| e % 5 == 0 ? “Buzz” : e }

58 Michael G Schwern November 16, 2012 at 3:16 pm

The hypothesis is that 60% of your candidates don’t know how to do even a simple FizzBuzz, but there’s a lot of other variables going on here which make your experiment diverge from normal coding. The biggest are A) coding under observation, B) coding with an unfamiliar editor (ie. pencil and paper) and C) coding with a ticking clock. You want to your interview process to reveal how the candidates will do their job, not pass a test. You need a control experiment!

As a control, it would be interesting to see if your success rate changed if you allowed candidates to use a familiar text editor but no compiler, docs or internet connection. A bare laptop would do. Install a few popular editors, turn the network off and remove as many compilers as the OS will allow (or create a user with no access to them). That would control from the unfamiliar editing environment.

As for coding while being watched, you could simply leave the room, but then they can’t ask questions. They can also cheat with a smartphone. As a compromise, stay nearby and available but turn away and work (or pretend to) on something else while they code. Don’t face them, their back or their screen.

Finally, coding under a ticking clock adds even more stress to an already stressful process. Don’t tell them there’s a time limit. If they ask, make it very casual. “Oh, about ten or fifteen minutes. Let me know when you’re done.”

Comparing the results of the two different environments would prove interesting which ever way it goes. If the control results are no different, your conclusions are even more valid. If the control results are better, then you’ve discovered important environmental factors in interviewing programmers! If the control results are worse, that’s the most interesting result of all. The “huh, that’s not right” result from which all scientific breakthroughs spring.

59 Don November 16, 2012 at 4:12 pm

Writing code in an interview is nothing like the real world. I spent 12 years at Microsoft and I interviewed for internal jobs and I interviewed external candidates and white board coding is by no means a way to determine the future potential of a candidate. When I say this question I quickly had a solution in mind but then like @amy I totally forgot how MOD worked. After I looked it up it was easy to come up with a solution.

Imagine someone who comes in for an interview prepared to do something with trees or list and they get thrown something like this. It could really throw a person off and make them fumble. What’s is even worse is the Google/Amazon thing where they have you write code in a shared text editor. Not only do they expect you write the code correctly they are just sitting there somewhere in the internet watching you.

There are plenty of people at Microsoft who can’t get into other groups because they don’t pass the internal interview. Why is that? Because when you spend your time writing real solutions using libraries or tools and solving higher level problems with high level abstractions the low level coding is not something that is done. For example reversing a linked list, this is not something that anyone would write code to do in a real world project but these are the kind of questions that people ask in interviews. These kind of coding questions are best for college students.

I interviewed with LinkedIn and the guy asked me some question about graph coloring in a shared text editor. Needless to say I haven’t done graph programming in 15 years but these are the kind of questions people expect to be solved in an interview.

60 Joshua Grigonis November 16, 2012 at 6:31 pm

Most of you failed to follow directions, here’s mine:

It took me less than 1 minute.

61 R.T. Lechow November 16, 2012 at 9:36 pm

Don’t think the thread has a video yet, so here’s one of me test-driving FizzBuzz:

Clocks in at just over 3 minutes. Seems like there’s a level of detail that pen & paper might miss.

62 Wesley Kerfoot November 16, 2012 at 11:17 pm

@Joshua, most of the ones people posted seemed correct to me (except for the couple I couldn’t understand because they were in obfuscated ruby). Is there anything wrong with the solution I posted?

63 Prince Bhanwra November 17, 2012 at 7:33 pm

Came up with best this solution.. is thr any better..?

if( number%5!=0 )
if ( number%3!=0 )
print number\n
print fizz\n

if( number%3 == 0 )
print fizzbuzz\n
print buzz\n

No. of comparisons for all cases = 100 x 2 = 200

64 Mpondwe November 18, 2012 at 12:56 am

If this were a discussion about using the “mirror test” to filter candidates then it would be full of posters proudly linking to images of their foggy mirrors.

65 Andy B November 18, 2012 at 5:33 pm

To all those who say that it isn’t an accurate test: this isn’t some ‘gotcha’ test, or ‘low level’. Things like reversing linked lists – agreed, you don’t normally have to do that yourself – but I challenge you to program without loops, counters and basic arithmetic. And programming is done often under time pressure – the project manager usually wants it yesterday…

We administer a similar test where I work, and over the last few years I’ve had to review them. I have been shocked. I’m not expecting an optimal program – heck, it’s nice to talk about possible improvements after their explanation. I’m not expecting working code – pseudocode is fine. Dammit, I don’t even demand that it’s finished, as long as the candidate knows what they still have to do.

But I do expect some signs of logic, structure. I do expect control constructs of some form to be familiar. Often, even this isn’t evident. I can’t explain it, but there it is. I also have the experience of finding plenty of professional programmers who can’t program.

66 Don November 19, 2012 at 3:43 pm

I’m not saying the test isn’t accurate. But I’m not sure how accurate any coding test is to the future success of an engineer. I interviewed a lot of people using white board coding some did great on the interview some didn’t. It is really about how well you study going into the interview. There are tons of books that people read about passing interview questions and most people study them.

In reference to basic arithmetic… I haven’t used % in a program in years. So yes I think that will make people stumble.

I expect that people can do basic computer science stuff. Walk trees, string manipulation, knowledge of graphs but I don’t ask graph questions.

Also pressure to get work done at your desk is different than having someone stare at you while you write code.

Basically there is no real way to see if someone will do good in a job from an interview. I remember the time before most companies had you write code for an interview. When they used to ask you questions like… Whats the differnce between c++ new and malloc? Even then the ratio of good to bad developers was still probably about the same. As interview questions change the interviewees also change to meet the challenge.

It comes down to gut feel.

67 Jim Myhrberg November 23, 2012 at 10:50 am

I recall reading briefly about the FizzBuzz test at some point years and years ago. After reading your article though I figured I’d actually give it a go with pen and paper. Specially due to the fact that I’ve used a pen maybe 15-20 times at most in the past 12 or so years, so I thought it’d be fun.

Here’s what I came up with after 2-3 minutes:

(1..100).each do |i|
o = “”
o << "Fizz" if i % 3 == 0
o << "Buzz" if i % 5 == 0
o << i.to_s if o == ""
puts o

And here's a shot of the paper version in all it's horrible hand-writing glory:

68 Abhinav February 27, 2013 at 5:55 am

This kind of questions separates programmers from non programmers, another one I like is swap two numbers without temp variable

69 Tyson March 13, 2013 at 3:39 pm

private void FizzBuzz() {
for (int i = 1; i <= 100; i++) {
string add = "";
if (i % 3 == 0) {
add = "fizz";
if (i % 5 == 0) {
add += "buzz";
if (add==""){
add = i.ToString();
this.TextBox1.Text += add + "\r\n";

I can't believe there are people in these comments who are claiming this test is unfair. I could have written this when I was 10 years old..

Leave a Comment

{ 16 trackbacks }

Previous post:

Next post: