FizzBuzz - really?

Question

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?

Really?

What is the evidence to back this up?

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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!

Answer 5

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.

Answer 6

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

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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?

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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 examples can be seen here

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.