Over a million developers have joined DZone.

The Fizz, the Buzz, and the Ugly

There's no glory to be had in writing code that only establishes a minimum level of competency. Let’s consider the usefulness of FizzBuzz as an interviewing tool.

· Agile Zone

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

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 coding 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
    lambda do |n|

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

     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—to whom we’re forced to give the FizzBuzz test.

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 computer science 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 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.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

fizzbuzz ,interview ,interview questions ,agile

Published at DZone with permission of Dave Nicolette. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}