The Fizz, the Buzz, and the Ugly

FizzBuzz is a simple programming problem that’s often used in an interviewing context or as the basis for exploring the nuances of test-driven development. It can be useful for purposes like those, as the problem itself isn’t so complicated that it gets in the way of the goal; either vetting very basic programming skills or providing an excuse to practice coding technique.

In either case, the resulting FizzBuzz solution isn’t the point of the exercise. When used as an interviewing tool, the purpose is to find out whether the candidate has even the most rudimentary programming skills. Many people are good at talking and not so good at coding. FizzBuzz can be a time-saving device to weed out candidates who aren’t up to the challenges of the job.

When used as the programming exercise for a code dojo or other individual or group practice session, FizzBuzz offers sufficient functionality to drive at least some design decisions, while also being uninteresting enough that people aren’t distracted from focusing on coding technique, which is the purpose of practicing.

Let’s consider the usefulness of FizzBuzz as an interviewing tool.

Again and again, it has become the subject of a flurry of posts on blogs, wikis, and social media. Again and again, the pattern is that someone mentions FizzBuzz and dozens or hundreds of people take it as an invitation to submit solutions.

The solutions they’ve submitted raise an interesting point about FizzBuzz, and probably other problems of similar difficulty, when used in an interview setting. To illustrate, let’s take a look at some of the solutions people have submitted.

Here’s one posted on the c2 wiki by Alex North:

public class fizzbuzz {
   public static void main(String[] args)
   {		
      for(int i = 0; i < 100; i++, System.out.println(i % 3 == 0 || i % 5 == 0 ? ((i % 3) == 0 ? "fizz" : "") + ((i % 5) == 0 ? "buzz" : "")  : i));
   }
}

Here’s another by Reginald Braithwaite, published with his article, “Don’t Overthink FizzBuzz”.

def compose *lambdas
  if lambdas.empty?
    lambda { nil }
  elsif lambdas.size == 1
    lambdas.first
  else
    lambda do |n|
      lambdas.first.call(compose(*lambdas[1..-1]).call(n))
    end
  end
end

def carbonation(modulus, printable_form)
  i = 0
  lambda do |n|
    (i = (i + 1) % modulus) == 0 && printable_form || n
  end
end

print(((1..100).map
   &compose(
     carbonation(15, 'FizzBuzz'), 
     carbonation(5, 'Buzz'), 
     carbonation(3, 'Fizz'))).join(' '))

Now contrast these solutions with comments many people have made regarding the low percentage of job applicants who possess any programming skills at all. Here’s an example of the kinds of comments that are typically posted, from StackOverflow. And here’s another example from Jeff Atwood, reacting to the flood of solutions that followed his post lamenting the poor skill level of most job applicants with a follow-up article, “FizzBuzz: The Programmer’s Stairway to Heaven”. An excerpt:

FizzBuzz was presented as the lowest level of comprehension required to illustrate adequacy. There’s no glory to be had in writing code that establishes a minimum level of competency. Even if you can write it in five different languages or in under 50 bytes of code.

The whole point of the original article was to think about why we have to ask people to write FizzBuzz. The mechanical part of writing and solving FizzBuzz, however cleverly, is irrelevant. Any programmer who cares enough to read programming blogs is already far beyond such a simple problem. FizzBuzz isn’t meant for us. It’s the ones we can’t reach — the programmers who don’t read anything — that we’re forced to give the FizzBuzz test to.

What does this tell us? We need a quick way to weed out people who claim to have basic programming skills, but don’t. When we ask them to sketch out a solution to FizzBuzz during a job interview, they often can’t even begin.

In contrast, any programmer who pays attention to their work finds FizzBuzz so trivial that they can’t resist getting carried away with it. Look at the two examples submitted by good programmers. It looks as if they had fun! But would you want your staff to have to live with code like that in production systems? Probably not.

Alex and Reginald used FizzBuzz as a plaything. That’s a good thing, but not in a job interview context, unless you’re interviewing for programmers who like to play (and maybe you are, depending on what your company does).

There are hundreds of examples of “clever” solutions to FizzBuzz on the internet. That c2 wiki page I mentioned is immensely long. There’s a page on the RosettaCode wiki that had solutions in 234 languages, as of the date I checked it, including some rather unusual ones like AutoHotkey and HicEst, which may not be of great interest to interviewers.

If job candidates might tend to overthink the problem and provide solutions that are too clever for everyday work, interviewers often miss the point of including programming exercises in the screening process. In “Using FizzBuzz to Find Developers Who Grok Coding”, Imran Ghory writes:

Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes.

Want to know something scary? — 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.

This shows a fundamental misunderstanding of the purpose of asking candidates to do real coding during the screening process. No one ships code that they sketched out in two minutes on a piece of paper (I hope). That isn’t the way production code is built in a commercial environment. What we’re interested in is the candidate’s step by step thought process as they build the code. You don’t see that by watching someone sketch out a quick and dirty solution on a piece of paper.

Imran will be able to weed out those who don’t know what they’re doing, but he has has little chance of finding programmers who grok coding. He can only obtain negative results in this way…both true negatives (the people who can’t code at all) and false negatives (the people who know too many ways to solve it, and can’t decide which one to write down before Imran dismisses them as “slow”).

It’s a good news, bad news thing. For lazy interviewers, the bad news is there’s no substitute for sitting down and pairing with the candidate. For interviewers who enjoy coding, the good news is there’s no substitute for sitting down and pairing with the candidate.