So the author has decided to set the bar ridiculously low. As the post says:

I’ve come to discover that people who struggle to code don’t just struggle on big problems, or even smallish problems (i.e. write a implementation of a linked list). They struggle with tiny problems.

He gives an example of a “tiny” problem that is quite suitable for a phone interview:

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

One of the nice things about using a tiny problem is that anyone who has written actual code in the last six months will solve it in less than ten minutes. This is good because (a) it leaves more time for talking about important things, and (b) if the candidate can’t solve the problem you will find out right away and save yourself a lot of grief.

Right away I think you want to be careful if you ever trot a solution like this out in an actual interview. Here are some of the things that could go wrong:

The interviewer merely wanted to go through the motions of demonstrating you could program. Now she’s going to have to get into a discussion with you about how your solution works, which is irritating and wastes time that could have been invested more profitably on a design question;

The interviewer might presume that you will always find the most indirect route to the destination and decide you belong in an ivory tower;

The interviewer might not understand your solution at first glance but will make up for this by “bikeshedding” and grilling you about some minor nit like the failure modes of using && and || instead of the if statement or the ternary operator;

Of course, some interviewers are just looking for an excuse to talk about technical issues and will not prejudge you in any way. Speaking for myself, I would laugh if you wrote something like this out. But then again, I once worked for someone who had won the second International Obfuscated C Contest.

Update: Don’t Overthink the Interview Either

If you are conducting an interview and you receive a cryptic answer, or an impossibly concise one-liner, or perhaps something like the above that is redolent of Higher Order Functions, do you embrace the candidate as a genius? Or perhaps avoid them as someone who cannot write clear, maintainable code?

I suggest the best answer is neither. Stay on track: you asked the question for the purpose of eliminating the 199 out of 200 that have absolutely no hope of ever producing working software. You have just identified that this person is the one in two hundred applicants who can actually code. Mission accomplished. You aren’t trying to get to HIRE or NO HIRE over the phone.

Invite them in for an interview: that’s the place where you can drill down and obtain their views on professional programming. Remember, this is a toy problem. Unless you load the question down with requirements that their answer resemble production code, why should you have any expectation that the candidate only knows one way to write software?

This is like trying to hire programmers who know both languages, FORTRAN and COBOL.

If you do ask them for production code, don’t be surprised if the best candidates decide not to work for you: they will rightly point out that FizzBuzz is not a realistic example of a production problem.

Overall I think the best approach as an interviewer is the simplest: pose the simple question. Indicate it is a screener designed to confirm that they are the person described on the resume.

If anything, tell them that there is no need for production artifacts like documentation and unit tests, you just want working code in as little time as they are able. The no-hopers won’t get it no matter how simple the question, and the good people won’t waste a lot of time with JavaDoc and xUnit.

And then make your decision based on one objective fact: does the code run and produce the desired output. Everything else is superfluous to the question of whether the candidate should be asked into your office for a face-to-face meeting.

It does seem like a drag over the phone, but after you've had a morning where three straight applicants came in for an interview and failed, you don't want to see anyone else without them passing one or more of the five essential phone screen questions.

As for email as an alternative... I'm not sure. This definitely lets them go through hours of trial and error, so you can't judge whether they more-or-less get it right off the bat.

I don't care so much whether they get the braces right as I do whether they dash it off almost immediately.

Someone claiming to be "Seth Gordon" wrote to say: My wife got me this for a birthday present, and I set it up in my cube. I was a little disturbed by how many of my co-workers couldn't figure out how to read it.

Seth, I deleted the comment. If this is on-topic in some way and not spamacious, please write back explaining the relevance and I'll be sure to let your comment through.

In the mean time, I must admit that a desk clock in binary does sound interesting, so I've modified the link to support the raganwald hosting costs.

I am a system admin, and I have always been very careful not to call myself a developer.. even though I can code fairly well (rusty as my "coding" usually is modifying someone else's to work how I want it too.) I can definatly design a program or system.. What you are saying here is that perhaps I should apply for Dev jobs?? It has been something I have never really done because I always figured good devs are all kick ass coders and I, by my own definition, am not but a okay one.. functional I should say..

food for thought..

Wow.. this gives me alot of insight into why the worst, most unrealistic users internally are the development department.

As for those who are all education happy.. well I have hired more then my fair share of university grads and I can say from experience that %99 of them are completely useless. A degree is a wonderful thing for advancement in management, but when you are looking for someone who can DO something, there is NO replacement for experience and the true hacker attitude and thirst for knowledge. If you want middle management drones, hire a University grad, if you want someone who is going to be Code Warrior, or a Systems Guru, hire someone who has been doing computers when they were 6 and live, eat and breath them day in, and day out.

The guys I know who I would call coders.. they code when they get up.. then go to work and code.. then come home (IF they come home) and code.. code code code... I gave up on Development years ago because I get WAY too obsessive. Still.. wouldn't mind getting out of what I am doing now, so I am sharpening up my Foo.. it is the FuzzBuzz test I should get the job it sounds like!

I just gave my non-programmer wife a 5 minute Ruby lesson and she was able to write a FizzBuzz program in another 5. After spending the morning doing college-hire interviews and seeing evidence that a CS degree does not mean the ability to code, this is a depressing commentary on the state of CS education.

The assertion that less than .5% of "Progammers" cannot get this correct is absolute poppycock. I performed this test on my 10 of my developers and ALL of them got it correct - most in less than 2 mins. Once again - a blogger making up a stat and trying to pass it off as fact.

This is a tacit or functional solution, as the input parameter (number of integers to print) is not specified in the function FB. The function FB is defined in the first line, and invoked in the second line. The right argument of FB in the second line simply generates all the integers between 0 and 99.

Man, you programmers are out there. I'm not even sure if you're speaking English. I could participate by throwing in some lawyerese like, "the party of the first part assigns all rights, interests, claims, actions, suits, or entitlements, now existing or accruing in the future, to the party of the second part and forever waives, releases, relinquishes, and foregoes any recourse for itself, its assigns, successors in interest, officers, directors, representatives, employees, or other interested party..."

Actually, there is some relationship to coding here because a misplaced or omitted comma can change the entire agreement -- much like a missing paren. or tag can cause errors.

The sad part is that I went looking for a solution to a plugin issue I have on my blog and got so caught up in the FizzBuzz discussion that I had to see what a solution looked like. I freely admit it. I would not have been the 1 person who came up with the solution off the top of his head, but then, I highly doubt I would have said that I could on any resume. Unfortunately, I have just spent about an hour reading stuff because I found it interesting rather than a) solving my plugin problem; b) doing real work for which I would like to be paid; or c) going home and eating dinner. This to me is the REAL danger of Google. It's too diversion-friendly.

Eversman I presume! - that's exactly how I ended up here too! And, no, I have no idea what this is about either. But it is interesting, that I stumbled into this dark pit of cabalistic babble only to find traces that another human had passed here before - it made me feel like I was on a journey to the centre of the Earth. ;) as they type...

You are correct that writing code like the example provided is not evidence of brilliance. That's actually what the post says, please read it again, and one more time if it doesn't seem clear.

Furthermore, getting the problem right in the strict sense of a program that produces the correct output does not place you in the top .5%, nor does it make you above average. The Update in the second paragraph supplies the explanations for why this is the case.

I suspect you have failed to realize we are actually in agreement. In the interest of exchanging colloquialisms, I wonder if you have scored an "own goal."

Most people reading this will be horrified at the thought of so many students having so little to offer. I would think it is time to start questioning the tutors of their universities/colleges under the sale/provision of goods and services act (or relevant law in said country) perhaps

I just found this today, and spent way too much time over-thinking fizz-buzz. I love seeing the functional ruby code ( because i don't fully grok the functional code yet, but dream in ruby ). But I think it took me a while to understand your solution because it is broken. The "carbonation" is dependent on starting at zero. It creates a function that accepts "n" then constructs the "n"from "i"? try this for range (2..101) you'll see what I mean. But still a good blahg-post, got me thinking.

I find your statistics pretty appalling - but that's one of the reasons I got out of full time programming (I still do some freelance work). Among other things, I got tired of cleaning up messes that other "programmers" had made and surprisingly, or maybe not so surprising to you, many of them had pretty impressive educational credentials.

Write a program that prints the numbers from 1 to 100. But for multiples of threeprint “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”.

Poor specs like this are a problem. Lets look at:

1) It makes the reader believe that multiples of 5 should be replaced with "Buzz" but doesn't clearly state it.

2) Through normal logic one would assume that 'FizzBuzz' is the result of 3 & 5 having both passed,but the spec doesn't state that either. The person has interpret it their own way which is bad practice,so instead he/she has to waste time/energy to get in touch with the designer to reclarify the design theyshould have written properly in the first place

3) There are quotes used in the spec without the commonly used 'without the quotes' statement which meansit is fair to print the full terms.

Code works or it doesn't work. If the spec is crap then you're gambling.

If the interviewer gives foolish examples like that then I just hope I don't work on the same team with him.

Some people can't write specs just as some people can't design user friendly interfaces to their own software. At any rateit is unfair to blame the outcome of poorly written specs on the people who had to try to make sense of them.