Categories
Process Programming

FizzBuzz Still Works

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!

99 replies on “FizzBuzz Still Works”

I always like to look for silly solutions as well as an efficient one :)

#!/usr/bin/perl
use strict;
use warnings;

# “proper” solution
for (my $i=1; $i<=100; $i++) {
my $out='';
$i%3 or $out .= 'Fizz';
$i%5 or $out .= 'Buzz';
$out||=$i;
print "$out\n";
}

# silly solution
my @three = ('')x3;
my @five = ('')x5;
$three[0] = 'Fizz';
$five[0] = 'Buzz';

for (1..100) {
push @three, shift @three;
push @five, shift @five;
print $three[0].$five[0] || $_, "\n";
}

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.

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.

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”)

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

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.

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!”.

/rant

Quick && dirty incoming:

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

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.

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.

@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?

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

if( number%5!=0 )
{
if ( number%3!=0 )
{
print number\n
}
else
{
print fizz\n
}
return
}

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

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

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.

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.

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.

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
end

And here's a shot of the paper version in all it's horrible hand-writing glory: http://cl.ly/image/032h1C2u0h3L

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..

[…] With the initial interview out of the way, it was time for a little programming test. For developer advocates, this is a less difficult test than for those who do actual production coding, and in an attempt to ramp up my skills and build a portfolio, I’ve been doing at least an hour of iOS coding after work on most days. The purpose of this test was to see if I could code at all, and he would’ve been well within his rights to hit me with FizzBuzz. […]

Am 11… Wrote FizzBuzz in python and it took about 2½ mins… Heres the code:
————————————————————————————————————–
import time
import os
os.system(“clear”)
for i in range(100):
time.sleep(0.2)
os.system(“clear”)
x=i % 3 == 0
z=i % 5 == 0
if x and z==True:
print “FizzBuzz”
elif x==True:
print “Fizz”
elif z==True:
print “Buzz”
else:
print i

Happy to have come across this.
My Code…..

#include

int main()
{
int a=0;

for(a=1;a<101;a++)
{
if(a%15==0)
printf("FIZZBUZZ\n");
else if(a%5==0)
printf("BUZZ\n");
else if(a%3==0)
printf("FIZZ\n");
else
printf("%d\n",a);
}
return(0);
}

Because Swift is the new guy on the block:

func fizzy(n: Int) -> String {
switch(n % 3 == 0, n % 5 == 0){
case (0,0):
return “FizzBuzz”

case (0,_):
return “Fizz”

case(_,0):
return “Buzz”

default:
return “\(n)”
}
}

for i in 1…100 { fizzy(i) }

// AND In C#

String fizzy(int n){
var s = “”;
if(n % 3 == 0) s += “Fizz”;
if(n % 5 == 0) s += “Buzz”;
if( s == “” ) return n.ToString()
else return n + “!”;
}

for(x = 1; x <= 100, x++){
Console.Out( fizzy(x) );
}

The C# could be written more efficiently.

I wrote a pretty quick one in python.

for i in range(0, 100):
if i % 15 == 0:
print “fizzbuzz”
elif i % 3 == 0:
print “fizz”
elif i % 5 == 0:
print “buzz”
else:
print i

I’m always stunt to read about people who are objecting to FizzBuzz test.
Common guys, seriously?
It’s the simplest test there is, it’s a loop with two or three conditions (depending on your approach) and a modulo operator. I don’t get how can anyone object to this?

It’s like a carpenter saying to his candidate stick a nail in a wood, I would presume that the candidate should know what a hammer is and how to use it…
If he doesn’t then what, well according to Rob’s comment if he’s smart and motivated you’ll hire him anyway, right? Are you serious man, so you would hire someone that doesn’t know the pure basics of the job he applied because his smart and motivated so he will pick that up in no time?
Well consider this, what if I hire someone that’s smart and motivated and knows a thing or two. I don’t have to wait for this guy to learn the fundamentals, I can delegate some advance tasks to him straight away and that guy will actually do what he is suppose to do and get paid for it.

Also to Don who mentioned that he forgot how the MOD works, are you kidding me? So if you would not use any additions and subtractions for N years would you forget about them as well? The modulo is really a basic operator and I’m sorry to say that if you forgot how it works then I would be very concern about what else you forgot.

I believe FizzBuzz or better jet a variation to FizzBuzz test is useful even today and I believe they are excellent at detecting those coders that can only code out by googling. But I would just like to add (as “Edict of Nantes” said in the comments), I think that this threshold testing should be conducted as early as possible to avoid unnecessary lost of interviewer’s and candidate’s time (as an example of this I would suggest you to take a brief look at TestDome: http://www.testdome.com/)

String fb[] = {
“FizzBuzz”, null, null, “Fizz”, null “Buzz” // etc, upto 14
};

for(int i = 0;i<=100; i++) println(fb[i%15]==null?i:fb[i%15]);

I am also very surprised that only one your candidate ever heard about FizzBuzz – it’s really super popular task. I thought everyone knows it.
I agree that on live interview you better give candidates to write code on paper rather than machine since it forces them to take all the decisions from the brain instead of Stackoverflow.
What you can do before interview is to test developer with the programming skills test like https://tests4geeks.com. It will allow to avoid big number of interviews in your office and save time.

[…] With the initial interview out of the way, it was time for a little programming test. For developer advocates, this is a less difficult test than for those who do actual production coding, and in an attempt to ramp up my skills and build a portfolio, I’ve been doing at least an hour of iOS coding after work on most days. The purpose of this test was to see if I could code at all, and he would’ve been well within his rights to hit me with FizzBuzz. […]

Comments are closed.