FizzBuzz entered the software development lexicon in 2007, when Imran Ghory wrote a post about a simple programming problem that can weed out those who just aren’t very good when it comes down to actually writing code.  The task: “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 ‘FizzBuz’.”  If you can’t write that out in a few minutes, I don’t want to pay you to write code for me.  As Mr. Ghory mentions, a depressing percentage of candidates can’t do this in a timely fashion.

This doesn’t surprise me.  Thanks in no small part to this classic post from Joel Spolsky, I believe very strongly in making candidates program in their interviews.  At my last job, my main role on interview day was to prompt candidates to code on the spot and help them along just enough to keep them moving when they got stuck.  I always started them out with something even simpler than the FizzBuzz problem: “Print out all of the elements in this List” (it’s a Java interview).  Most people got through it very quickly, and perhaps we’d go from there to a brief exchange about exception handling or the behavior of toString() and why every object will have that method defined.  For some, it was problematic, but I’d give them a chance to print out elements of an array, or to do something similar in the language of their choice, and at least that would keep us moving.  However, about 15% of my interviewees crashed and burned here.  These people might possibly write decent code, when given an IDE with code completion hints, but if that level of coding isn’t fully burned in one’s brain after doing even a fair amount of coding in college, I don’t want to take my chances that said candidate will ever reach a barely-acceptable level of productivity.

These “immediate no” candidates had already convinced HR that they had sufficient qualifications for the position, and had already provided answers to specific technical questions I asked them on the phone.  If not for the coding exercises, we would have made a couple of seriously damaging hiring mistakes.

Here’s my preferred interview structure for anyone that’s going to spend significant time mucking about in my code base.  This assumes a position that will be doing web application development, but also a helping of “mad scientist” work – the kind of work that goes into building a revenue-optimizing ad platform or a search engine.

• Head of the department asks the soft questions
• One coder asks questions about high-level software design issues and specifics of relevant platforms
• One coder asks questions related to algorithms and data structures
• One coder (or perhaps two) asks the candidate to work through some programming problems

The specifics should be modified for the level of the position being discussed, and it’s not so important how the questioning is split up among interviewers.  For recent grads, I’m not too troubled if they’re a blank slate when it comes to design patterns.  For senior candidates, that’s not okay. (Side note: I don’t care so much if someone doesn’t know the names of patterns or can’t enumerate a bunch of them.  I’m more interested in seeing if they can come up with a decent high-level design for a problem that a popular design pattern solves well.)

Do me a favor – tell me about your interview process, your worst interviews, or what’s wrong with my suggested interview schedule.

P.S. Bored?  Check out this solution to the FizzBuzz problem. It has no branches and involves the number 19142723.