The twitterverse has been alive with discussion about the generic FizzBuzz test and it’s effectiveness as a filter in the hiring process. There has been mixed reaction from both sides – some find it an effective way to weed out candidates, while others find it an uninteresting or even insulting approach to hiring. There’s even reports of candidates leaving the interview after being asked to complete FizzBuzz!
For those who don’t know, FizzBuzz is a fairly simple coding problem that is being used more and more by companies trying to hire programmers. The basic premise (from Using FizzBuzz to Find Developers who Grok Coding):
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”.
Sounds simple, right? It is! It takes most programmers with experience less than a minute or two to write some pseudocode to solve this problem. It isn’t language-specific, doesn’t require any domain knowledge, and can be solved by pretty much anyone who’s taken a middle-school programming course.
And it’s boring.
I get it. When you apply at a new company, you want to see what problems they’re solving, what you can learn, what you can contribute. You don’t want to waste your valuable time writing a if statement inside of a for loop.
If we flip the tables for a minute and look at it from the interviewer perspective, FizzBuzz is a low-cost barrier to entry. As someone who’s recently attempted to hire someone, I can tell you that it can be a painful, time-consuming, and sometimes futile process. 90% of the 100 applicants in our last job posting were recruiter spam – and we don’t even live in a major city! Of the five we eventually gave a take-home test to, only two of them actually completed it.
We need to make sure you can write code, and we need a low-cost way of doing so. Sure, we can develop crazy complicated/interesting/fun tests in order to do so, and we do, but those take a long time. To do interesting tests properly, you have to create a problem, solve it yourself, and get other people in your department to solve it to set a bar. And you’ll probably have to tweak it because it’s too language-specific/domain-specific/takes too long/etc., and start the whole process over again.
Now imagine after all this work, we sit down with a potential candidate, and give them this super cool problem we’ve created. They respond by asking what a for loop is.
It’s perfectly legitimate to expect us as interviewers to spend just as much (if not more) time on our job application and hiring process as each individual candidate does applying for the job. I would expect nothing less from any of the companies I apply to. However FizzBuzz, in addition to other problems/tools/assessments, provide a low-cost (in the sense of time investment on both sides) solution to making sure you can at the very least write code.
Then there’s the applicants that leave the interview when presented with FizzBuzz. I think there’s more to it than just being upset at the problem – odds are there’s one or more other flags that were raised throughout the interview(s) process and perhaps FizzBuzz was the final straw (or the first opportunity to leave).
In any case, a developer who leaves because they were presented with a simple or uninteresting problem is a red flag for myself as an interviewer. We all know we can’t face interesting problems every day in software development. If a candidate can’t handle that for two minutes, then how are they going to work a 40-hour work week?
All this being said, I’ve only used FizzBuzz when interviewing co-op applicants or new graduates. I think it’s a perfectly valid filter to separate those who can code from the rest of the applications. Once they’ve completed the problem, we give them more interesting problems in the form of whiteboard questions and take-home tests. FizzBuzz is just one low-cost tool in the repertoire of interview techniques we use, and it’s already saved us from a few potentially bad hires.