FizzBuzz is dead. Long live FizzBuzz!

UPDATE: It seems I was describing an out of date process, this is what we did a few months ago. Talking to folks doing interviews, we went back to live coding the Fizz Buzz exercise. Doing Fizz Buzz as a take-home exam actually told us nothing about the candidate – they would still bomb out during the exercise where we go over modifications. So the take-home exam was actually even more of a waste of time for everyone involved! One thing that isn’t different is that we’re upfront with the process – we set expectations. So you’re not surprised by the coding part.

It seems silly, but to this day the easiest way to judge a person’s ability to code is to have them, you know, actually code. In our company, our livelihood is completely dependent on our ability to transform problems into solutions, usually by coding. What better way to understand if a potential employee can also perform this critical task than asking them?

That the landscape of developers is extremely wide ranging is nothing new. As an employer, we need some sort of (somewhat) objective measure to understand if one candidate does indeed possess the skills needed to do the job. It’s remarkably accurate for us as an indicator – bubble candidates that didn’t do well in FizzBuzz that did well in other things, wound up not working out for us. Putting it plainly – every employee that works for us has aced FizzBuzz.

Many, many programmers out there hate FizzBuzz, even though it’s a simple problem:

Write a program that prints the numbers from 1 to 100. But for multiples of 3 print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiple of both 3 and 5, print “FizzBuzz”.

The kind of problem that someone with very basic skills of problem solving and programming should be able to solve it. Yet developers hate this test! Why is that?

Gotcha Interviewing

I see complaints about FizzBuzz generally fall into two categories:

  • I’m above FizzBuzz
  • I hate the pressure of live coding

In the first case – if you think you’re above FizzBuzz, then you’re putting yourself on a pedestal over all other employees. Pointing to your GitHub page doesn’t mean you can follow basic instructions – it just means you like to do OSS. Even pointing to OSS examples, while helpful, does not mean that you’re a good fit for day-to-day development. Our company doesn’t build OSS for its business, so we need a test that creates a level playing field.

The second point is absolutely valid. The last time I did FizzBuzz as a live coding exercise – it didn’t go well. I was so concerned about what questions I would ask, making a good impression and so on that it became difficult to relax and concentrate on a simple problem.

Live coding from scratch is a form of gotcha interviewing. Trying to stump the candidate, put them in a corner, put them under the bright lights to see if they respond is a harrowing experience. Moreover, it has zero basis in reality of how normal development actually happens.

We don’t do FizzBuzz like that – a live coding session doesn’t really tell us much about an employee. Our FizzBuzz strategy is a little bit different.

FizzBuzz for success

Instead of asking the candidate to perform live coding acrobatics, we ask them after an initial screening call to do FizzBuzz as a “take home” exam. Candidates can time to ask questions, probe for answers, and even cheat (if they want to).

Some time later (a day or two), we circle back and have a discussion about the code. At this point, it’s more of a code review than anything else. Typically, solutions are sent to us via GitHub, which makes it easy to collaborate and discuss.

We’ll ask all sorts of questions about their code – does it handle scenario X or scenario Y. It’s really just to understand the thought process of the candidate. And believe it or not – no two submissions have been the same!

We do have some semi-live-coding at this point. Things like, “suppose we want to print Foo and Bar instead of Fizz and Buzz”. “Suppose we want the consumer of this application to decide Foo/Bar versus Fizz/Buzz”

Suppose we want to pick different numbers – 5 and 7 instead of 3 and 5.

Suppose we want to pick arbitrary ranges (100-200).

Suppose we want to pick arbitrary sets of number/word combinations (3 = Foo, 5=Bar, 7=Bazz, 11=Banana)

We don’t necessarily assume that you’ll code this all live – in fact, whiteboarding works just as fine. We’re mainly interested in how you might deal with changing requirements, unexpected complexity, and the questions you ask to solve the problem at hand.

Ultimately, we try to match our interviewing process to how we actually work with clients and develop projects internally. Short of doing “trial runs” on real projects, FizzBuzz provides as accurate of a window into skills we need as we’ve been able to find.

All about respect

We at Headspring are big on respect. We respect your needs, your wants, but especially your time. We want interviewing to reflect as much as possible how we work, so that candidates understand exactly what they’d be joining.

If we throw some situation at you that we’ve never faced with clients, like a client staring at you while you code, then what are we really measuring?

However, if candidates don’t take the exercise seriously, if they think they’re too good or half-ass it, then it’s them that’s not giving respect. It takes time to interview, on both sides, so the least we try to do in assessing skills is make sure that neither of us are wasting each other’s time.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Process. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • WickyNilliams

    Cue people writing Fizzbuzz solutions in comments in 3, 2…

    • http://twitter.com/ntcoding Nick

      fizz

    • http://realfiction.net Frank Quednau

      function Coalesce($a, $b) { if ($a -ne $null) { $a } else { $b } }
      1..100 | % {
      $1 = if (!($_ % 3)) { “Fizz” }
      $2 = if (!($_ % 5)) { “Buzz” }
      Coalesce ($1 + $2) $_
      }

      In Powershell :P

  • http://donnierayjones.com Donnie Ray Jones

    I just completed an interview in San Francisco, and I wish the company would have used this approach. I think it gives the interviewers better information, so they don’t overlook a valuable candidate because he/she wasn’t able to come up with a solution on the spot, on a whiteboard. It also gives interviewers a chance to ask harder questions; questions that have a “real world” applicability.

  • sodablue

    I was once

  • Trystan Spangler

    I like the “Suppose we want….” idea of changing requirements. Not only is it important to see how they solve the problem, but most time is spent changing code not writing it from scratch. People also react differently when they need to change their original design. Best to find that out during the interview process. I wish more places interviewed like this.

  • Frederic

    I don’t really get it. Sounds like a quite an easy program to write … a few minutes necessary.
    OR
    is there something I’m missing here?

    • jbogard

      You’re not missing anything – except it’s _insane_ how many folks can’t do it.

  • Alper

    I like the idea of a take home exam. It gives the applicant chance to refactor the code written under pressure.

  • cbp

    My attitude with some of these questions is that they are -SO- easy, that for a good programmer they should literally be able to do it with their eyes closed. If you have to actually sit and think hard in order to solve a simple FizzBuzz problem, you’re probably not going to be the quickest worker on the job.

    • ohgodkillmenow

      The two guys who pumped out code by the barrel and set the company back five years and untold fortunes were, indeed, the quickest workers. But I don’t want to bore you with such trivialities–how was the vacation, Mr. Lumbergh?

  • Ivan

    There is one problem with this approach.

    Many companies use people that are seeking jobs to solve their internal code problems. For example, a company has a problem, or a contract they need to solve and then they
    suppossedly hire employees which have to solve the problem they’re facing. When they solve the problem, company thanks them but doesn’t hire them.

    How to face this problem?
    Personally, I am more fond of talking to someone to see how one thinks on solving the problem. It’s not so important to know all the code gimmicks, but to know what possiblilities are out there.
    But, yet again, I was never in position of hiring someone :) .

    • jbogard

      I had this happen in an interview once – the questions were so specific to a problem, I thought “geez am I consulting for free here?”

      If it’s general, then yeah that comes out. But not usually a coding exercise.

    • ScottB

      You say “many,” but I don’t believe it’s true. The average candidate does poorly answering technical questions. I can’t picture a company with programmers so inept that it’s easier to try to fake-hiring-process a solution to a problem than to solve it themselves. If they’re that bad, they won’t know a working solution from a non-working one, or a bad solution from a good one.
      It’s more likely that if you see something that specific that it’s a problem the interviewer has actually faced, and he didn’t want to ask someone to write a sort again. Asking the same questions that everyone else ask means that you’re seeing how well someone prepared for interviewing specifically instead of how good they are at programming generally.

  • michaelminutillo

    Has anyone tried to cheat by submitting Enterprise FizzBuzz? It’s re-use!

  • Pingback: Подборка статей по поиску и отбору программистов | Блог кадрового агентства ITHH

  • http://www.facebook.com/hoblitzell ホブリットゼル ビール

    I’m by no means a good programmer, but someone unable to write a basic FizzBuzz pseudo-code cannot credibly blame performance anxiety. It basically tests your knowledge of three primary programming concepts:

    a) What a function definition looks like
    b) Your understanding of basic conditional statements such as if – else if – else
    c) Basic knowledge of mathematics

    If you want to be some PHP hacker, then the third party ain’t so necessary. To program for Google, M$ or the big boys you need to know your stuff. I’d humbly submit that someone incapable of basic integer math is absolutely unqualified to be a software developer.

  • Timur21

    I was filling up an application form the other day and they asked me to submit my own fizzbuzz code… I thought this was too easy and wanted to submit something original, perhaps in the form of a game. This is what I submitted: http://fizzbuzzgame.appspot.com/

  • Pingback: Why is it so hard to find good help these days? | Salted Mac Hash

  • Pingback: Testing Software Engineers? Engineer these Tests | Entelo Blog : HR technology, recruiting tips and Entelo product updates

  • Kyle

    for ($i=1;$i<101;$i++) {
    $test15 = $i/15;
    $test5 = $i/5;
    $test3 = $i/3;
    if (round($test15, 0) == $test15) {
    echo 'FizzBuzz ‘;
    } else if (round($test5, 0) == $test5) {
    echo ‘Buzz ‘;
    } else if (round($test3, 0) == $test3) {
    echo ‘Fizz ‘;
    } else {echo $i . ”;}
    }

    • Jack

      Use the modulus operator, no need for “round”… $i % 15