Are most applicants really unable to implement FizzBuzz in an interview?

Question

Are a large proportion of programming job applicants unable to implement FizzBuzz (or a similarly simple task)?

On the blog Coding Horror, Jeff Atwood quotes individuals as saying that a large number of programming job applicants are unable to implement FizzBuzz. Why Can't Programmers.. Program?

[Quoting Don't Overthink FizzBuzz]

Like me, the author is having trouble with the fact that 199 out of 200 applicants for every programming job can't write code at all. I repeat: they can't write any code whatsoever.

The author he's referring to is Imran, who is evidently turning away lots of programmers who can't write a simple program:

Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".

Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes. Want to know something scary? The majority of comp sci graduates can't. I've also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.

This question was partially prompted by this unanswered skeptics exchange post .

Is there something wrong with our colleges? Are people panicking? Is it a good thing to ask in an interview?

Answer 1

Yes - and that makes the exercise useful for the interviewer!

I've been on the hiring panel for Software Engineering jobs, and programmer applicants straight out of uni are universally unable to do the following:

• Write FizzBuzz (or a similar simple program.)
• From only the specifications alone, without any help from the interviewers
• In the programming environment of the company
• In under 15 minutes.
• Without Googling.
• And have it compile without errors.
• And run correctly first time.

... and that's a good thing because "How good a programmer you are" isn't the main focus of what we're testing for in an interview for a programming job - we want to know how good a programmer you'll become. It's going to take you 3 months to get up to speed (learn our libraries, standards, etc), we want to preview how good you'll be in 3 months by watching you fail and learn. If everyone got it in 5 minutes it wouldn't tell us anything useful about the interviewee. We want to see you try, fail, investigate the failure, ask for help, debate ideas, take advice, and work with the interviewer to develop the software together.

After explaining FizzBuzz to an interviewee, we explain that we're here to help and bounce ideas off. The interviewee will then attempt to write the code using multiple if statements. They'll usually predict the mod 15 case, but will mess up something trivial (like it may print the number after FizzBuzz, or there'll be a missing newline, or such), or it wont compile. 50% of the time they'll spot their error(s) and fix it within a few attempts without help.

When they really screw up, its usually because their uni taught them Java or something, and we were looking for a C++ developer. We do say that C++ experience is preferred but not required, so there's often questions asked about syntax, or cryptic compiler errors. We want you to ask these, it helps us understand how you think.

If they do get it too early without help, we'll try to make the challenge harder. "Excellent; Now do it with only 1 print statement.", or "Now do it without duplicating Fizz and Buzz for the FizzBuzz case", "Now do it without using an 'if'", "Now do it without an if or a '?' operator."

We need to see you solve a problem to figure out how good a developer you'll be. Most people will get FizzBuzz wrong first few attempts, spot their mistakes, and fix it on their own. That debugging and reasoning and diagnostic process is what we want to see, and if we see that, and you can communicate with the interviewer about your problems, issues, and ideas, then you'll get through to the next round of interviews.

The FizzBuzz exercise is also really an ice breaker. We'll get you on harder problems within 15 minutes. We just want to get a feel for your problem solving ability.

Answer 2

There is a deeper phenomenon here:

The majority of applicants for any given job are below average

That sounds counter-intuitive, right? But, think for a moment.

• Good applicants get jobs quickly. They go for an interview, maybe two, they have a pleasant chat with the interviewer, they answer the questions correctly, they get an offer.
• Bad applicants interview over, and over, again, until they find an employer whose application process is loose enough to take them on.

So suppose you have:

• 10 good applicants, going to 2 interviews each before getting a job.
• 10 bad applicants, going to 20 interviews each before getting a job.

That's 220 interviews total, and 200 of those interviews are with a bad candidate.

Now imagine you are a company doing 10 interviews total. How many bad candidates will you see?

So, the figures given don't seem unrealistic to me, but they are representative of graduate applicants for a given job, not of all graduates.

Answer 3

While I agree with most of the existing answers, this is another issue:

Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes.

Many good programmers are not very comfortable with paper programming. Yes they should be able to explain and develop an algorithm on paper, but they might feel out of their comfort zone when they need to actually program with somewhat correct syntax on paper. This is more a behavioural instinct that gets in the way than a sign of not being able to program. They are instinctively programmed to type on a keyboard and get the "unimportant stuff" added automatically, it's awkward and just may take some time to suddenly go back to doing everything manually. So at least they might get slower and be distracted by the challenge to remember the correct syntax. While paper tests often are not about correct syntax (and good ones imho never should be), that impression might come across easily and startle the candidate. So, if you design your paper tests badly the likelihood you will see people struggle that would normally perfectly fit for your programming job also increases.

Answer 4

I feel like Joe's answer is enlightening in that it does explain that the pool of interviewees thins out naturally due to the fact that a good candidate can find a job quicker than a bad candidate.

My response is aligned with Ash's in that this is a simple problem solving exercise.

I've conducted interviews at my current employer for several years now, and the ultimate goal and objective that I have is that I want to see: if I give you a problem and some resources to approach it, are you able to solve it, or do you freeze up?

FizzBuzz is beloved (or loathed) for the ability to gently introduce the notion of, "how do you solve a problem?" It eliminates any contextual awareness or notion of state, and it makes the environment or frame of reference entirely sterile and uniform. Everyone gets the same question and gets to answer it in their own way. There's enough pitfalls in it that some interviewers could isolate a form of "talent" or a form of "oh, this person can solve a problem".

While I emphatically disagree that FizzBuzz is fit for the purpose of problem solving - I've only ever used it once and immediately regretted it - the bigger and broader question that the article is addressing is that graduates may not know how to problem solve.

Having done this, my specific answer to this is anecdotal, but the real issue isn't that applicants don't know how to program. It's that applicants don't know how to problem solve, and they fill their resume with all of the signatures and finger prints of having solved problems, but when pushed on those fronts, their achievements ring hollow.

Programming can be taught; it takes a period of time with the right resources and an environment that facilitates education for that to happen or manifest itself. Problem solving is more nuanced in that there's no formula or pattern that can be applied; unlike FizzBuzz which is really there just to weed out people who don't know how to use modulo (which - again - can just be taught!), asking an applicant to solve a problem or how to approach a problem is the ultimate crux of interviews.

We get a lot of graduates who have relied on writing code as a way to get their degree, but when faced with the prospect of actually solving a problem, they crumble.

Answer 5

This isn't necessarily meant to contradict the existing answers about selection bias or performance anxiety. They're good. But I want to address a specific part of your question:

Is there something wrong with our colleges?

Yes. Or no. Depends on perspective. But I'm going to relay two conversations that I had in the last few years with two different computer science undergrads that may shed some light on this. Names (other than mine) have been changed for privacy of the participants.

"Greg" was a compsci undergrad at Purdue, which while perhaps not quite on the level of a Stanford/MIT/CMU is still pretty high up there in terms of US compsci programs (top ten?). If you asked Greg at that time about what his favorite language(s) was/were, or what personal projects he was working on, he could talk your ear off about it. I privately coached Greg in sports, and we had a lot of great tech conversations as well.

"Bob" was an undergrad in compsci at Podunk State that I wound up by chance sitting across from at a dinner for an unrelated activity about the same time. When it came up that he was a computer science student, I being a software engineer immediately started to ask the same sorts of questions I mentioned above, both because it makes for interesting conversation and also to see if I could nudge him into the recruiting pipeline. It became very apparent very quickly that Bob had never written a line of code in his life that wasn't for a class assignment. You might chalk that up to him not being very interested in programming, but based on other clues in the conversation it seemed more that he thought excessively inside the box. He did what he was told, the idea that he should have his own interests seems to either have not occurred or was more likely beat out of him at some point.

Greg has never applied for a job in his life. Any job. He didn't work in high school, he was recruited to be an intern by a prestigious household-name NYC company, then got a job offer as a data scientist for said company, then worked part time for them while finishing his degree and now works full time for them.

I lost track of Bob but Bob almost certainly graduated with a real-life CS degree from a real-life university. And given the burgeoning demand for software engineers he probably found some job, somewhere. But it must have been a struggle: I certainly wouldn't have hired him.

We often say the degree or the institution doesn't really matter. And to a large degree that's true: my degree isn't even in Computer Science, and I went to the same university as Bob. But the person matters a lot.

Except for top-tier programs universities in the United States do not do a good job of policing this. You can skate by doing C-level work in a mediocre program and still graduate and the university's incentives are totally in favor of letting you do just that. But the real problem is more subtle: people who are only capable of at best C-level work can skate by and graduate. And perhaps in a narrative discipline you can get away with that when you get to the real world too, but we expect people to code, hence fizzbuzz.

Greg can give you fizzbuzz as fast as he can write it, in multiple languages. Bob could probably do it with help, and it wouldn't be pretty, and that's in his language of choice. Ask them to write it on paper, give them an IDE (Greg doesn't even bother to use an IDE), doesn't matter.

So US universities create some of the problem by accepting and then graduating individuals who just can't cut it in industry, and whether that's their fault or the student's or the parents' is more of a philosophical question.

I also suspect but cannot prove that a lot of the debate about whether or not the US has a STEM shortage revolves around this point: employers unable to find qualified candidates say there is one and unqualified graduates who can't find a job say there isn't.

Answer 6

Are a large proportion of programming job applicants unable to implement FizzBuzz (or a similarly simple task)?

Yes. I can't think of a single client, friend or my own interview process that was not plagued with that issue where simplest of technical tests, without access to google the answer, do not sieve out majority of candidates.

Are most comp-sci graduates really unable to implement FizzBuzz in an interview?

That I don't think is possible to answer as this isn't as obvious and would require some careful data measuring across that specific demographics.

Answer 7

I cannot confirm whether the statistics are true or not, but maybe I can suggest a reasonable explanation for this. Most programming courses in university do little to no programming at all, and a student can get by with little to no programming by opting only for theory courses. The problem is, unless the university is smart and directly provides it, most courses are made by professors, and these professors do not spend their time learning the latest frameworks or interview questions, they research and teach their field to the students, mainly covering theory. Most courses are not there to drill programming exercises or leet-code problems, and lectures that do that tend to be ineffective - how exactly are you going to make the student learn hours of Java in their own time, since lectures are not long enough to babysit them, if they don't want to do it? In short, one must learn programming themselves in their own time to get on top of things, and this may explain why graduates may fumble at a fizz buzz question if they didn't prepare for it.

Answer 8

No

Directly quoting your link http://weblog.raganwald.com/2007/01/dont-overthink-fizzbuzz.html

UPDATE: If you think that I just claimed that 199 out of 200 working programmers cannot code, stop immediately and either read my follow-up explaining the math, or read Joel’s article on why companies aren’t as picky as they think they are. Thank you.

Answer 9

To add to the other answers - anxiety is a very real thing for some. And by that I mean those with anxiety problems will feel much more anxious under the conditions of the interview. Yes you have pressure and deadlines in the actual job but we are accustomed to that, have people to bounce our ideas off, and can go deep inside our heads to solve problems if we need to. I for one have never mastered it well even though if you were to talk to people I have worked with they would have good things to say about the work I have done. But trying to talk and think at the same time on a whiteboard with strangers and the clock is ticking just freaks me the eff out on some primal level

Answer 10

Are a large proportion of programming job applicants unable to implement FizzBuzz (or a similarly simple task)?

Obviously, a reliable statistic does not exist. The opinion of 2-3-10 people is not enough for a believable generalization.

However, "unable" might be too strong a word. Closer to the reality would be (according to my limited experience) that (would be) programmers have troubles implementing the FizzBuzz problem. With some hints and some support, or using longer time, some (many) of them succeed to implement it.

On the blog Coding Horror, Jeff Atwood quotes individuals as saying that a large number of programming job applicants are unable to implement FizzBuzz. Why Can't Programmers.. Program?

That is the opinion of one person out of several billions. Does he have a believable statistic to support his claim?

Like me, the author is having trouble with the fact that 199 out of 200 applicants for every programming job can't write code at all. I repeat: they can't write any code whatsoever.

Can anyone show a study supporting the "199 out of 200" claim?

The author he's referring to is Imran, who is evidently turning away lots of programmers who can't write a simple program:

Again, the experience of only one person out of several billions.

The majority of comp sci graduates can't. I've also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.

That makes a sad-but-true observation of the education system in this world. As long as the purpose of universities is to make profit, they will accept and promote people with below-standard abilities. I would love to see a research targeting to find out the percent of people who deserve their diploma at the end of their studies. Maybe "199 out of 200", maybe not.

Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes.

Considering the simplicity of the problem, I mostly agree. In other contexts, testing a programmer on paper is kind of dumb.

Is there something wrong with our colleges? Are people panicking?

I am not sure I understand. Which "colleagues"? Which "people"?

Is it a good thing to ask in an interview?

It depends. If a company wants to quickly filter out the "garbage", then yes. If the company uses this problem to pick the best candidate, then definitely no.

---

I was tested a couple of times with this problem. I had no problem, I finished in just a few minutes, using only 2 "if" statements.

Answer 11

I'll start at the bottom:

Is there something wrong with our colleges?

Yes, the degree used to be "Math and computer science", and Calculus was a required course, as well as logic classes. In the late 1990s, with Y2K looming over us, programmers were needed and the math requirement was loosened, unfortunately, it was never restored.

But, the problem doesn't stop there.

The title used to be "Programmer/Analyst", now it's "Developer" and people are referred to as "coders" and not programmers any longer, and with good reason. There is a distinct difference between the two.

Then, there is the availability of resources that make for lazy thinking. Those of us who started with a command line interface and no internet beyond the rudiments of using telnet to get into a BBS or using USENET and the like, we had to figure things out on our own. We had to buy books and manuals, and pour through them trying to figure out where our mistakes were.

This has been replaced by a Google search, and code snippets here and there on various sites where people just cut and paste the code without ever writing it, or more to the point UNDERSTANDING it.

Are people panicking?

Some are, yes, but that's not the problem, IMO

Is it a good thing to ask in an interview?

I would say yes, but more to see how they reacted than anything else. The question is less relevant than it was, and there are very few real life situations where understanding the modulus operator is going to make or break you. But it does show how a person reacts to the problem.

When I am interviewing, I am less interested with the answer than I am with the approach and the reactions. In fact, knowing that this question trips up so many people, I would ask it just to see how people react to failure, as that tells me far more than how someone reacts when everything is going well. I have absolutely no problem working with someone who is technically deficient so long as they are WILLING AND ABLE TO LEARN

Then of course, some people are just dumb.

As George Carlin once said "Think of how stupid the average person is, then realize that half the people are dumber than that"

That is literally half the issue right there: 50% of people are below average

But, the question to ask is not are you getting the upper 25, 15 or 5% but if if you NEED someone of that technical level.

Answer 12

It's definitely a problem. I personally don't like eyeballs on me when I'm coding, but if you're asked to write it on paper, the interviewer is not expecting it to compile, just that it conceptually makes sense, and I would absolutely expect a candidate to be able to do that. Whenever I've given tests to candidates, I've always put more stock by how they discuss it afterwards, how they interpreted the problem and what they planned to do than by what they actually churned out in however long they were given.