In case any readers don't know how to complete that test, here's a solution in VBScript. To try it - save the code into "c:\test.vbs" and run "cscript c:\test.vbs" from a command prompt.

Dim i

For i = 1 to 100
If (i Mod 3 = 0) And (i Mod 5 = 0) Then
WScript.Echo "FizzBuzz"
ElseIf (i Mod 3 = 0) Then
WScript.Echo "Fizz"
ElseIf (i Mod 5 = 0) Then
WScript.Echo "Buzz"
Else
Wscript.Echo i
End If
Next

Very very common, alas. I once interviewed a candidate for a VBA job (yes, you can stop booing for the peanut gallery) whom I asked to swap two variable contents without using a temp variable. It's the standard a=a+b, b=a-b, a=a-b problem. His answer? Well, I can't do it in VBA, but if you let me use Excel I can put the values in two cells and swap the cells' contents using a third cell.

We hired the guy who said, well, "if they're integers, then I'd do it by a=a|b, b=a^b, a=a^b. But I don't know how to do it if they're strings."

I've been making a decent living from programming for over ten years, and if I may say so, I write some damn good code.

However, I have never *once* used - or had call to use - recursion to solve a problem, since I learned about it at university. Does this make me a bad programmer? Or is it simply that people program in different ways for different problem spheres?

I simply can't believe that the other 199 people tested who can't write a simple for..loop have no career as some kind of programmer ahead of them.
Does that mean that every one of those people who do program but don't use (say) recursion is a bad programmer?

Or is it that you can't rely on any one testing method (like writing simple programs) to prove either way that the person can program effectivley or not?

The most obvious way to decide - for me - is to run through these tests, emply the person you like the best and then look at the code they've produced after a week. Then you'll know if they can do what you need.

The bottom line is, you can always learn to pass interview tests of any kind - that doesn't mean you can program or not.

I think the above solution is not elegant.

I think

If (i Mod 3 = 0) Then
WScript.Echo "Fizz"
End If
If (i Mod 5 = 0) Then
WScript.Echo "Buzz"
End If

because it covers the "both" case automatically. OK you have to care about line breaks which I don't know in VBS (never used that crap, thank goodness).

I think the use of recursion probably depends on the particular field that you code in.

As a web developer I also have very little cause to use it. The only time I use it is when I need to search through the file system.

Isn't the code for that ..

int main() { ExitPaperBag(); return 0; }

I'm not sure ... copied it from somewhere :P

There's a cynical voice in my head that says "because no-one has ever asked them to".

Where I work we spend a long time looking before we hire someone, because it's so hard to find them. We use a walk-through test that has a sequence of "questions" leading to a simple app and are willing to argue the toss (I was hired despite arguing that the test had significant flaws: "why would I do that? That's stupid because..." when they wanted me to code a solution that led to the next question).

I fear that any take-home or pre-interview component would lead to plagarism or "helped" solutions, so we make candidates perform in front of us.

That's got our ratio up to 3/4 good hires.

shenpen - Unfortunately that wouldn't be a valid solution (in VBScript) because WScript.echo adds a CRLF. In another language it might work though.

Sorry, but if someone were to ask me how to swap two variables w/o a temp variable I'd ask them to give me a good reason why.

Not being able to answer that particular question certainly doesn't preclude someone from being a good programmer. That'd be like asking a C# programmer how to do modulo 16 using only a logical and. Why the hell would they need to know that, and how does that help you determine that they understand the ASP.Net framework, etc.?

shenpen: As you point out, your solution doesn't handle line breaks. It also doesn't print out the original number!

shenpen, for shame. Read the spec again.

I don't think I've ever interviewed a programmer quite that bad, but I did have a conversation with a contractor I was replacing once: I'd introduced a class into the monster spreadsheet he'd been maintaining and he looked at it and remarked "I wish I knew how to do that". He was picking up about GBP400 a day (call it about $650 at that time) for this.

As I'm about to start looking for a programmer I shall be able to implement my long-cherished plan of asking candidates to submit a page or so of what they consider to be "good code". I don't mind if they wrote it or not, I want to see if we agree on the look of "goodness". If we get that far, I can find out if we agree on why it's good.

This is nasty but it's technically a one-liner:

1.upto(100) { |n| puts n % 3 == 0 ? n % 5 == 0 ? "fizzbuzz" : "buzz" : n % 5 == 0 ? "fizz" : n }

WOW! (and not the vista kind).

I can't believe there are people out there applying for jobs in software that cannot write a fizzbuzz program.

It's true that knowing how to do modulo 16 using AND doesn't relate to understanding ASP.Net.

On the other hand, do you want an ASP.Net technician, or someone who understands the theory behind it? Can you really call the candidate who only knows ASP.Net, but nothing about a basic logic a programmer (or a computer scientist, or a software engineer, or a coder), or is he just some guy who knows ASP.Net?

James: it's amusing to me that any reference to a programming problem-- in this case, FizzBuzz-- immediately prompts developers to feverishly begin posting solutions.

1) The whole point of the article is about WHY we have to ask people to write FizzBuzz. The mechanical part of writing and solving FizzBuzz is irrelevant.

2) Any programmer who cares enough to read programming blogs is already far beyond such a simple problem. It's the ones we can't rerach-- the programmers who don't read anything-- that we have to give the FizzBuzz test to.

But it's OK, I mean no offense. It's just funny. I know how software developers' minds work. :)

My point is that what you're asking for isn't "domain knowledge" strictly speaking. Using an XOR to swap two variables w/o a temp variable is only really useful when memory is expensive (embedded programming, et al). If you're not interviewing for an embedded programmer why are you worried about it?

Same with the modulo trick. The first time I ever encountered that I was writing a Perlin Noise Generator based off of someone else's work. Outside of routines that need to be highly optimized there's no reason for it.

Are you trying to hire an ASP.Net programmer or an embedded systems programmer? Granted, the XOR trick is pretty well known, but not knowing it off the top of your head says nothing about your abilities as a programmer (whereas the fizzbuzz example does).

No one can know everything. I would expect that type of attitude from a non-IT person, but not someone who is interviewing programmers.

Ha ha! I see what you're saying Jeff.

I hope I didn't come across as feverish though. I sincerely thought that a solution may be of interest to someone who couldn't write one themselves.

Perhaps you have readers who aspire to be programmers but are still learning?

Perhaps a future Google search for "FizzBuzz" will bring back this page? (And the Googler might be after the solution).

Interestingly, the use of a technical test in interviews can actually work both ways. In my recent hunt for a new job I automatically turned down any vacancy where I was *not* given a technical test. My reasoning behind that is that I know *I* can program, but do I want to work with *other* programmers who haven't been tested?

The harder the test I was given, the more excited I was about the vacancy.

If anyone out there is looking for a new job I urge you to bear that in mind.

Instead of using recursion, it's often faster to use a Stack.

There's always 'Survivor for Developers' for those who don't make the cut. http://techtalkblogs.com/blog/archive/2007/01/26/1837.aspx

At the end of each week, you vote the worst dev off the island.

It's just performance anxiety.
Most people are terrified/stressed out during interviews.
Not "Can you X?" -
"Can you X whilst terrified?"

AndyToo wrote:
"However, I have never *once* used - or had call to use - recursion to solve a problem, since I learned about it at university. Does this make me a bad programmer? Or is it simply that people program in different ways for different problem spheres?"

i think you missed the point: if ou were explicitly tasked to write a algorithm using recursion, would you be able to do it ? would you be able to recognise the use of recursion while reading someone else code ? and most important, the one i struggled teaching to newly hired guys and which most people dont learn at school: do you understand the principles behind recursion ?

every good programmer knows there are plenty of ways to avoid recursion, but being able to avoid it implies that you know what recursion is.

and that is the point of such a question during an interview.

Damnd thing took me three minutes to write in php. I am getting slower with old age ;-)

if ($x/3 == floor($x/3) ... and so on.

I wonder why it is 199 out of 200 instead of more reasonable number like 99 out of 100? In any case I believe him. It is amazing how many people are paid to be programmers that struggle at the job and clearly should have been hired in the first place. When I used to teach college I noticed the same trend... a large number of CS student just really did not understand how to program. It was scary.

Having in the past been tortured by clueless candidates, I can believe the claim. Phone screening with simple as simple can be questions is amazingly (and disturbingly) effective. Where do these people come from?

While you may not have used recursion to solve a problem, if you know what it is and how to code something simple then that is enough, me thinks. There is a stunningly large population of people who describe themselves as 'professional software developers' who have not the faintest idea about recursion, bit masking, hexadecimal maths...or how to code a simple for loop that does something like FizzBuzz.

Over the years I've built up a loose theory on these "pretenders"--they are the people that know tinker and tweak and copy and paste and fidle and, when left alone for a while, some how manage to produce a bit of code that passes as productive.

Non technical people just cannot distinguish between them and us, and many times we technical people don't ask the right questions. What are we asking if not the FizzBuzz question? Surely it varies, but inevitably we are asking questions whose answers have nothing to do with problem solving and the mechanics of coding.

One of my FizzBuzz questions is, when a candidate has "SQL" on their CV, is to draw a simple table (Person: last, first, sex, DoB), populate it with four or five rows, and ask them to write some SQL that returns all the males, or everyone born after a given date. Simple enough problem, very real world, and relevant to someone working in 'web development'. Two out of three cannot do it! Ask for an insert or update? Four out of five, if not fewer!

Our profession is full of frauds and incompetent fools. And I feel safe saying that here because, if you are reading the comments on Jeff's blog, then you actually take an interest in both the nitty gritty of computers and programming...and the higher level fluff, like hiring. :)

>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

Ofcourse we all know that being a elite programmer is all about how fast you can program, especially in a high-pressure situation.

Wow. Now that's sad. I don't call myself a programmer at all, and I could write a solution to this in Qbasic!

Most development is simple viewing and editing of data in forms.

Developers who can't write "fizzbuzz" can be productive in such an environment, especially if there is existing code they can copy and modify.

Most development is simple viewing and editing of data in forms.

Developers who can't write "fizzbuzz" can be productive in such an environment, especially if there is existing code they can copy and modify.

I suspect some of the people above complaining about the high pressure of having to write a ten line program including division may fall into this category. :-)

if program does require recursion, then definitely everyone will use this.

for (int i = 1; i < 101; i++)
{
if ((i % 3) == 0) Console.Write("Fizz");
if ((i % 5) == 0) Console.Write("Buzz");
Console.WriteLine();
}

"Most development is simple viewing and editing of data in forms.

Developers who can't write "fizzbuzz" can be productive in such an environment, especially if there is existing code they can copy and modify."

They'd also be an incredible liability. If fizzbuzz is beyond them, concepts such as memory/processor usage, security, stability, defensive programming, etc. are going to way out of their grasp. I've worked with someone like this; they _cost_ us time, because _everything_ they wrote had to be completely re-written by someone else. Unchecked inputs, error messages that consisted solely of dancing cats (seriously), SQL and HTML injection holes all over the place.

On writing a program to switch two variables without a temporary variable; while I had a hunch it involved bit operations of some kind, I certainly wouldn't know how to do it off hand.

On time taken to program; I'd probably spend several minutes just staring the FizzBuzz task, looking for some complexity I'd missed, so that's also something to take into account.

bool printint;
for (int i = 1; i <= 100; i++)
{
printint = true;
if (i % 3 == 0) { Console.Write("Fizz"); printint = false; }
if (i % 5 == 0) { Console.Write("Buzz"); printint = false; }
if (printint) Console.Write(i.ToString());
Console.WriteLine();
}

to LKM:
"Instead of using recursion, it's often faster to use a Stack"
do you understand how, in almost any language, recursion involves a stack ? you are just making the hidden part visible...

to shiva:
"if program does require recursion, then definitely everyone will use this."
agreed, but you are free to think a bit longer and see if you cannot avoid it. this is the difference between a good programmer and a smart programmer: the former knows how to solve the problem while the later invents new ways to solve the problem more efficiently.

to Fabian:
no, you forgot a part of the requirements. wroooong ! do it again !

to Jeff:
"it's amusing to me that any reference to a programming problem-- in this case, FizzBuzz-- immediately prompts developers to feverishly begin posting solutions."
it is also amusing how many of those solutions are wrong. so typical of our profession...

Back in '99, I was given a FizzBuzz task by a Microsoft recruiter to design a program that would take two inputs and determine if they were anagrams of each other. I began with a quick test of string length - if they didn't have the same number of characters then it was immediately rejected. He was very impressed that I would start with such a test. Seems most people would go through cycles and cycles regardless of the inputs.

To be honest as a recent grad and somone who is new to being a software developer I think if you are incompetant you shouldn't last long anyway.

In my first month at my new job I had to learn VB and C++ from scratch, two months later I was moved on to a project in C# using ASP.Net which I'd never used before. I've seen similar tests to the fizzbang questions, and they are useful.

My current employer gave me 3 hours to parse an XMl file and display it as a tree structure. I'd not spent much time playing with XML before but with after a quick google for a reference on the SAX api I was coding away. apparently half the candidates couldn't write anything and others didn't know how to use and IDE and insisted on using a text editor. which they screwed up.

Another couple of employers has written tests with small "write a code fragment to do this" and "spot the mistake in this code" questions. both were piss easy but there were some trick questions in there.

I think what should be tested especially for recent grads is not the knowledge per say, but the capacity to pick stuff up, I got my current Job becuase I took an API I had never used before and figured out how to use it. I'm by no means a pro, but I have the capacity to learn by myself, some people can't pick up new things unless they are spoon fed.

University is not an excercise in cramming your head full of knowledge it's an excercise in learning how to learn quickly and efficiently.

When you know the basics you can teach yourself a new language in a few hours, and depending on the complexity learn a new API in an hour to day. Many grads I find dont have that capacity, I did a masters with a bunch of people who came from different universities to me, and some of them just couldn't cope with having to fend for them selves.

Thats my two cents anyway. I think the fizbang questions help sift out the muck but the problem is more intrinsic and needs to be addressed at the level of academic institutions.

Stu Thompson wrote, "There is a stunningly large population of people who describe themselves as 'professional software developers' who have not the faintest idea about recursion, bit masking, hexadecimal maths...or how to code a simple for loop that does something like FizzBuzz."

FizzBuzz, sure, any programmer should know how to write that. Bit masking though? That example just goes to show the wide range of expertise involved in programming, not all of which is required to be a successful or skilled programmer.

I don't think I've used bit masking (and I can't even remember what it is, exactly) since college. But Stu goes on to say talk about asking for SQL examples in interviews, and here not only would I be able to demonstrate inserts and updates - of course - but left joins, cross joins, multi-table deletes, whatever.

FizzBuzz is an acceptable test because it is non-domain specific, the same cannot be said for all other types of programming knowledge.

Quote: Granted, the XOR trick is pretty well known, but not knowing it off the top of your head says nothing about your abilities as a programmer (whereas the fizzbuzz example does).

True. However, someone who's never read enough professional literature (including programming blogs) to have seen this may either be:
a. very inexperienced OR
b. not interested in programming outside of coursework/their job.

I submit that such a person is never going to be a great programmer (although they may be, barely, adequate).

Common, unfortunately. The majority of CS grads can handle the trivial stuff like "FizzBuzz" (though a slight majority probably never really grokked recursion). But I've seen people hired at my last job who couldn't code.

in one case, the person did know a bit of syntax, but they had absolutely no debugging skills. This person didn't know the integrated debugger existed. They didn't even use simple debugging outputs to the console. No, their method of debugging was to randomly change stuff to see if it fixed their problem. Not surprisingly, that didn't work very well.

Fabian

Nice little snippet there. However, it doesnt fulfill the specification.

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

You arent writing out i when its not %3 and/or %5

Close but no cigar.

I need a raise then, cause I actually write and ship a COTS version of the FizzBuzz application.

"it is also amusing how many of those solutions are wrong. so typical of our profession...:

I noticed this as well. Makes one really start to question the worth of such statements as "if you're reading this blog, you're already much better than those *other* programmers".

Heres another solution

int i = 0;

for(i = 1; i <= 100; i++)
{
if(i % 15 == 0)
{
count << "FizzBuzz" << endl;
}
elseif(i % 5 == 0)
{
count << "Buzz" << endl;
}
elseif(i % 3 == 0)
{
count << "Fizz" << endl;
}
else
{
cout << i << endl;
}

}

My weapon of choice is Ruby

1.upto(100) do |i|
out = nil
out = out.to_s + 'Fizz' if i % 3 == 0
out = out.to_s + 'Buzz' if i % 5 == 0
puts out || i
end

And did you really think you could say "only 0.5% of programmers can write FizzBuzz" without people showing you how they do it? :P

I remember at my first University course the teacher asking how many people never programmed before. Many hands were raised, and I felt bad for them for choosing a future profession without knowning what it actually was about. Then he asked how many people never touched a keyboard before. How shock was I to see at least 10 persons raise their hand, mostly women.

I've witnessed the same, sad truth. It even inspired me to write my first blog entry on candidates attempts to code strcpy():
http://davidavraamides.net/blog/2005/05/07/strcpy/

I think the takeaway from this is that you are a fool if you are interviewing programmers and not requiring them to write some code.

Toepopper: swapping variables without a temp is more what I'd call tech trivia then useful knowledge. There really isn't a good use case for it anymore (its not even necessarily faster than using a temp since procs have so many registers these days). Besides, your solution of a=a+b, b=a-b, a=a-b fails in overflow cases. The candidate's XOR solution is more correct, but still unnecessary.

rien: you are right on regarding _understanding_ recursion. I agree that its frequently not necessary and often the less efficient solution, but being able to recognize that fact, and to read someone else's code, requires familiarity with the technique. And that's why I would consider it fair game in an interview.

"we all know that being a elite programmer is all about how fast you can program, especially in a high-pressure situation." ....well, yes, if you've got an online application and somebody's just discovered a serious bug, sometimes that's exactly what it's about.

Recursion? I never used to use it either. Then I read the first chapter of Structure and Interpretation of Computer Programs, and some other stuff about writing compilers and interpreters. Now I use recursion all the time, coming up with all sorts of general, automated solutions for the sorts of tedious tasks I used to code out by hand.

Why can't they program? Because demand for good programmers has outstripped supply. Those of us who interview a lot of applicants (I've seen at least 50 the last year) know two things: most can't program, and those who can will be tough to get. And now it's been bad enough for long enough that many doing the hiring can't program either, so screening is often incompetent and these charlatans stand an excellent chance of getting hired anyway.

Testing is imperative, but some just seem reluctant to do it -- it seems so cold and mean.

Fizzbuzz looks like a good test. Here are two other standard questions, the first one broadly published and the second very general. Many "programmers" flop on one or both:

1. Draw four "cards", showing "A", "B", "2" and "3" respectively. Say that for each card there is a letter on one side and a number on the other side. I have a theory that if there is a vowel on one side of a card, then there will be an even number on the other side. Which cards do we need to turn over and examine the other side of to adequately test my theory?

2. What is a hash table, and when would you use one? Why might you prefer using a hash to using an unsorted array, or a sorted array? What tradeoffs are you making when you choose between a hash and a sorted array?

When the applicant doesn't know what a vowel is, or a hash table is, I know it's going to be a long day....

Neah... Jeff just wants us to fell all fuzzy and warm... No way I'm in like the top .5% of the programmers.
Anyway... I can do the FizzBuzz thingy... hi hi hi
for i in range(1,101): print {0:"FizzBuzz", 3:"Fizz", 6:"Fizz", 9:"Fizz", 12:"Fizz" , 5:"Buzz", 10:"Buzz"}.get(i%15, i)

@Ade: My point is that the many 'programmers' do not know *anything* about bit masking, *and* other core concepts. None. Zip-o. Nada. I did not mean to imply that all coders should have an encyclopaedic knowledge of all CS! :) Please don't obsess on my mention of bit masking alone.

Good for you on the SQL, but then again it is domain specific and I qualified it as such above. ('web development')

@rien: hehe, i agree on the urge to post code...it is funny...especially when it is incorrect

Hrmf!

I wouldn't hire any of you guys who sent in the Fizz/Bang program. You should have declared 5 and 3 constants, and used the constants in your code.

Besides, real programmers wouldn't program in VB, they'd use Perl. Now, if I can only get this page to work in my Lynx web browser.

"....well, yes, if you've got an online application and somebody's just discovered a serious bug, sometimes that's exactly what it's about."

Ugh, had one of those on Friday. Our caching system was spitting out the wrong data (by which I mean, the wrong user's data). Never showed up on the dev system because the caching system uses SoftReferences to allow the Java garbage collector to expire data from it, and the dev version never ran long enough for garbage collection to really be an issue. Important lesson about being _really_ sure about your compareTo() methods before using java.util.TreeMap.

Took us 40 minutes to locate, fix, and patch to live. Which is a little longer than usual, but locating the problem more or less came down to eliminating everything it couldn't be, then figuring out how it was the fault of what was left.

Geez guys - EVERY ONE of you who gave example code - EVERY ONE - hard coded the FIZZ and BUZZ conditions... And a LOT of you wrote code that will do the FIZZ, BUZZ and FIZZBUZZ but NOT print the integer...

I just couldn't resist:

for(int i=0;i<100;printf(i%3==0?i%5==0?"Fizzbuzz":"FIZZ":i%5==0?"BUZZ":"%i",i++));

82 Characters
And yes, it's as dirty as it would ever get ... ;)
I've tested it with .NET 2.0 C++ and it works just fine ...

public class FizzBuzz
{

public static void main(String [] args)
{

int k;

for(int i=1; i<=100; i++)
{
k = 0;

if(i%3==0)
{
k = 1;
}

if(i%5==0)
{
k = k + 2;
}

switch(k)
{
case 1:
System.out.println("Fizz");
break;
case 2:
System.out.println("Buzz");
break;
case 3:
System.out.println("FizzBuzz");
break;
default:
System.out.println(i);
}
}
}
}

My biggest problem with solving simple programming problems tends to be the memorization involved with different languages, especially if I haven't used a particular language in a while. More often than not I'll go through my resume and remove (or limit mention of) languages that I used for only a short time or simply haven't used in a while.

For example, I feel quite competant with dealing with basic database issues, but without having touched a database in a few years I'd have to look up even the most basic sql statements, so I wouldn't claim to be a capable database programmer, though after a couple of weeks I could be at least a moderately good one.

Recursion is a similar problem with different languages. Some languages don't allow it at all, and others have very specific restrictions that make it a little harder to just jump in and say we'll just make this call here and make sure the conditions are in line to stop the whole mess from self-destructing.

In other words, I have a terrible memory, but I can still answer most of those questions with whatever language I've been using recently. I simply have to maintain my resume to avoid being asked questions that would send me to the books (or the web) to find an answer that should just spring to mind immediately.

Forgive me, but I can't resist...recursive fizzbuzz:
(Python)
def fizzbuzz(n):
if n:
if n % 15 == 0: return fizzbuzz(n-1) + 'fizzbuzz ';
elif n % 5 == 0: return fizzbuzz(n-1) + 'buzz ';
elif n % 3 == 0: return fizzbuzz(n-1) + 'fizz ';
else : return fizzbuzz(n-1) + ('%d ' % n)
return ''

>>> fizzbuzz(100)

"And did you really think you could say "only 0.5% of programmers can write FizzBuzz" without people showing you how they do it? :P"

Gareth: my guess is the ones who couldn't do it didn't bother to answer

Anecdotal "evidence" against this: When I started my first job after university (also, my first programming job), I could /maybe/ have answered FizzBuzz in Java. I'd programmed probably less than 1000 lines my whole life. Two months later I was improving my colleagues' code in a language I'd never used before. 2.5 years, some 36,000 lines of production code, and a good recommendation letter later, I'm stuck in a job market that only wants people with 5 years experience.

"Ofcourse we all know that being a elite programmer is all about how fast you can program, especially in a high-pressure situation."

So you think that, even in an interview, it's alright for an experienced professional to take 10-15 minutes to write FizzBuzz? That's more than one minute per line!

>do you understand how, in almost any language,
>recursion involves a stack ? you are just making
>the hidden part visible...

Do you understand that by using a local stack instead of the call stack, the computer needs to keep track of much less information and needs to do much less work building and tearing down the call stack? In most languages, using a stack instead of recursion speeds up your app tremendously.

Also, why the hostility? Did I somehow insult you? If so, I apologize, but I fail to see what exactly I did to you.

Any question can be made difficult. If asked an easy question, an interviewee knows they have to get it right and will become more nervous as time goes on. Over the course of three minutes, it can get *very* bad.

"Write a program that prints the numbers from 1 to 100."

Inclusive/exclusive? Are we in a language in which fencepost errors are likely?

"But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”."

On the same line or different lines?

"For numbers which are multiples of both three and five print “FizzBuzz”."

What about performance? The interviewee may be trying to remember how mod is implemented. And thinking about fence posts. And thinking about 3 cases of control flow. And "fizzbuzz". And working quickly. And acting calm. And why they're being asked this stupid question. Normally you do not deal with all of these things at the same time, but asking a simple question in a stressful environment in which the interviewee is getting ready to put 110% in to whatever you say will likely lead them in to trying to do so. There's only so much you can keep in your head, and even less when you're nervous. As you get more nervous (because the question is taking a long time), your nervousness will feed into itself.

Whenever I'm asked a question like that, I think the manager is clueless, both technically and in their ability to lead a team. Asking insightful questions about harder projects will reveal who did the work, and asking questions appropriate to the applicant will show you understand your team. This just shows you're a delusional asshole.

One company I know required applicants to do an almost code homework assignment before applying. A code sample or two as well as discussions of past projects should suffice and probably bring up good topics, as the subject will reveal what they're interested in. If you're a coder on the same project, ask for their solutions to problems you're having.

I stopped explicitly listing my technical skills recently and just put projects I have worked on - that also cut back on the bullshit questions people asked. When not given something distracting like that, interviewers have to think about better topics - and the interview may even become a fun conversation at that point.

It requires a huge deal of self-confidence to be as much effective during an interview as during your lazy sundays. Most of us will think twice before considering writing the *simplest* statement in front of an interview panel. I agree with most of this article - but it should really insist of the psychological factors (Of course, you could argue whether good programming abilities are dissociable or not from good social and communication abilities).

Mike Reiland: when you wrote

"Not being able to answer that particular question certainly doesn't preclude someone from being a good programmer. That'd be like asking a C# programmer how to do modulo 16 using only a logical and. Why the hell would they need to know that, and how does that help you determine that they understand the ASP.Net framework, etc.?"

I think you missed the bloody point. There are plenty of people who "know the [fill in the blank] framework," but can't program worth a flying damn in a circus tent. I've worked with people who brought a Master's Degree in Computer Science to the table, but couldn't understand the concept of a state machine or even building flag values by accumulating bits. I showed a simple event-driven framework to one junior programmer and his response was "I wasn't taught that method." He didn't ever appear to grasp that there was more to the world than was taught in his Computer Science classes, and that we were allowed to actualy come up with and express ideas all on our own without a professor's approval. Needless to say, he didn't last long. (Actually, he was a little on the weird side; he kept coming to work after we fired him. That concept of being fired seemed beyond him as well.)

Check out http://worsethanfailure.com/Default.aspx for examples of people who "know the [f.i.t.b.] framework," but can't seem to express the simplest of concepts in code. It has little to do with hoop-jumping and clever tricks, and everything to do with getting the job done on a daily basis: some of these people come out of University with a degree and no idea at all how to code.

The company where I work has an extensive series of programming tests for potential new hires, including specific problems derived from the kind of coding we expect them to do on a daily basis. It's amazing how many people can't get through it. One applicant excused himself to go to the bathroom during the middle of the test, and never came back. It's not even a hard test.

For the record: wrote the FizzBuzz thing in under two minutes--right the first time. (In all fairness, though, I first started programming when I was 15, and that was 31 years ago. If I can't do FizzBuzz after that amount of time, I need to hang up the cape.)

I think it's interesting to see how many people here are innately drawn to developing a solution to the problem, completely overlooking the original point (which was that many candidates wouldn't normally find themselves innately drawn to this).

I think this defines one key aspect of programmers who succeed, and those who simply maintain as they move forward: an inherent interest in/drive toward practicing (in the Dave Thomas "Code Kata" sense) their craft, vs. someone who simply views programming as a job to complete.

In any field, there are those who are passionate about what they do, and there are those who do it because they need something to do; it's just starting to catch up en masse with technology fields now. And it's not necessarily a bad thing: you always need people who would rather do repetitive tasks, and you always need people who would rather be tackling ambiguously-defined problems, and these people are rarely one in the same.

And, just because I'm a geek, and can't help myself, here's what I whipped up in a couple of minutes. I'm sure it could be better, but that's when you start up an interesting conversation about refactoring in the interview, right? ;-)

for i in range(1, 101):
x = ""
if i % 3 == 0:
x = x + "Fizz"
if i % 5 == 0:
x = x + "Buzz"
if x == "":
x = str(i)
print x

I'm very impressed with all of these FizzBuzz developers posting here in the comments!

Has anyone thought of creating a web page where we can see cross-language solutions to the FizzBuzz problem? Once there are enough solutions (and optimizations) posted, perhaps it can be spun off into the Great FizzBuzz Programming Shootout. And don't forget a job board and forums to connect with prospective employers.

This is an exciting time to be in software development.

LKM: I think your man was just pointing out that it's a bit dodgy to say "use a stack instead of recursion". Recursion pretty much always uses a stack, you're just talking about using a smaller, faster stack. A stack on the stack, even.

Anyone who expects a VBA programmer to write "swap two variables without using a temp variable" code is going to end up hiring a programmer who gets bored in three months and leaves.

The FizzBuzz problem is a good example of taking a simple set of requirements and translating them into program code.

Unless you're interviewing for an embedded software position, the "swap two variables with no temp" problem is a good example of utterly pointless "Let's see if you know the same nifty trick I know" interviewing. You might as well ask the interviewee where they bury the survivors when a plane crashes on the border of Canada and the U.S.

Okay, so python's required indenting and blogging don't seem to go well together. Ah well, you all know what I meant. ;-)

Here's my simple C program that implements the fuzzbuzz program.

#include

int main(void)
{
int i,j=0;
for(i=0;i<=100;i++)
{
if((i%3)==0)
{
printf("Fizz");
j=1;
}
if((i%5)==0)
{
printf("Buzz");
j=1;
}
if(!j)
{
printf("%d",i);
}
printf("\n");
j=0;
}
}

well ... someone had to write it in C right?

#include "stdio.h"

int main ()
{
for(int i = 1; i < 101; i++)
{
if (i%3==0) printf("Fizz");
if (i%5==0) printf("Buzz");
if (i%3 && i%5) printf("%d", i);
printf("\n");
}
return (0);
}

I use recursion every day. It makes handling XML simple. I can't imagine not using it. However, if I were hiring someone, I'd not make it a prerequisite. Neither would I fail them if they didn't know what a modulo was. I'd be happy if they could solve FizzBuzz in 30 minutes. I'm more concerned that they understand a little about abstraction. If they don't know what "this" is, then we're screwed.

CF (SCRIPT) version, for your viewing pleasure...

for (i = 1; i LTE 100; i = i + 1) {
if ((j MOD 3) AND (j MOD 5)) {
WriteOutput(i);
} else {
if (NOT j MOD 3) {WriteOutput('FIZZ');}
if (NOT j MOD 5) {WriteOutput('BUZZ');}
}
WriteOutput(chr(13) & chr(10));
}

Opps... I suppose i should have a "return(0);" before that last curly bracket...

I guess that's what I get for compiling without -Wall ...

>I think your man was just pointing out
>that it's a bit dodgy to say "use a
>stack instead of recursion".

Well, that's not what I said. I said "Instead of using recursion, it's often faster to use a Stack." Which is true.

>Recursion pretty much always uses a stack,

Yeah, but that does not change what I wrote. Coincidentially, I have written a Java-to-native compiler and happen to know how call stacks are implemented, and the overhead involved in building them up and tearing them down :-)

most people are in it for the money. most people, like me, actually enjoy coding. What do I do before heading to bed? No, I dont read a book, I code. I get butteryflies in my stomach whenever my professors anounce a new C++ programming project; I start on it that same day and do not stop until complete--and perfect. I added a feature to that fizz-buzz program: it prints out the number which is divisible as well. Took me all of 30 seconds to do.

for(int loop = 1; loop <= 100; loop++)
{
if ((loop % 3 == 0) & (loop % 5 == 0))
{
cout << loop << ":\tFizzBuzz" << endl ;
}else if (loop % 3 == 0)
{
cout << loop << ":\tFizz" << endl ;
}
else if (loop % 5 == 0)
{
cout << loop << ":\tBuzz" << endl ;
}
}

btw, my fiance gets mad when i code early in the morning; i actually had to alt-tab out of the compiler so she wouldnt see it. :P

And the obligatory Haskeller chimes in with:

fizzbuzz n | n `mod` 15 == 0 = "FizzBuzz"
| n `mod` 5 == 0 = "Buzz"
| n `mod` 3 == 0 = "Fizz"
fizzbuzz n = show n

main = mapM_ (putStrLn . fizzbuzz) [1..100]

That probably won't format properly because HTML is disallowed and there's no preview button. What's up with that?

And now for something completely different. In Lisp. Recursive. And in backwards recursion. For no reason.

(defun fizzbuzz (n)
(when (> n 0)
(fizzbuzz (- n 1))
(format t "~a~%"
(if (= (mod n 3) 0)
(if (= (mod n 5) 0) "FizzBuzz" "Fizz")
(if (= (mod n 5) 0) "Buzz" n)))))

(progn (fizzbuzz 100) (values))

A simpler question, requiring NO answer: If you were writing a disk based index for fast access to usernames from id's, what datastructure would you use?

Blank Stare = Fail.
Eyes light up with passion = Hire on the spot.

Note that the FizzBuzz Test requires at least some simple number theory thinking. Yes, some small children understand it, but most people with standard schooling are not comfortable with the ideas of multiples, common factors, modular arithmetic, etc.

I only point this out because 199 out of 200 should make us question ourselves about the test. I'll accept that 90% of so-called programmers are "low functioning" but not 99.5%.

Is this FizzBuzz-style number theory knowledge required for programming? No. Does it help? Yes, a lot. I find applied mathematical knowledge to be a better indicator of quality, efficient, expandable programming than a checklist of fad languages and environments.

But, still, watch out for hiring *only* super-nerds or your product will be super clever but unusable by "normal" people. A little bit of variety of backgrounds helps.

"Beware of bugs in the above code. I have proven it correct; I have not actually tried it." -Knuth

ha ha. Lets see some ASM code. You got 10 seconds. Assuming 8086.

What a whiny post. You complain about the graduates themselves but what about the departments who taught them? If you were really concerned with the situation, rather then obliquely congratulating yourself on being so shit-hot, why not attack the professors?

PhDs do research, not programming and I've know dozens of apparently dim graduates turn into excellent developers.

piece of cake. took me about a minute to write it in php
then again, i started my days hacking Z80 assembly on a ZX Spectrum...

maybe this lack of "real programmers" is because of the growth of object oriented languages + visual GUIs - and move away from being at the coalface?

here's "fizzbuzz" in php:

for ($x=1;$x<=100;$x++)
{
if ($x%3==0 and $x%5==0)
{
print "$x\tfizzbuzz\n";
}
elseif ($x%3==0)
{
print "$x\tfizz\n";
}
elseif ($x%5==0)
{
print "$x\tbuzz"."\n";
}
else
{
print "$x\n";
}

}

I once interviewed a guy who TAUGHT programming at a city college and HE couldn't answer very basic questions about the language. My typical C++ interview question is to ask whether they understand what happens when an exception is thrown, stack unwinding, how it can cause memory leaks, and what to do about it. (someone out there is thinking the answer is "program in Java" but they should go die now)

I suspect the original observation can actually be generalized to almost any other profession/job. It seems a common complaint that one has to search hard for even basic skills and then harder for someone who will put the effort into being an employee that can be counted on to even show up regularly and actually work.
One wonders what the future holds when you read the above posts, realize that a fair number of good programmers will be leaving the market over the next decade (boomers), and hear reports of declining enrollments in the field.

I wonder how often this book is read anymore:
http://www.amazon.com/Algorithms-Structures-Prentice-Hall-Automatic-Computation/dp/0130224189

A sad fact is that many of these types of skills often don't apply in business programming, and so you lose touch. Many of the exciting routines we used to learn just don't apply. A little sad.

How about asking people the pros/cons of various types of sorting algorithms?

http://linux.wku.edu/~lamonml/algor/

Not sure what kind of educations you have over there but certainly here in Sweden you write A LOT of code if you study computer science on university or college elevel.

Even in high school programming courses you write code from day one, are you seriously saying this is not the case in the US ??

The whole thing sounds very strange to me.

An APL one-liner where INDEX ORIGIN is 0 :

(L,'Fizz' 'Buzz' 'FizzBuzz')[¯1+(L×W=0)+W{assign}(100×~0=W)+W{assign}{declose}+/1 2×0=3 5|{enclose}L{assign}1+{index}100]

"{index}100" creates a numeric vector from 0 to 99, "1+" brings it up to 1..100, which we {assign} to L.

"0=3 5|{enclose}L" compute the modulo of 3 and 5 for L. Enclosing vector L makes it a scalar, which can then be taken as argument of a modulo (primitives in APL requires vectors of same length on each side, or a vector and a scalar, the latter being applied to each item of said vector). This gives us a vector of two vectors (one for modulo 3, the other for modulo 5). "0=" gives us two binary vector where 1s point every solution where the number is a multiple of either 3 or 5.

"W{assign}{declose}+/1 2×" multiplies these vectors by 1 and two respectively (now 1s represent modulo 3, and 2s represent modulo 5), and then we sum the two vectors. "/" is an operator which introduce the function between each item of a vector : +/1 2 3 1 + 2 + 3
In this case : +/(0 0 1 0 0 1 ...)(0 0 0 0 2 0 ...) (0 0 1 0 0 1 ...) + (0 0 0 0 2 0 ...). Since the result is still a vector of vectors (with only one item), we {declose} it, which makes it a simple vector, and {assign} it to W.

"W{assign}(100×~W=0)+" : we then add this vector to another where every number not 0 is replaced by 100. "~W=0" (~ means not) creates a binary vector with 1s everywhere that's not 0, which we multiply by 100. So now we have (0 0 101 0 102 0 ...). We {assign} it to W.

"¯1+(L×W=0)+" : we use the reverse operation "=0" to create a binary vector with 1s everywhere that's not a multiple of 3 or 5 and "L×" to replace every 1 with the original number. We then add this to W, and "voilà !", every number a multiple of 3 or 5 or both is replaced by 101, 102 or 103. Since indexing starts from 0, we substract 1 from the vector "¯1+" (- is reserved for substraction, ¯ indicates negative numbers : 3-¯1 = 4).

"(L,'Fizz' 'Buzz' 'FizzBuzz')[ ...the rest... ]" creates a vector where 'Fizz', 'Buzz' and 'FizzBuzz' are concatenated at the end of L, and [] indicates that we use what's inside the brackets to index the vector to the left : 'abc'[1 0 2] => 'bac'

And there you go : Fizz, Buzz and FizzBuzz replace multiples of 3, 5 or both.

It is possible to create more readable code, but not as fun !

This code, which can be the body of a function, does the same thing in easy to read steps :

List{assign}1+{index}100
Fizz{assign}0=3|List
Buzz{assign}2×0=5|L
W{assign}Fizz+Buzz
W{assign}W+100×~0=W
(L,'Fizz' 'Buzz' 'FizzBuzz')[¯1+(List×W=0)+W]

The original post and the original quoted post do nothing except perpetuate the worst stereotype of what a good coder is. Executive managers prefer to think of their best developers as sweaty grubs who pound the keyboard (rapidly, I'm sure) and who amuse themselves with anal debates. Most of the comments here seem to confirm that stereotype willy-nilly.

"I’ve also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution."

Perhaps they became senior programmers by acquiring the habit of quiet reflection *before* pounding the keyboard (rapidly). Many executives do not understand that the person staring out the window may be getting more done than the busy people at the keyboard.

Job interviews structured to find sweaty grubs will probably find sweaty grubs...

My simple C version:

#include

int
main (void)
{
int i;

for (i=1; i<101; i++) {
if ((i % 3 == 0) && (i % 5 == 0)) {
printf ("FizzBuzz\n");
} else if (i % 3 == 0) {
printf ("Fizz\n");
} else if (i % 5 == 0) {
printf ("Buzz\n");
} else {
printf ("%d\n", i);
}
}

return 0;
}

You all are using the wrong language. Stare in awe at the power of Perl:

use FizzBuzz;
my $fb = new FizzBuzz;
$fb->print;

Isn't this an issue because you can learn to people to master a programming language but not how to solve problems? The people who couldn't solve the fizzbuzz test you describe in your article, might be great at solving well defined problems. I remember Jon Udell wrote an article about the tacit dimension of tech support:

http://www.infoworld.com/archives/emailPrint.jsp?R=printThis&A=/article/05/06/15/25OPstrategic_1.html&source=searchresult

I clearly see "problem solving" as the skill that defines what you expect to be a good programmer.

As I'm reading this blog topic and all the responses I'm having a hard time breathing for all the smug in the atmosphere (or, rather, blogosphere.)

Oh, I'm such a great programmer that I can't imagince that a professional programmer can't do hexadecimal maths, says the crowd. Look, I'm a relatively new programmer. I do exclusively VB.Net but I work daily in several applications (some in-house, and some production) and I've been programming now for over a year and a half. It was very hard at first, but I'm becoming more proficient every day. One day, I know, I'll be very good but I'm certainly not there yet. You see, I made a career change. Many of you grew up with computers -- tinkering with them, writing programs when you were eight, etc. I don't have that background. After years in the military I got out and decided I wanted to challenge myself and become a computer programmer. So I went to a two-year college, got a degree and got my foot in the door at a small software company.

If you're asking me, I'll say I've done well. I'm also probably being realistic when I say I'll never work as a hotshot programmer for Microsoft. But, you know, there are plenty of programmers out there who aren't superstars. They don't need to be. They are proficient and reliable and they get the job done. Just not superstars that eat, sleep and breathe programming. Does that mean they don't deserve to be programmers?

I understand the point of this blog -- but I just think some of you should step back and take a look at your egos. Because some of you might not have hired me and you'd have lost out on a good programmer. BTW the FizzBuzz thing would have been no problem, but I have no freaking idea what Hexadecimal maths is (it's off to wikipedia!)

Just my two cents. Narf.

I agree it is scary how few people can actually code. That being said, which version is better?

for (x=1;x<101;x++)
{
sprintf(temp,"%s",x%3 ? "":"fizz");
sprintf(tem1,"%s",x%5 ? "":"buzz");
strcat(temp,tem1);
if (!temp[0])
sprintf(temp,"%d",x);
printf("%s\n",temp);
}

for (x=1;x<101;x++)
{
if (!(x%3) && !(x%5))
printf("fizzbuzz\n");
else if (!(x%3))
printf("fizz\n");
else if (!(x%5))
printf("buzz\n");
else
printf("%d\n",x);
}

Jeff, I like your FizzBuzz question, but my use of it in screening would be different, since I see an entirely different problem in hiring a programmer.

I'd try to sit down with the candidate, ask her to do the "FizzBuzz dance" & then wait to see what she does next.

I would be disapointed not to hear some questions, like
"why should she write this code."
"should the code be maintainable, fast, memory economic or is it a show piece?"
"might the requirements change."

before she starts coding ..

After she presents a first solution, I'd change some requirements, crticise some aspect of the code (is a repeated execution of the modulo function needed/efficient, don't you know more about the sequence of numbers your processing ..)... and learn not only "can she code" (in my experience, they usually can..), but can she think, does she stand up for her beliefs, does she spot incomplete requirements, can she point out the faults politely?

Only 10% of the day are taken up by coding .. much of the rest of the time is spent interacting with the designer/architekt/manager/customer.. that's where most programmers I've employed in the past have not failed, but struggled.

When testing for language competence in my graduate class, I have the students write a program at home, but then ask them to modify it in class. While they could cheat and use a "tutor" to write the code at home - if they can't change it and run the resulting program in front of me then there is no way they can code. This eliminates a lot of the test anxiety stress which affects about 1/4 of the students while accomplishing most of its purpose.

Back in the dark ages when I was a contract programmer for about 6 months the contracting company had a neat way to do a similar test. They let you get familiar with the system and environment for about a week and then gave you a realistic problem. If you did it you were still there next week. (I don't know what happens if you didn't).

Haha, that's why we outsourcers get these jobs instead of some lame US graduates

I think this blog entry would have been better off at thedailywtf.com because it just has to be complete BS, if they have any kind of computer course and the paper isn't falsified of course they know how to solve that, if they don't then you have a serious issue in your education system.

Maybe if you stop wasting so much money bombing people and spend it on education instead ?? Just an idea.

I think the point isn't that any one of us (most likely) could spit out a solution to the Fizzbuzz problem in a minute - I had a solution in my head before I'd really tried to think about it. The point is that people go into 'programming' jobs sometimes for the wrong reasons. Maybe because the money is good. I don't know. But these are exactly the kind of folks that need to be encouraged to look elsewhere - and I mean a different career path - for employment. Encouraging folks with no aptitude for problem solving and logical thinking to work in a field where such an aptitude is needed simply drags down the team.

The problem I've seen in the past is that often those doing the interviews aren't qualified to know the difference between a person in a suit with a smile and a good disposition from a person that will actually be a productive member of an organization. This is particularly the case in larger organizations I've worked within.

Any organization that doesn't actively try to find the best people deserves what they get in my opinion.

I actually code primarily in python for its cleanliness and maintainability plus convenient methods for handling various data types, but... For the sake of curiosity, I figured I'd go for the executable line noise version (e.g. perl)

perl -e 'for (my $i=1; $i<=100; $i++) {($i%3==0 and $i%5==0)?print "FizzBuzz\n":(($i%3==0) ? print "Fizz\n":(($i%5==0) ? print "Buzz\n" : print "$i\n"))}'

I can sort of understand this problem, actually (no, not fizzbuzz - that one I get).

I graduated from a major CS school a decade ago - but the school was a Comptuer Science school - heavy on the science - not a computer engineering school. I had classes on Kleene stars and turning machines and all sorts of academic languages that I was unlikely to see again unless I went into computational linguistics. My token database class spent exactly a week on SQL - and, I suppose, with reason...that's "IT", not "CS" in their view. Of course, since I graduated I've written SQL pretty much every day of my career. We spent a lot of time discussing the finer points of various languages, spent a lot of effort writing applications that used these finer points, but didn't bother to spend much time on "what you would actually use these things for in the Real World." That fell outside the realm of "CS" again. I guess the assumption was that this is academia, not a trade school.

Of course, on the flip side, the IT program at the same school required only the most basic programming classes and a lot of business stuff. CS gave you all sorts of cool architectural techniques but few basic skills to use them, and IT gave you all sorts of practical basics but few techniques. There was a huge range in the middle where "actual programming" fell that was never addressed.

I'm not even going to go into some of the small schools with the build-your-own-degree programs.

The only reason I was ever able to hold a job or write some code immediately out of school was because of some hotshot programmer friends who showed me some stuff. Blind luck, basically.

So collegiate education seems to fall short. But that's only really a small part of the problem. From the day I started my post-college career I've been in the minority in every IT department I've ever been in - I'm usually the only person with a formal background in technology. Many people in your standard corporate IT-development department landed there by accident or by lateral move - their training includes "Teach Yoruself VB4 in 21 Days" or maybe a few classes at the local community college. I've worked with plenty of people who consider copy-paste in visual studio "code reuse", and I wouldn't say this any fault of their own - they've just never been shown what OO or even really decent procedural code looks like.

And there's the web...web development allows a lot of sloppy code to slide under the radar, it seems. If a developer has never had to solve a problem because a web browser front end lets them get away with it, they're never going to think about that problem in the first place.

I'm not sure what the solution really is - it'd be nice to have the education broaden a bit from both directions, but that will only help people who are exposed to it in the first place, which isn't often the case. Working with a good programmer helps immensely - it's what kept me from being useless for years, and I've seen one guy's good code transform the coding styles of entire companies in a matter of weeks - but how to do you guarantee a good coder in your environment?

Something to ponder, I guess.

To answer your original question: I've worked on big projects where the low-level programmers (and me, the contractor,) spent weeks or months doing cut, paste, change-the-variable-and-function-names kind of work. A person can sit in front of a computer and "program" for a long time without ever having to actually write even simple logic from scratch.
Maybe this is the "experience" your seeing on people's resumes.

It is interesting that at least two solutions given in the comments are wrong. People don't even know that they can't program.

wow.. pretty scary thought.

Interestingly, in the USA (at least in massachusetts where i am from), we used to play the same game but it was called "BizzBuzz", not "FizzFuzz".

So here is an American BizzBuzz version in Python:

-------------------------
#!/usr/bin/env python

for num in range(1, 101):
if not num % 3:
print "bizz"
elif not num % 5:
print "buzz"
else:
print num
-------------------------

lua is nice!

for i=1,100 do
fizz= (i%3==0) and "Fizz" or ""
buzz= (i%5==0) and "Buzz" or ""
print(i,fizz..buzz)
end

I've become infected with the FizzBuzz fever, too.

main = putStr . unlines .
foldr (zipWith ($)) (map show [1..100]) $
[replace "FizzBuzz" 15, replace "Buzz" 5, replace "Fizz" 3]
replace s n = fix ((replicate (n-1) id ++ [const s]) ++)

Console.Writeline("1");
Console.Writeline("2");
Console.Writeline("Fizz");
Console.Writeline("4");
Console.Writeline("Buzz");
Console.Writeline("Fizz");
Console.Writeline("7");
Console.Writeline("8");
.
.
.

Yeah it's not elegant (on purpose). But it shows that I can follow the directions and produce code that works. If the interviewer wants to do a code review and ask me to defend my methodology, I'm happy to do so.

Can anyone post the answer to the vowel/even number logic puzzle. I hate logic puzzles, but the programmer/pessimist in me says all 4 because you never know what the next input would be. However, I'm guessing the answer he wants is "A" and "2"?

to LKM:
i am sorry if you felt my message as hostile. english is not my native language and i may sometimes seem a bit rude (i do seem rude anyway on my daily life). it was not meant to be offensive at all, and i deeply apologize if you took it that way.

anyway:
"Do you understand that by using a local stack instead of the call stack, the computer needs to keep track of much less information and needs to do much less work building and tearing down the call stack? In most languages, using a stack instead of recursion speeds up your app tremendously."

yes i do understand. it is just less error prone to let the computer do the stack keeping for you. also, a good compiler will have a good optimizer which will make handcrafted optimization look slow (unfortunately, apart from tail recursion, recursion is not the favorite playground of optimizers).

but, as always, the solution used to solve the problem will depend greatly on the domain you are coding for. you will not code the same algorithm for an embedded system, a large-scale data-center or a desktop application. you will definitely have to make tradeoffs between resource usage, reliability, and ease of programming.

Perhaps I'm failing my Sense Motive roll, but I'm truly saddened by the number of people who not only posted the solution, but posted the *wrong* solution.

Go back and count the "solutions" that failed to print the values from 1 to 100. Go back and count the solutions that started a loop at zero instead of one.

So sad. I really hope that they were deliberately wrong to keep the script kiddies from getting a job. In fact, my sanity requires that I chose to believe that.

int main() {
printf("Get back to work!\n");
return 0;
}

rien: I guess something was lost in translation then :-)

Sure, creating your own stack has its own sets of problems, and it's not suitable to replace all usages of recursion. It's often a good idea, though. I'd say that using a stack instead of recursion is not so much "handcrafted optimization" as it is "avoiding expensive patterns where they are not needed" :-)

Fortunately, coding is merely my hobby. The one time I applied for a job, I did have to do some basic code in front of the owner of the company. He asked me to do something basic that I hadn't done in C in many years, so I couldn't remember the commands, so I had to resort to the last language in which I had actually done it: REALbasic. That was a bit embarrassing, to say the least. I also had to recode the script in front of him, because I wrote it under a minute and had a few logical errors in it, which I corrected. Then I optimized it in front of him, which I couldn't walk away without doing. I didn't get the job (thankfully), but I was one of the top two candidates. The only thing that won out the other guy in the end was that he had more experience with .NET than I did. Or so they told me. Could very well have been that I was a colossal embarrassment, but they were too kind to tell me. Who knows? But I do know that I'm glad I didn't get the job. I just haven't got the chops to sit in a room and code all day, not even for pay.

So, exactly where are you FINDING these job candidates? sounds like a piss poor advertising and recruiting practice if 99.5% are not valid candidates.

Geesh, I advertise on Craigslist in Austin or Phoenix and over 1/2 of the people who apply are able to pass a test like this. And this is with modest pay for an easy and flexible work at home job (ssh, svn, etc). Plus I get maybe 10 to 15 replies running the advertising 1 time, and those replies come in within the first 5 days. So I get 5 to 8 real job candidates and I can focus on long-term aspects of which person is best.

In other words, just like writing a good resume is important, writing a good job description and knowing where to find people is just as important.

For some reason,(maybe because I am now only a hobbiest) I still use qbasic for brainstorming and pseudo-code)
X=0
Do
X = X + 1
outstring$ = ""
If x mod 3 = 0 then outstring$ = "Fizz"
if x mod 5 = 0 then outstring$ = outstring$ + "Bizz"
if len(outstring$) = 0 then outstring$ = str$(x(
print outstring$
Loop Until X = 100

Here's a "clear" Lisp version:

(defun fizz-buzz ()
(loop for i from 1 to 100
do (cond
((= 0 (mod i 3) (mod i 5)) (format t "FizzBuzz~%"))
((= 0 (mod i 5)) (format t "Buzz~%"))
((= 0 (mod i 3)) (format t "Fizz~%"))
(t (format t "~a~%" i)))))

lua still nice even doing what the problem states!

for i=1,100 do
fizz= (i%3==0) and "Fizz" or ""
buzz= (i%5==0) and "Buzz" or ""
number= not ((fizz=="") and (buzz=="")) and "" or i
print(number..fizz..buzz)
end

"It is interesting that at least two solutions given in the comments are wrong. People don't even know that they can't program."

People might know how to program, they just don't test what they program!

If I'd been given the "swap 2 values with no temp variable" problem before yesterday, I probably would have said "you can't do it".

Now that I've seen the trick (which isn't a general solution. It only works for integers, and only those containing values that won't overflow when added), I probably would have said "you shouldn't".

I've been developing software professionally for 18 years now, for fun about 9 years before that, and have at least 6 assorted Free or Public Domain projects under my belt. Does my "incorrect" answer to that question make me a bad programmer in your eyes? Given that your "correct" answer is something I'd slap someone for trying in any code I have to maintain, I think I'd prefer to not get that job anyway.

As for the issue about recursion, in my experience most software developers (even fairly good ones) are scared of it. I wouldn't consider that a deal-killer for hiring. I was scared of it too, until I took a Lisp course in college. Its probably a better test of Lisp exposure than anything else.

On the other hand, if you are scared of it, be honest enough to admit it. Don't throw me some (possibly true) pablum about explicitly using a stack being just as good, and faster in some cases.

If an algorithm is naturally recursive, recursion is probably the best expression of that. As for the speed issue, I agree that a good programmer doesn't do things that are going to be massively slow. However, they also don't pervert their source code for optimization purposes. That's the compiler's job. If the compiler fails, *and* you have a known speed problem, *and* you have tracked a big bottleneck down to that chunk of code, then you may source-level optimize. Otherwise, just make it as understandable as you can, please.

However, I would consider "I have trouble with recursion, and so does nearly every other developer who will have to maintain this code", a compelling argument.

I interviewed at a place with a fairly stringent testing regime last year. There were many "write on the board" SQL questions and some Java pair programming with one of the team leaders.

Unfortunately, although I nailed the whiteboard part, I did poorly on the pair programming portion. I didn't handle the context shift between VB (which I was using on the current gig) and Java well enough, and kept foolishly expecting Eclipse to get the case on my variables correct for me, leaving off semicolons, stuff like that. It was embarrassing, considering that six to eight months previously I had been doing a lot of Java.

I suppose I would have done better had I freshened my Java knowledge a little before the interview, but I had an informal offer on the table for a lot more money and was going through with this interview for, shall we say, domestic political reasons (i.e. my wife didn't think the existing offer was official enough and would have killed me if I'd cancelled this interview. Because of the pay discrepancy and the awkwardness that would have ensued in trying to negotiate an informal offer against an inferior, but formal one, I actually dreaded the prospect of an offer.)

Some of these tests are fine, but I'm sorry... OCTAL? Almost -nobody- uses octal anymore. You're rewarding programmers for learning stuff they'll never have to use. If they ever need it for some crazy reason, they can always use google and spend two minutes learning how to interpret it.

These tests can't determine whether a programmer is economical, which is the secret to what actually makes programmers good. I've seen many programmers who are much smarter than I am destroy projects, because they spent too much time hacking on the 20/80 stuff instead of picking their programming battles wisely. Good programmers get the job done, which is why the best test for programmers should be their ability to create stuff (like projects, OSS and whatnot).

(python)

for i in range(1,100):
if i % 15 == 0: print(str(i) + ' fizzbuzz')
elif i % 5 == 0: print(str(i) + ' buzz')
elif i % 3 == 0: print(str(i) + ' fizz')

(c#)

for (int i=1; i<=100; i++)
{
if(i % 15==0) Console.WriteLine(string.Concat(i, " FizzBuzz"));
else if(i % 5 == 0) Console.WriteLine(string.Concat(i, " Buzz"));
else if(i %3 == 0) Console.WriteLine(string.Concat(i, " Fizz"));
}

I had recently gone through a few interviews - some good and some bad.

I thoroughly enjoyed one in particular for Blackbaud (Charleston, SC) where the team lead asked me through some real basic questions (something like storing people's favorite activities) that covered relational database, OO, and web-based design concepts. Nothing particular hard - but worthy of actual thinking. Then she went and expanded the basics a few times and had me explain what I would do - which covered nicely aspects of software maintenance that I reasonably expect most get to deal with. I did get the offer, but couldn't take it (in the end) because I had hoped I would sell a house in another state ... it was very complicated :)

Then I think back to another interview where there was a programming test. And I just completely bombed it ... I mean TOTAL brain fart. How embarrassing! I've gone through others and did completely well, but like how some interviews go (or at least for me), some go really well, and some just don't. Including programming tests. Well, the job was probably too far west (San Francisco) for my family anyway...

We've had a fair number of interviewees who couldn't write a very simple program. But I bet a fair number got home and realized that they could do the task easily under normal conditions, but had freaked out with interview anxiety.

seq 1 100 | sed '0~3 s/[[:digit:]]*$/Fizz/
0~5 s/[[:digit:]]*$/Buzz/'

While I understand the problem of programmers who can not program I really have no empathy for those of you doing the hiring.

I went to a little community college and got an A.A. while there I learned to program in C/C++, pascal, cobol, QB, and AS400. Since college I have taught myself 3 new languages and if I were to interview for a programming job would have brushed up on the syntax enough to have easily passed any of the "tests" listed on this page, yet none of you would have let me get that far.

Since I have only an A.A. no one seems to want to even bother interviewing me much less test me to see if I "have the skills". Yet they fall all over each other trying to "catch" one of the kids that used to come to me for help on their assignments week after week. Because those same kids went on to get a B.A. or a B.S. while I decided I was deep enough in debt and went out into the world to do basic comp. repairs.

It has been my experience that those who programmers who fail your little tests are most likely failing not because they can't program but because they have a problem applying their knowledge (it is a fine line but a valid one). Much like most high school grads these days seem to know the basics of proper grammar but could not compose a decent letter to save their lives.

That's my opinion anyway, take it for what it is worth.

quote: it's the standard a=a+b, b=a-b, a=a-b problem

Hopefully a and b aren't near MAX_INTEGER. In fact this is a worse solution than doing something obviously wrong as it will only come up in the weird cases making it even harder to debug. This is a terrible way of doing it, you fail!

Toepopper wrote

Very very common, alas. I once interviewed a candidate for a VBA job (yes, you can stop booing for the peanut gallery) whom I asked to swap two variable contents without using a temp variable. It's the standard a=a+b, b=a-b, a=a-b problem. His answer? Well, I can't do it in VBA, but if you let me use Excel I can put the values in two cells and swap the cells' contents using a third cell.
We hired the guy who said, well, "if they're integers, then I'd do it by a=a|b, b=a^b, a=a^b. But I don't know how to do it if they're strings."

Toepopper on February 27, 2007 01:49 AM
I think Toepopper hired the wrong fellow, because his "swap program"
is logically flawed. After looking up the meaning of the | ^ operators (i.e. | = bitwise OR and ^ = bitwise XOR), I attempted a formal proof. I could not get it to work out. So I tried a simple case. Suppose we have 1-bit words and

a = 1
b = 1

After a = a|b:

a = 1

After b = a^b

b = 0

After a = a^b

a = 1

And you can see, a swap has not occurred.

ECMAScript Solution:

function fizzBuzz(lim) { var msg=''; for (var i=1; i<lim+1; i++) msg += (i%3==0 && i%7==0?'FizzBuzz':(i%3==0?'Fizz':(i%7==0?'Buzz':i)))+' '; return msg; }

Hi!

I am writing from India.India is becoming famous with IT and lot of software development stuff happening here.
But,to my surprise,people in large organizations hires the candidates from the campuses with bulk entity and not even asking any fizz buzz questions.
I have given number of test with smaller organizations which requires to pass technical test or code right away at the time of test.
and I opted for such a company.Now,reading this article I think my decision is *really* good.

Another point to be made is should *years of experience* really teaches us these things in programming???
and if no then why do all software companies ad mentions the years of experience instead of asking for some other point...

please comment..

It seems to me that most of the comments here are focused on the actual code solution for the FizzBuzz question. I would like to step back and talk about the actual lack of programming knowledge possessed by those that apply for these programming jobs. I would say that the reason that so many numbskulls apply for these jobs is because somewhere in the job requirements it says that applicants must have at least a Bachelors in computer science. Most of the best programmers I have ever known, including myself, do not have a degree of any kind, and in my case, never went to college. Yet, many companies will simply push your resume aside if they see that you do not have the required degree, no matter what you skill level may be. A degree is just a piece of paper that says that you have sat in a class for x number of hours learning about something that you may or may not remember when you leave. If companies want to find real programmers with real programming experience they need to broaden their search or have a little slack when it comes to their job requirements. I guarantee that they will interview many more applicants with a deeper knowledge of the force.

Dave: "Note that the FizzBuzz Test requires at least some simple number theory thinking."

It's extremely simple number theory thinking, that people in all fields should know. The word "multiple" is basic vocabulary, and any grown-up with an IQ over 80 ought to be able to understand what it means.

That's a relief. I'm like "Dang! What if I'm one of the ones who can't do that?!" The script below is probably a little inelegant, but it works. Took about 5 minutes, but part of that was talking to a co-worker about nasal irrigation.

<?php
for($i=1; $i<=100; $i++) {
if ($i%3 == 0) echo "Fizz";
if ($i%5 == 0) echo "Buzz";
if ($i%3!=0 && $i%5!=0)
echo $i;
echo "<br>\n";
}
?>

Or how about,

$s = '';
for($i=1; $i<=100; $i++) {
$s .= ($i%3==0)?"Fizz":"";
$s .= ($i%5==0)?"Buzz":"";
$s .= ($i%3!=0 && $i%5!=0)?"$i":"";
$s .= "<br>\n";
}
echo $s;
?>

I prefer readability to compactness.

Mike H, the answer to the vowel/even problem is "A" and "3". It would be all four only if my theory were if-and-only-if, but that's not what I specified.

Jeff, thanks for posting this one, I've found replies really engrossing. Readers identified three problems worth solving:

1. Write FizzBuzz code
2. Distinguish good programmers from lousy ones in an interview
3. Fix the educational system that produces these morans

It's been a pleasure to read proposed answers for all.

Big Playa - re-read the requirements... you failed.

I ask the candidate to write a simple but full-fledge class from scratch. (Many can't)

I also provide a series of assertions and ask the candidate to write code that passes those tests.

However, writing code on a whiteboard is hard even for me, and I've written a lot of code in the last 20 years. These days I'd provide the candidate with a laptop (if they don't have one with them) and watch them code and test their code.

Anthony -> thats what i look for when hiring - experience and aptitude over qualifications. and i really dont care how many "certified whatever" post-college qualifications you have either.

a portfolio is essential. past experience too and a willingness to learn. some of the best coders i've met have never gone to college either. the ones that did go to college and were good coders after , were coders in their teens pre-college.

i think the problem lies with folks that never programmed before college and just did the course to get this mythical enormous "I.T. salary", without necessarily having any aptitude or love for the subject.

I dont know a lot of the languages used in here, but im guessin about one fourth of the answers to FizzBuzz are wrong.. I mean:

for num in range(1, 101):
if not num % 3:
print "bizz"
elif not num % 5:
print "buzz"
else:
print num

I dont know Python but that code looks like it doesnt print the bizzbuzz, am I rigth or is Python just weird?
i hope Im wrong cause this is sad..

I can't believe no one has put up the Perl Obfuscated version of the FizzBuzz:

map{$_=(!($_%3)&&!($_%5)?"caddeidd":(!($_%3)?"cadd":(!($_%5)?"eidd":$_)));y/cadei/fizbu/;print"$_\n"}(1..100)

My obfuscation powers are weak this morning, I'm sure it could have been done much better.

Incidentally, if this were the interviewee's answer, I would probably not hire him. I might invite him to become a member of Perl Mongers, though (http://www.pm.org)

About 8 years ago, after a UK conference on teaching the new language of Java, one of the attendees said that we certainly needed to change something -- the final year students on the Comp Sci course at his prestigious university were not confident in writing any program, even one just 10 lines long. Other people there agreed that it was not much better, if any, where they worked. Surprised, I went back to my much less prestigious place where all our students took joint degrees, Computing and Maths, Computing and History etc and and checked with my final year OO class. I had real difficulty explaining the question, even though I upped the size to 20 lines -- they just could not imagine anyone on our (half a) degree course, even those who had dropped programming at the earliest opportunity, being unable to write proper programs. What was the difference? Maybe a culture of 100% attendance, and the fact that, not being much of a research establishment, we did not farm out the practical labs to uninterested grad students.

On recursion, I stand by my advice to students. You should know what it is, how it works, and how to program it. But you should _never_ use it in production code, because whoever maintains it may not grasp what is going on.

On swapping the values of two variable without involving a third, I am torn. I agree it is irrelevant to much of modern programming, and is probably not taught in most places. But it does provide a good test to see if someone has read around the subject a bit -- and if they haven't heard of it you could use it like Ben's test to see if their eyes light up when you say it is possible.

Mike Woodhouse - "As I'm about to start looking for a programmer I shall be able to implement my long-cherished plan of asking candidates to submit a page or so of what they consider to be "good code"."

So where can we send our resumes/good code?

And yes, I can write the fizzbuzz thing. :P

I must say, that things like this are necessary. I hired developers for a small low budget startup before and you get any hack who has written HTML applying as a "programmer".

Also, knowledge of the framework is beneficial but does not mean you can write a line of useful code. It means you know how the framework works, and frankly that's what docs are for.

A true "programmer" can write code without knowing the framework and generally the code will run efficiently and well with only minimal need for tweaking to optimize it for the framework it's on.

What is recursion and hexydecimal?
.
.
.
.
.
Sorry, couldn't resist.

It is sort of funny that a lot of people who posted solutions here did not print the actual number on the condition of (i % 3) == (i % 5) == 0. Just goes to show you, being a good developer isn't just about writing code, it's also about reading comprehension! READ THE SPECS!

I also wasn't familiar with the "xor trick" of swapping variables that Toepopper mentioned in his first post and that others have mentioned here. However, I'd like to think it's an indication that I'm a good programmer that I immediately noticed it was suspicious, and a quick google search confirmed that it was in fact wrong (all three operations are xor, whereas the one posted used an "or" on the first one). If that is actually what the interview candidate stated, it would have been a bad sign to me, a sign that either they'd seen the trick before but didn't understand it, or understood the form but not the function (cargo cult).

As others have said, though, the only time I could ever see this being used is in an embedded system. Outside that domain, it's essentially just another brain teaser, one of those things that when you know the answer you go "oh, that's so easy!" but could spend days thinking about if you haven't seen it before. Those of you who keep saying that every competent programmer should know this, please ask yourselves what it says about _you_ that you can't tell the difference between a simple problem with a mundane solution and a "gotcha" question.

A little bit more searching indicates that the xor swap may perform worse than a temporary variable anyway, due to processor pipelining. I'm not sure whether or not that's true, but even if it isn't, compiler optimization would make the two methods at least equal in performance. I also found a post (http://blogs.msdn.com/rick_schaut/archive/2004/03/06/85357.aspx) which asserts that an optimizing compiler might just change all subsequent variable references after a temp-variable swap, which would make the xor swap slower. Stupid code trick indeed.

Bottom line - if I ever saw this "clever" trick used in modern non-embedded code, I would consider it and everything else around it to be suspect. I can't imagine anything worse than a developer using one of these lame tricks and making a typo or getting it wrong, then having to spend days or weeks searching for the source of the problem. That trick is an antique, completely irrelevant to today's programming problems (except maybe if you're writing an optimizing compiler).

all right. At least let's make it interesting.
Post the *tests* for FizzBuzz that you'd write *before* writing code !
Heck, I'll take unit and/or acceptance tests.

What's pretty dang funny is how many of the code examples above are wrong. That shows either one of two things, you misunderstood the requirements, or the even more fatal, YOU DIDN'T TEST YOUR CODE. Also the amount of of bombs we drop on suicidal muslim extremists has no bearing on this topic. As for outsourcing my old boss, when told we needed two more guys for a certain project, would say "OK get me 10 indians".

uglydawg: I don't even think a BS is enough these days. Completely unable to find a good programming job with mine. I was lucky enough to get a clerical position at my current company, and then the main programmer for my department left so I stepped in.

The problem is I'm still technically in the clerical position because they won't promote me. :(

The point of the interview should not be just to find a question that will trip people up. I'd get the swapping variables question wrong (well not any more) but I've generally do better the more technical the interview. It would seem silly to give the FizzBuz test and say "HA! You got the syntax of the modulo operator wrong (while writing the program out longhand under the pressure of an interview and not having tools to unit test it)! You are NOT a programmer!" It's the people like that the database analyst I interviewed who couldn't write a SELECT statement that deserve that ridicule. (Then again you might be looking for an embedded systems engineer who can do the variable swapping thing and not care if they know SQL. It's not one-size-fits-all.)

> Can anyone post the answer to the vowel/even number logic puzzle

I hate these puzzles as well, but because they often hinge on some pedantic phrasing. In "the real world", there is usually some system against when you can test your understanding normally, some shared organizational expectation of the meaning, or some person involved in writing the spec/question you can go to for clarification. (that is, unless you're trying to maliciously follow the spec =-) )

Now I'm not actually familiar with this puzzle, but the phrasing makes the answer pretty clear in my head.

"I have a theory that if there is a vowel on one side of a card, then there will be an even number on the other side"

That is, he says "vowel on one side => even number on other". He's not saying that whenever there's an even number there will be a vowel. He's also not saying that a consonant implies odd number (similar to previous sentence).

You only need to check one card: "B"

I read statements like "demand for programmers is outweighing supply" and "99% of comp sci grads cant write fizzbuzz" and its very encouraging. I didn't go to school for comp sci, but I could write the fizzbuzz in under ten minutes, including the time it took me to figure out how to use g++ from the command line. I'm by no means an excellent programmer, but if most applicants are really that bad, then I think I could be quite competitive. Is that a bad attitude? I'd like to think not, because u