Of course he should. It is as basic as it gets.

Can't really believe someone couldn't write even a pseudocode for that.

Yes. A million times yes (of which you'll have by the time everyone has posted their yes answer).

The entire point of FizzBuzz is to break down programming to the simplest possible test - do you understand how to communicate a task to a computer (by breaking it down into logical actions and decisions that do not require intuitive leaps).

If a person cannot meet this most basic requirement, they are not the programmer they claim to be.

If they can prove they have had any training at all (most bright people should be able to complete this, at least in pseudo code, after just their first week in a high school programming course) then they are not suitable to be a programmer at all - their brain just doesn't work the way it needs to (you can teach someone for 50 years and they still won't be Mozart).

Yes, you will get people who have 10 years of experience working as a programmer (and are not just faking their resume). They have 10 years because someone, maybe like you, decided that they must be able to program and hired them (because they had 8 year/5 years/2 years/a degree in programming). And thanks to the tools meant to help programmers do the simple things faster (like drag and drop designers), they are able to do the bare minimum needed to create the impression of work (which other programmers must make minor "bug fixes" for it to actually do what it is supposed to).

You want to stop having to interview people like this? Stop hiring them under the impression that the talk on their resume is more important then what you see with your own eyeballs.

YES.

It's a loop, simple math, and output. Should be no problem for entry-level programmers.

Absolutely. HOWEVER, the interviewee may have legitimate performance anxiety that prevents them doing it in a fixed time on a whiteboard while an intimidating person (you) stares them down.

Make sure that the interview is "friendly" and that you give them time and space to construct a solution.

But if they can't put together pseudocode in an empty room with a pencil in a half hour, then they're not worth any more of your time. (Your criteria may vary.)

Not only should a college graduate be able to answer the question, anyone who has taken one or two intro to programming classes should be able to answer it. It's not that difficult of a problem.

Of course they should be able to do it provided they are not having a breakdown.

Maybe you could lead up to the problem with some exercise that shows you're not trying to embarrass them with a trick question though.

I remember being very nervous during an interview in which I kept being told that I gave wrong answers. Then I was asked write pseudocode that sorts elements that can be one of three colors. So I was wrecking my brain trying to out-think the exercise, thinking that none of the sorting algorithms I was remembering would be good enough for the guy. And I ended up not writing anything down.

Turns out he wanted me to count the number of elements of each color then populate the new array according to this.

So after the interview, I find a table and work out the answers to the questions he asked. Turns out, in all cases I was right. He had been judging interviewees against wrong answers to simple logic/math/CS problems. I intended to go back and inform him so he could do a better job (and to recover some of my dignity, I admit). But then I overheard him disparaging my university to his fellow interviewers, how he didn't encounter a single competent applicant. At which point I just turned around and walked away.

I guess I recall that account so you know to make sure the interviewer is not an incompetent asshole.

Any college graduate should be able to solve a problem as simple as FizzBuzz. Not being able to do so should raise some red flags.

If you can't trust someone to be able to give a decent answer to a FizzBuzz style question then there's no way I'd trust them to be able to create something complex. Would you want them let loose on your large legacy codebase?

Considering the enormous exposure this interview aid has gotten lately, my first question to a failing interviewee would probably be "do you use the Internet much?"

Perhaps it's a good thing I don't do interviews.

And yes, of course a programmer should be able to solve this problem.

It seems like most competent programmers would be able to write the FizzBuzz solution even before stepping foot into a university for comp sci (since most dabble in programming during their high-school years). The comp sci curriculum is data structures, writing compilers, Big O notation, etc. The FizzBuzz is very easy in the sense that it omits virtually all the bread-n-butter compsci topics. The 4-year degree shouldn't even be a prerequisite! The FizzBuzz question is almost like asking if a college graduate should be able to add fractions.

My degree is in EE, I took 1 CS class in my life, and I just wrote out a pseudocode answer to this in <1 minute. It's the equivalent of asking an EE grad how to analyze a simple circuit, or what an op-amp does... However, ask me about OOP concepts in an interview and I'm likely to throw a stapler at you.

What do CS courses teach if not problem solving within different contexts?

FizzBuzz is simple enough that I'd expect them to be able to write the solution not only in pseudo-code, but in the language of their choice, ignoring syntax errors of course.

I don't see why you should expect 30 minutes to come up with the following solution:

for(int i = 1; i <= 100; i++)
{
   string output = string.Empty;
   if (i % 3 == 0) output += "Fizz";
   if (i % 5 == 0) output += "Buzz";
   if (string.IsNullOrEmpty(output)) output += i;
   System.Console.WriteLine(output);
}

Yes, I could have used StringBuilder to make string concatenation (as little as there is) slightly more efficient, or removed the concatenations by using if-elseifs instead. Hell, anyone who writes down string.IsNullOrEmpty should be hired right then and there.

Add: I'm nervous as hell during interviews, but I don't think I'd have trouble with a question as simple as this one. Typically, I've been asked either much harder questions that I've choked on, or been asked such unimportant questions, such as the syntax for operator overloading in C++, that any simple Google search would return the answer in a real-world situation. It's a touchy subject for me, knowing I have to rely on the quality of the interviewer.

While it might not be possible in many environments, I think the optimal situation would be to sit the interviewee on a computer with the newest version of Visual Studio up and running, and say "Write a function that answers the FizzBuzz question. I'd just like to see your coding style."

I feel like it'd be a situation like this where'd I'd really shine, just because I've learned to love the FxCop guidelines:

/// <summary> Prints the numbers 1 - 100, writing Fizz when divisible by 3, and Buzz when divisible by 5 </summary>
public void PrintFizzBuzz()
{
  for(int i = 1; i <= 100; i++)
  {
    string output = string.Empty;
    if (i % 3 == 0) 
    {
      output += "Fizz";
    }

    if (i % 5 == 0)
    { 
      output += "Buzz";
    }

    if (string.IsNullOrEmpty(output))
    {
      output += i;
    }

    System.Console.WriteLine(output);
  }
}

Yes, this is more work, but at least for me, it's much easier to visualize a solution with Visual Studio in front of me for such a trivial question than to write pseudo-code on a piece of paper. I do most of my work on a computer, not on paper, and I'm much more at-home in front of one. And doesn't this provide much more insight into the programmer's quality and their respect for readability?

FizzBuzz should definitely be able to be answered by a graduate - if they can't, then the course the took didn't teach them anything. I'd also be worried if they couldn't at least come up with a very simple answer to the question in a five minutes [never mind the 30 minutes that has been mentioned by others].

Aside from being able to answer it, you can also use it to determine other areas of an inerviewee's skill by simply asking them if they can improve it [and again after each subsequent improvement]. Then, once they reach the point that they say they can't, ask whether they're happy with it and/or why they can't improve it.
Improvements can include things like making it easy to add in a third term, not hard-coding in values, or other things that could be language dependent.

Yes,

Even if a junior programmer cant complete the FizzBuzz problem they should be able to sit with you, break down the problem to it's component parts (i.e. can I print Fizz for the multiples of 3 for the first 10 numbers, can I print Buzz, can I print both, what about 15) and explain how they would address them.

If the developer cannot break a problem down into it's simplest component parts then they will be useless as a developer.

If a developer can complete the FizzBuzz problem easily, worry more, ask them to break it down and see if they actually can do that, it's far more important than coding ability in a language.

If they can't do FizzBuzz in a half an hour, then our programming test would make them weep. Of course, our test isn't intended to be finished within the alloted time by any but the best of programmers - what is important is how much you get done in the time allotted and what the quality of code is.

The question isn't as simple as it may sound. Not every good programmer may like puzzles and not every good programmer can focus enough in an interview setting to see that it's a simple modulo question -- even more so if they don't have to deal with the modulo operator much in their field. From what I hear, a CS grad in the US should easily recognise the problem and be able to solve it. From my personal experience in my country, this doesn't hold true universally -- the modulo operator is a bit obscure if you're not actually dealing with pure algorithm design much.

If you test someone on how well they perform in solving well-known puzzles, you are only testing them on exactly that. This may be a good indicator of whether they are of any use, but the importance may also heavily depend on the programming tasks you're looking to be solved in real projects -- a maths nut may not be the best choice for GUI programming and a GUI programmer may not be the best choice for writing a physics simulation.

If the interviewee is completely clueless and can't solve the problem even after being given straightforward hints, they still might simply be too nervous, but chances are that they will perform equally badly under real stress or simply not know much at all.

It's certainly a good clue, but it's not fail-safe enough to rely on it alone. Variable naming and such can be telling, as can be the actual process -- let them use a realistic environment if you want insight into their actual abilities (can they tell by their code and its output what they are doing wrong? can they fix it? is the result patchy or clumsy, or did they actually improve it?). Looking at the code and asking them about it may also help to judge not only whether they are good, but also whether they can communicate their thoughts and what they did (is the code readable? can they explain how it works?).

Don't ask them to describe it as they do it -- that's distracting (writing code is a linguistic process, talking may interfer with it) and may hamper their creative process. But if they can't justify what they do or can't describe the function in layman's terms (not idiot-proof, but other-people-proof), they may be difficult to work with in a team or leave a mess behind when they leave you for new shores.

If they can't solve FizzBuzz, try another question. Maybe try a different topic, or something easier. If they can't even write a loop over an array, that's a good indicator they're lying about their skills. Also test them one things they claim to be good at. Don't insist on code samples if they can't write you any in the interview, but test their abstraction skills (e.g. ask them for the way they would do something in general terms, then ask them for something on a lower level, try them on several layers, not just one).

For good measure, here's my take on FizzBuzz in Python (without looking at samples and after forgetting to output non-fizzbuzz numbers literally):

def fizzBuzz(n):
    l = []
    for i in range(1,n+1):
        fizz = (i % 3 == 0)
        buzz = (i % 5 == 0)
        if fizz:
            if buzz:
                l += ['FizzBuzz']
            else:
                l += ['Fizz']
        elif buzz:
            l += ['Buzz']
        else:
            l += [str(i)]
    return l

I think the question has a subtle trick to it. The straight forward solution is obvious (checking for each condition), but there's a hint that there's a really cool one line solution when you noticed that mod 15, is FizzBizz, the concatenation of the two strings for mod 3 & mod 5. Perhaps I read too much Perl.

Yes^infinity.

Out of curiosity, I just tried this question.

for (int i = 1; i <= 100; i++)
{
    if (i % 3 == 0 && i % 5 == 0)
    	System.out.println("FizzBuzz");
    else if (i % 3 == 0)
    	System.out.println("Fizz");
    else if (i % 5 == 0)
    	System.out.println("Buzz");
    else
    	System.out.println(i);
}

This took me less than 4 minutes to think/write.

I am a college student whose first programming class was last semester.

So yes, I think someone who has a CS degree should be able to do this.

FizzBuzz? Give them one of the first twenty Project Euler ^[1] problems and ask them to think out loud as they try to solve it. That should prove once and for all if they're capable of problem solving and/or algorithmic thinking.

Of course they won't solve it without a computer, but at least they should be able to tell you how they would approach the problem.

Depends on what you want for an answer. Would the following suffice?

for every integer going from 0 to 100
  if thenumberismultipleof(3) then print fizz
  if thenumberismultipleof(5) then print buzz
  if thenumberismultipleof(3) and thenumberismultipleof(5) then print fizzbuzz

I haven't used the modulus operator in over five years because of the type of software I write. I have no use for it. The only thing I need is to know at times is if a number is even or odd. I have written an extension to do that (used to be in a utility component).

Why? Because reading

If (score.IsEven) {...}

is much more clear than reading

If (score % 2 = 0) {...}

Plus i don't have to worry about "2" accidently gets turned itn "22".

So using the modulus operator, and many other "basic" operators/framework methods, is not in my work routine. In fact I do very little math/number work. That work was done years ago and resides in various components and works so well I don't ever have to revisit it. Why should I be able to spit out the use of these things during an interview? Why should I expect others to do this?

In the end the fizzbuzz test is a trick to help people that do not know how to interview. They don't know how to judge the competence level of strangers. It is understandable because those are very hard skills to acquire. They might even be magical power for all I know.

So I think that if that is your primary trick, or if it is used as a show stopper, you are going to miss out on some good hires. Especially if you are going after young kids right out of college.

We hire people to do a specific job. I need a web service that can do x. I need a game engine that can do these things...

Does Fizz Buzz come under that job description? Does Linked List?

I mention this because of some of the comments noted above. There are many opinions about what a computer science grad should be able to do and that if they can't they aren't qualified.

There are many questions which could stump even seasoned programmers. Are they not qualified?

Well, maybe yes and maybe no. The thing is what am I hiring them for? To handle generic questions in tech they might not know that they haven't seen before under pressure, or to do a specific task that they can figure out and implement in a reasonable amount of time?

Once we prescreen the candidate, really see that he can do the tasks at hand, or figure them out on the job, we bring him in. Not before. Having trouble prescreening? There are ways to solve that easily and without extra manpower.

I'd rather send a guy a code screen, or have him come in to do one onsite. Give him access to the tools he will use on our job, and then let him have at it Google and all within the time frame that I would need this done from a junior team member.

That's a fair test, and a less demoralizing process for both he and I.

We had a very "senior" level contractor come in to look into something for us, and as part of a screening process, administered a similar type of question. He refused to answer saying it was below him.

As part of the interview discussion he told us the way we wanted to do something was "impossible" and would never work, and that we should hire him and do things his way.

We didn't hire him. We did things our way. The "impossible" worked just fine.

Never mind the level of person you're interviewing. The question is simply: can they pass this test?

Absolutely. As with any interviewing technique, it should be used to filter out the people who obviously have no idea what they are talking about and you don't want to spend too much time with. That is, it should be used a negative filter. If you can't solve it well in under five minutes, no hire. Actually, it would be a great phone-screen question. Easy to ask and a solution is easy to describe over the phone.

I wish interviewers were more about asking questions like this that let you show off the goods and less about what keywords you have or don't have on your resume, whether you include a separate cover letter with your email and resume and address the recruiter by name, or whether you have correctly prepared answers to the typical questions like "what is your greatest weakness"... etc.

Yes! You either can do stuff like that in the beginning of your career or you will never be able to.

We started doing a programming task for new hires in my company. The quality of the tests, even for senior developers, is behind what we are expecting, and I am glad we have this test in place now.

I think that FizzBuzz is a fine "logical" problem, but you'll really want to couple it with a separate problem that actually applies to the code that you work on every day.

I know for my latest interview, I did up some test code on recursive json, and gave a code sample of my own work, but when it came to the actual job, debugging in the large codebase that exists is the hardest part.

I often wonder whether that test was meaningful since it was so far off of the mark of the day-to-day stuff that I do.

Absolutely.

Surprisingly a lot of candiadates aren't even expecting this kind of question so apart from the fact that it gives you some information on wether the candidate can code it also shows you how he handles unexpected situations.

I wish I had a interview where they asked me fizzbuzz. I am a cs student and I could answer that question even if I had a total brain meltdown.

The only time I would not not ask it is if they came in with some code from a program that solved some real world problem. At that point fizzbuzz is not needed

Not only is this a good test to see if the candidate can think in (pseudo) code, a simple test like this can be used to:

• highlight the candidate's thought/design process (especially for more junior, or interview-shy candidates)
• serve as a springboard for further discussion

Any computer science student should be able to answer these sorts of questions. But twe things occur to me. First, keep in mind that nervous people often appear dimmer than they are. In particular, I've seen people thrown off (even offended) by how simple a question is. It's probably worth giving them a couple tries on different questions so that you can get an accurate picture of what they are capable. Second, as many have pointed out this is a very common problem; as such you may not have the luxury to dismiss them all. Instead, I believe it's also worth exploring higher-lever problem solving skills. You may find that they still have something to offer or that they can more easily answer the simple questions after having some success with more challenging questions. I'm not saying it's okay for "programmers" to be incapable of solving FizzBuzz problems, but I think it's worth making a concerted effort to understand someone true capacity before discounting them.

Its dangerous to taste a meal by sampling a few things on the table. I met some of the most clumsy developers that I know five years ago .. trained mostly by Google after a pathetic CS curriculum at some way too expensive university failed to equip them to actually get a job. Most of them are now brilliant.

When I hire, its for one of two reasons:

• This person really, really knows what they are doing, is patient and can bring up the over-all quality of the team
• This person has some skill and a burning desire to pick the brains of their peers.

Of course, placement matters. A recent Wikiversity graduate is not going to take on a lot of responsibility during their first few months.

When I say "Don't call us, we'll call you", its because:

• The person who can't solve a simple problem projects an "I know everything and I destroy bad code in my spare time!" image
• The person is sharp, but not well enough exposed to our language of choice for the project that will receive them (learning curve is just too steep)
• I saw the person acting in a really, really funny porno .. and just can't conceivably take them seriously after that, much less contain my laughter during the interview.

NB: the third case actually happened, which is why I noted it.

Btw, the solution (in C)

#include <stdio.h>
#ifndef TOP_AND_BOTTOM
#define TOP_AND_BOTTOM printf("+-----+------+------+\n");
#else
#error "How much time are you going to spend on a stupid interview question?"
#endif
int main(void)
{
  unsigned int i;
  TOP_AND_BOTTOM;
  for(i=1 ; i < 101 ; i++)
    printf("| %-3d | %-4s | %-4s |\n", i, i%3 ? "" : "Fizz", i%5 ? "" : "Buzz");
  TOP_AND_BOTTOM;
  return 0;
}

.. Could be a little more optimized, but I was making a point. I probably should not put the whole formatting task on printf(), its notoriously slow.

I was honestly a bit terrified about what the question was going to be (First time I've ever heard of the FizzBuzz name). After reading it though, I know for a fact I solve this in 25 seconds. Can people honestly, not do this? :S

Non programmers should be able to do this after reading ANY intro to programming textbook's first few chapters.

I taught myself programming, and I wrote it in C++ in under 2 minutes. I'd say give them something harder, like write a program to list out all the primes from 1 to 1000000. Even then, that's still quite easy.

Questions I definitely wouldn't give them though, considering they're entry level staff, are IOI ^[1] tasks.

I suspect those failing to answer were baffled by the stupidity of the task. They probably wasted their time trying to figure out where you hid the camera.

The question is fine as a starting point for discussions about how to solve it shorter/better/etc. btw, is there any shorter version in perl? I can write it only in 94 chars (yes, with spaces to make it more clear)

print join("\n", map ( ($_%3 == 0 ? "Fizz" : "") . ($_%5==0 ? "Buzz" : "") || $_, 1 .. 100));

Unfortunately, higher education is a business like anything else. If I were a cynic, I might think that the abundance of CS-degreed programmers who couldn't write Hello World in Visual Basic with a gun to their heads is in some way related to the need of CS departments to keep their enrollments up.

Because when you look at it that way, you start to see these departments as degree mills that suck in the country rubes, pocket their tuition dollars, and send them on their way without ever disturbing their self-delusions of grandeur. And I'd be angry if this weren't so true of (U.S.) higher education in general.

So yes, entry level programmers should be able to answer FizzBuzz. They're certainly paying enough for the privilege.

I gave myself 5min, and I wrote two ways of doing in paint using my wacom tablet...just to get the feel for actually writing it out...if you can't code this you really shouldn't be coding professionally, and it is really hard to believe someone claiming to have experience, that actually made it to the in person interview couldn't do this.

I used AS3 and although not terribly original, it is by me, Anthony Pace

    //there was of course the obvious...
    for(var n:int=1; n!=100001; ++n){
        if(n%3==0){
            if(n%5==0){
                trace('FizzBuzz');
                continue;
            }
            trace('Fizz');
        }else if(n%5==0){
            trace('Buzz');
        }else{
            trace(n);
        }
    }

    /*but it seems like the fastest  variation (in my mind at least)
I could come up with in under 5 min was one that uses a variable outside*/
        var output:String;
        for(var n:int=1; n!=101; ++n){
            if(n%3==0){
                if(n%5==0){
                    output+='FizzBuzz\n';
                    continue;
                }
                output+='Fizz\n';
            }else if(n%5==0){
                output+='Buzz\n';
            }else{
                output+=n+'\n';
            }
        }
        trace(output);
        // you could also trace output.substr(0,output.length-1); to get rid of the extra linebreak if it is absolutely neccessary

Man, this is pain... anyone have proper study of comsci should know how to do this at least.... :(

I suggest you keep using this kind of test :)

I wouldn't determine hiring based on a right or wrong answer. You hope this would be an exercise in how the person thinks/programs.

Going to play Devil's Advocate here and say "no". Being able to answer trivial programming questions doesn't mean that you can program, and I find it painfully annoying when I interview and get asked basic nonsense despite having programming experience. Ask me about real world problems, not textbook crap. It's as bad as asking somebody to write a program to sort numbers.

Many programmers are self-taught and have no idea what this FizzBuzz stuff is, but they can write applications that work. That should be the only thing that matters, not being able to regurgitate theoretical nonsense learned in college. CS courses don't do squat to prepare you to develop real world applications.

You are essentially testing for knowledge of the % (modulus) operator, or equivalent - not something we often use. I know of it from 8 bit programming days - not sure if I've used it more than a couple of times since then.

I know I'll be downvoted, but nevertheless, no, it isn't a good question.