Take the 2-minute tour ×

When it comes to "interview test" questions, the subject of FizzBuzz often comes up. There is also a Coding Horror post about it.

Now, if you bother reading sites such as this, you are probably less likely to be in the demographic of programmers who would find FizzBuzz anything but trivial.

But is it really true that 99% of programmers will struggle with it?


What is the evidence to back this up?

Some real-life examples would be very helpful in answering this question.


locked by World Engineer Sep 21 at 21:19


closed as primarily opinion-based by World Engineer Sep 21 at 21:19


It's not 99% of programmers, it's 99.5% of applicants (many of which are not programmers). –  webbiedave Oct 29 '10 at 17:52
I didn't believe it until I got it on an interview- I later got the job, and later still chatted with the ceo about it. Apparently 99% is about right. O.o –  Fishtoaster Oct 29 '10 at 18:19
I always thought fizzbuzz questions were a myth, or maybe just for fresh-out-of-college beginners, but then one day I actually was asked at an interview. Yeah, do many candidates really have trouble with this? –  DarenW Nov 12 '10 at 16:39
I routinely give out the FizzBuzz test at interviews and routinely have people fail it. One graphic designer passed it one day though..... Surprised me a bit :) –  Brandon Wamboldt Nov 13 '10 at 3:05
@Rogue Coder - Hey, we're not stupid, just weird. And most of us suck at math. –  Inaimathi Nov 13 '10 at 3:09

16 Answers 16

99%? No. A significant percentage? Yes. From my own direct experience of interviewing people I can testify to this one. It might seem insignificant to you but there are a lot of people in the programming field who have more or less faked their way through for years and apply on non-entry level positions and fail this one.

Even if you CAN easily solve it, but you give me huge static about being asked to do such a menial task will count against you. Being on a team means having to sometimes do things you might not enjoy but are necessary. If right off the bat, before we've even started to work together you think it would be best to try and assert your special status of being above doing something I've asked you to do then it will act as a mark against you.

I don't care necessarily how elegant your solution is (although that would be nice) but seeing you take a stab at it on a whiteboard and talking your way through it shows me that you're at least willing to take a stab at it. If you get indignant and say something along the lines of "I'm a problem solver, not a code monkey!" then you will be knocked down a peg.

I have had interviewees just flat out refuse to even begin to attempt it. Just simply refuse. No. Uh uh. Won't do it. I ask one or two more polite questions, thank them for their time and close the interview off.

I say this as a manager and as a developer.

What are their grounds for refusing to attempt it? –  Jon Hopkins Nov 12 '10 at 16:46
I never directly asked them. After their second refusal I would ask a couple more questions and then close the interview out. If I was going to GUESS it would be that they were too nervous to try (if I'm being charitable) or that they cannot in fact figure it out on the spot (if I'm being more cynical). –  Todd Williamson Nov 12 '10 at 17:04
I know a guy who refuses to code in interviews. He also refuses to commit to memory anything he can lookup in a few seconds of Googling. He's a "problem solver". –  kirk.burleson Nov 13 '10 at 1:39
Then again, whiteboard coding is a problem that the interviewer gives to you… that needs to be solved, perhaps? To me refuse to code in the interview is equivalent to refuse solving a problem that the interviewer has. Hence contradiction to the term "problem solver" and it's more like the guy is a "problem refuser". –  Spoike Jul 7 '11 at 6:56

I think that 99% of programmers who apply for a job (and don't get it) may struggle over it. But not 99% of programmers that are productively holding a job.

That's the nature of our modern job-seeking process. Many people who apply are not qualified.

That Coding Horror post also speaks to the way we teach Computer Science nowadays. In the past (particularly at MIT), you were required to learn things like Lisp, which pretty much requires you to grasp concepts like recursion.

Nowadays people are taught Java because it is widely used in industry, and the focus has shifted to syntax rather than deep programming thinking. I don't dislike Java; in fact, I think it's an ideal first programming language. But I have not seen my instructors teach deep programming principles with it.

Yeah I think our education system (at least in the US) is a big part of this. I know someone who got a 2-yr degree in Software Programming, graduated with honors, and couldn't read or write code. –  Rachel Oct 29 '10 at 17:22
The argument against teaching Java is a weak one. Concepts can be taught in most languages (recusrion is easily written in Java for eg). I don't disagree that teaching of the concepts taught are getting weaker, but I don't blame it arbitrarily on the implementation language. –  Steve Evers Oct 29 '10 at 17:42
Oh things like Recursion get taught, they just don't get used. You get the same grade for writing a 100 line IF statement as you do for writing a recursive function (at least you did where I went), and the 100 line IF statement is easier to write when you're in a hurry (i.e. you've skipped doing your homework until 5min before you need to turn it in) –  Rachel Oct 29 '10 at 17:47
@SnOrfus: Nor do I blame it on Java. I didn't make an argument against teaching Java. Yes, you can teach these concepts in Java, but I haven't seen that happen, not in the Java classes I took, anyway. That said, MIT originally chose Scheme for their introductory programming classes, because it has a very simple syntax, so you begin thinking about programming concepts early, without having to focus a lot on the language syntax. –  Robert Harvey Oct 29 '10 at 17:49
Who on earth goes to a university where they "teach Java". Programming language schools are less than useful (regardless of it being Java, C++, Lisp or whatever); is that what you have in the US? Where I studied CS, you more or less taught yourself the prog language as required (an exception would be the Paradigms class, I guess). University courses taught math, CS theory, multiple programming paradigms, calculus, etc. Anyone graduating from that can easily solve FizzBuzz, because we had to solve harder problems just to pass the courses. –  Andres F. Nov 14 '12 at 15:29

I hate to say this but

The main reason I've seen programming questions fail to get answered is the fault of the asker rather than the answerer.

I can clearly remember one interview where I was being asked how to create a particular collection search algorithm that would run in constant time (Same number of look ups regardless of how many items in the collection). I fumbled and bumbled on it for 20 minutes before giving up. It was then that this genius doing the interviewing proceeded to demonstrate the answer as being something that operated in nearly constant, but still not constant time. A bit like saying "Give me an answer of zero" and then accepting 0.1.

Short of it is that I've seen too many cases where someone interviewing is asking a question that fails to meet the following criteria:

  1. They know all the possible correct answers.
  2. They know why the correct answers are correct.
  3. They know how to actually provide enough information without giving the answer away.
  4. "Problem solving" questions do not rely on knowledge of an undisclosed fact (this is the biggest issue I've seen).
  5. It would take less than 1 minute to write the answer if you didn't have to figure it out. If it would take 5 minutes just to type the code, it really requires more problem solving than can be fit into the verbal portion of the interview.
  6. Questions are based on more than just "A problem I ran into once or I was given in school and so you should know how to solve it right now". I'm going to bet you had more than 2 minutes to answer it, why aren't you giving the candidate the same courtesy.

Seriously (1), I think asking people to write code in the verbal portion of an interview is stupid.

Seriously (2), I think interviewing people without asking them to write code is also stupid.

Seriously (3), You should either give them "homework", ask them to bring in code samples, or give them a laptop and couple of questions and quiet office to work on them. Then leave them alone while they work on them. I usually go with the latter approach as it limits their ability to get outside help (cheat) and I can time box it.

@Nemi - Yes I did. The person in question wasn't one with hiring authority, but I did get an offer on the position. –  MIA Nov 15 '10 at 1:28
int? result; for (int i = 0; i < int.MaxValue; i++) { T item = (i < array.Length) ? array[i] : someDummyItem; if (item == whatWereLookingFor) result = i; } return result; - constant time :) –  configurator Jul 7 '11 at 0:31

All you need to do is search on FizzBuzz. There was a huge wave of blog posts on it. Generally speaking the blogger said "I told people to write it in [some language] and here are the kinds of mistakes they made:" and then listed some pitfalls. The fun starts in the comments where people say "ha! that's trivial in [some other language], all you have to write is this:" followed by code. The next comment invariably finds bugs in that first one. Seems like some very good devs don't get it right the first time, in any language. Some of the errors:

  • I asked for 1 to 100 and you did 1 to 99 or 0 to 99
  • messing up on whether to print the number along with fizz and/or buzz
  • disagreements on "fizzbuzz" vs "fizz-buzz"
  • missed optimizations, like comparing twice when once would do
  • lots more

When I'm hiring, I ask people to code at the whiteboard for me, nothing anywhere near that complicated (I know, you don't think it's complicated) and many candidates fail utterly. I mean like writing vb-style If, Then, End If but putting braces as well (just to be on the safe side I guess) or writing C# (and asking first, C#?) but having not one semi colon anywhere. Don't start me on logic errors!

@Jeff most devs first write something that would not compile. The good ones take a look and fix simple syntax errors. Stressed out good or calm ok programmers write a function but no code to call it, write something that isn't super optimized, suffer (and don't spot) an off-by-one, or may miss a syntax error or two. Horrible programmers write code that is nowhere near compilable, does the entirely wrong thing, etc. For example looping to 3 or to 5, since those are in the question, instead of looping to 99 or 100 or 101 (ish.) Or even no code at all. You really can't believe it till you see it. –  Kate Gregory Oct 29 '10 at 22:32
If {"If {} Then {} EndIf" qualifies as failing utterly} Then {Your interview style is defective and/or you're amazingly lucky to be able to dismiss a candidate on such a trivial basis} EndIf –  Sparr Oct 30 '10 at 9:46
I program in at least a dozen languages on a monthly basis. Sit me down in front of a computer and ask me to work in one that I haven't touched in a month and I'll make mistakes like that for the first five minutes while I get back in the groove, usually having my mistakes pointed out by the compiler or interpreter. –  Sparr Nov 1 '10 at 1:06
@Sparr - sure. So at the whiteboard if I ask you to look it over, you'll probably spot it and say "oops - I use a lot of languages." If you don't, I'll say "what language did you write that in?" and then you will. It's not a trick question or a trap. Some people have actually never written code and claim that they have. That's the point of questions like this. –  Kate Gregory Nov 1 '10 at 10:31
But I think those questions aren't good for that. I couldn't tell you, five minutes before this comment thread started, whether VB required braces around code blocks. I could have told you that If/Then/EndIf looked mostly like VB[.Net]. And I write code in VB for ... about two hours every three months (rentacoder.com tasks, I never take real VB jobs, I hate it). –  Sparr Nov 3 '10 at 4:28

I've read the Coding Horror article you mention, and my opinion is that Jeff is right... but when is the last time he got interviewed?

When you are interviewed, you are usually in high stress, and you often have to answer to theoretical questions (no intellisence, no google, no resharper, ... only your memory troubled by stress). That's the same in tests. Stress doesn't help you.

I've noticed that the only way to know if someone is suitable for a position is to work with him for a while... Just take the last 10 persons you hired out of 100 (maybe more), how much was a really good hire???

An employer should hire a problem solver, not a code monkey that know about modulos.

You can't test "for a while all applicants", so interviewing them is required. That's why I focus my questions on that (problem solving) and do past reference check.

My opinion is that the FizzBuzz is dangerous for the company that is looking for developers to substain its growth.

IMHO the problem here is that FizzBuzz is such a lowball question that if you can't answer it even under stress you deserve to have people laugh in your face if you call yourself a "programmer". If it was something slightly more complicated, like "implement a bubble sort", then these excuses and concerns would be justified, but not for FizzBuzz. –  dsimcha Oct 29 '10 at 17:38
Fizzbuzz is good at what it's for: filtering the people who know nothing from the people something. And knowing something may still not be enough to do the job. It's not a hiring decision test, it's a "are you going to be wasting my time in an interview" test. Some hiring managers try to take fizzbuzz too far to have it do their job for them. –  Steve Evers Oct 29 '10 at 17:40
My goodness, modulo is not some sort of esoteric operator. It's a core operation that all developers must have experience with if they wish to call themselves professional programmers. Regardless, if someone can write FizzBuzz it doesn't mean you hire them. It's just a quick starting point to see if this person can even attempt to layout the control flow needed to complete the task. –  webbiedave Oct 29 '10 at 17:40
I think that FizzBuzz is useful simply because it is so mind-bogglingly trivial. It requires a for loop, two if statements, modulo and print. Anybody with any meaningful programming experience should be able to bang it out while hardly a thought. If someone struggles with it in a interview, I consider that a perfectly valid litmus test. –  Adam Crossland Oct 29 '10 at 18:16
@snorfus: Filed under "somebody else's problem." I'd much rather miss the boat on one good developer with crippling social anxiety than waste precious time and money training and waiting for results from somebody with no aptitude for programming. Can't handle yourself around other human beings? See a therapist. –  Aaronaught Oct 29 '10 at 21:11

I was recently tasked with interviewing over 50 programmers for a senior position where they would be working mostly with PHP.

I tossed the fizzbuzz problem on the screening exam, mostly to amuse myself and because I wanted ten good questions and had only nine. My intent, at the time was to show people that we can have fun too, even on interview questions.

80% Of the applicants solved the problem, but did not use the modulus operator.

15% of the applicants could not solve the problem.

5% of the applicants solved the problem using the modulus operator.

While my sampling is quite limited (50 applicants from one country), I can tell you that:

95% of them had a BS or higher in a CS curriculum (universities here compete by trying to make CS sound more spectacular).

I was truly amazed. Well, frightened .. but amazed. I did not think I'd come close to reproducing the results, since the problem has become so popular. This shows me that 5% of my applicants might not be super programmers, but at least they read programming related blogs.


In my last round of hiring I had 3 construction workers with 0, I repeat zero, programming education or experience apply for a software developer position.* So that's the bottom of the barrel. If you assume a normal distribution of skill, then you can see how the average skill level will be quite low and even 'above average' (amongst applicants) will still be relatively bad.

Now, if you're fizzbuzzing only the applicants that had what appeared to be some programming ability, you'll find that you now have:

  1. liars
  2. buzzword enthusiasts (I read an article about .NET once)
  3. bad actual programmers
  4. people who used a technology to complete a project, but didn't learn about it (see fizzbuzz questions about idisposable to identify these)

Additionally, some 'fizzbuzz' questions that I've seen are domain specific. You can progressively develop with a language/framework x for a number of years (hence z years experience with x) and not have come across certain parts of it (library developers not knowing much about UI component development for eg.)

Likewise, lots of developers do maintenance development these days, so their architecture/design skills may be weak in some areas.

Now, I'm not sure if 99% is accurate, but IME it's still pretty high. At least in the 80% range.

* No, we didn't call or even give a second look at these applications.

We had a similar situation, but since our contract with the client said we'd have 4 full-time devs assigned to the project, and the project was basically done, the sheetrock hanging guy got to learn programming on the client's dollar for the 3 weeks remaining on the contract. –  Tangurena Nov 13 '10 at 3:41

Yes really. Probably not 99% but still pretty high. I used to interview computer science students for internships and full time hires. I'd interview about 25 students at a college. We were told not to ask the same questions, because the students talked. I quickly learned that it didn't matter, because I would only get 3 or 4 students out of the 25 who could answer my first question. "Write strcmp"

I asked them to write a function to compare two strings. Maybe to use the function to sort words for a dictionary. You would be amazed at the number of students who didn't understand how to compare two words, let alone know how to write the function. And some of these students claimed they got all A's in CSc.

The thing is programming is VERY DIFFICULT. A lot of people like to think they know how to program, but they don't.

Grade inflation sucks, wastes time for everyone! –  DarenW Nov 13 '10 at 0:45

Some thoughts:

  • I wouldn't hold it against someone if their program had some bugs but they clearly had the right idea. Debugging is part of programming.

  • I think it is sad that so many people are applying for jobs they don't know they can't do. Seems to me like a problem with the economy.

  • It is really easy to ask people bad questions, where the only "correct" answer is the one the interviewer would give.

About the 2nd point... having spent a lot of time contemplating my next career move, studying various industries, and job-hunting, it was a major difficulty trying to assess my own level of competence at many different things. Apparently this is a big, big problem for (nearly) everyone. –  DarenW Nov 13 '10 at 0:43

This test very nicely covers several things I want to know about a programmer I might hire:

  1. Can you even program at all?
  2. Can you write a program from scratch (because not everyone can!!!)
  3. Can you solve a problem without over-thinking it.

To elaborate on the last point, there are countless solutions to fizz-buzz. Do you go for readability? Speed? Brevity? Do you try to finish writing the program quickly? How a programmer attacks this simple problem is very telling. If a programmer can't pick a solution and see it through to the end, what does that tell you about how this person will perform on a real task?


Unfortunately, many people with impressively looking resumes do seem to lack basic programming skills. I have seen many cases when people who list C and C++ on their resumes could not answer basic questions about pointers.


There are two types of people I would hope that FizzBuzz would help me avoid.

  1. Chancers with no knowledge of programming or no relevant knowledge of programming. Usually you can recognise these from the CV but not always and giving them a simple programming task is a good way of making it clear that they are not a programmer.
  2. Java school grads, who have completed a programming course or degree but don't actually know how to program. These people can be harder to filter out because they can talk about theory but they just have no practical skill. Putting a simple problem in front of them and asking for a solution and an explanation of the solution is a pretty good way of seeing the difference between a Petra Java and a Paula Bean.

In either case, I don't really care about a perfect implementation. The test that you need to make with people applying for developer jobs is that they can program at all.

That said, I would probably not bother with that particular test for several reasons now. Firstly it's very well known and either of the above groups would be quick to try it. Secondly I would prefer to use Steve Yegge's phone screen questions to screen out non-programmers before we got as far as bringing them in. If someone recognised those questions it would imply they had read Steve Yegge's blog which would suggest to me they were in the top 1% of developers who take their profession seriously and certainly warrant an interview. Likewise if someone had some good rep here or on SO I would be inclined to interview them.


It's hard to believe that developers can't code FizzBuzz until you see the "nine-to-fivers" that copy and paste their work together and conciously try not to write code. I couldn't believe it when I heard one of our senior developers teaching a C# developer, with 3 years "experience", how to use a Dictionary. Interfaces? Design patterns? stdout? YAGNI? My lead had never heard of YAGNI! It's amazing what these people don't know.

I believe it now. I also think there's too many developers just doing enough.


I think part of why it is such a popular question is because there is more then one way of answering it, and depending on which way the candidate chooses to go can give you an insight about how they code. Some great examples can be seen here if you have 10K rep on Stack Overflow.

As to the 99% statistic, check where that number comes from. It is probably biased. If it is based off entry-level programmers interviewing for their first job, then yes I can see that being possible, especially if the majority of their candidates are coming straight out of college. I can actually think of someone who probably would write out a 100 condition if statement as a solution to that problem.

I suspect that the figure 99% points to the truth (the recursive truth, no less) of the statement that 87% of all statistics are made up on the spot. –  Adam Crossland Oct 29 '10 at 18:13
@Adam Crossland: 100% of statistics about statistics are made up on the spot too. –  Macha Nov 13 '10 at 16:18
@ironcode I went to school with someone who couldn't even begin to comprehend fizzbuzz... I'd be surprised if they could even write something that printed out 100 lines with the fizzbuzz values hardcoded. They graduated with honors. –  Rachel Sep 2 '11 at 14:24

I find the statement that 99% of the programmers are unable to program or to solve a simple coding test highly exaggerated. In the case of the FizzBuzz test, either you have encountered this problem before and can easily solve it with the modulo operator or you have not encountered it before and will struggle with it. It tells the interviewer nothing about your programming skills.

I think the problem with many programmers apparently leaving a bad impression at an interview lie in the nature of technical interviewing methods. Interviewers expect applicants to memorize and instantly reproduce language syntax, details and computational complexity of data structures, hardware architectures, design patterns, etc, etc. The area of computer science/software engineering is vast. It is impossible and insensible to try to memorize everything.

In the real world, the key is to be able to understand the programming/design problem assigned to you and to know where to find information(your IDE, man pages, books, google, etc) how to solve your problem. This is something however that interviewers never test for.

Do you realize how easy FizzBuzz is? You don't need to have encountered it. If you struggle then consider a career change. –  John Smith Apr 15 '11 at 14:50

I am still a relatively junior programmer (I have been coding for money for ~2 years and coding in some professional capacity as a side-responsibility for about 2 before that) so use sufficient grains of salt.

I have some experience doing a first screen for coders for a Large Enterprise Project (we kinda knew the project was doomed, but hey, they wanted to pay anyways). As the only programmer at the firm doing the hiring I was given the task of reviewing resumes and screening applicants.

This was for a government project so it perhaps probably didn't attract the most talented applicants, but I did not receive one application from anyone with a github account that actually had code shown, nor anyone who had a portfolio, so I used fizzbuzz (literally the exact problem) as a first pass on anyone who looked like they might be able to program.

I prefaced it with a pseudo-apology stating that I knew it was stupid but that I just wanted to see any working code, and if they wanted they could send another example of equal or greater value or really anything, but that fizzbuzz would suffice.

The result: I didn't get one response that was actually correct, which is mind-blowing considering the volume of answers on the internet. No one even bothered to plagiarize. We had to just go with hiring people who had previously worked on the failed previous iterations of the project.

After the initial shock of the exercise and disappointment about how screwed government software/contracting was, I felt much better about my own skills, so small victories?

Edit: By not correct I don't mean an off-by-one error (i.e. I asked for through 100 not 99) or some other innocent bug that is an easy fix. I mean not functional, either won't run/compile/etc or showed clearly that the problem was just not read and understood, also a significant portion withdrew the application and not one sent some other code instead.


protected by MichaelT Sep 21 at 19:55


Would you like to answer one of these unanswered questions instead?
