Fizz Buzz Sniff

A while back I came across an interesting blog post on what's become known as the Fizzbuzz test. The interesting idea is that despite claiming to be trained and qualified, many job applicants for programming jobs are bad. What makes this interesting is that it doesn't sugguest that they're bad but rather that they're BAD. Not just that they can't write production standard, bug free code on a commercial scale code (projects I worked on as a professional programmer were in the order of a million lines of code), but that they can't write the most trivial of code.

In the fizz buzz test, you're asked to write code (in the language of your choice) to count from 1 to 100, replacing any number divisible by 3 with fizz, divisible by 5 with buzz, and if its divisible by both use fizzbuzz. We only say the number if none of these apply. It's actually in interesting (trivial) problem, as it doesn't fit easily into an if/then/else, and actually requires a little thought, but any programmer can code it easily.

The hypothosis is that asking job applicants to write a trivial piece of code weeds out the ones who are wasting your time just as well as a more extended coding test. Part of the idea is that it will trivial to anyone who has a clue, so you don't waste their time either - it takes them 2 minutes and you move on to something else.

It's important to remember that the point of the test is to weed out terrible programmers. There are several ways to factor the answer, and some may be more efficient than others. Other's may be "clever", or shorter. But it's actually important not to judge the quality of correct answers - real world problems have context, which might dictate a fast solution, a low memory solution, or a maintainable solution. Dumb tests have no context, so making the correct design choices is impossible, so don't judge them.

I thought it might be interesting to see how I'd code it in Sniff. You should probably code it yourself first before reading mine, but here it is:

make counter number

make message string

when start

.repeat 100 using counter

.. set message to ""

..

..if counter mod 3 = 0

...set message to join message "fizz"

..

..if counter mod 5 = 0

...set message to join message "buzz"

..

..if message =""

...set message to [counter]

..

..say message

There are couple of places where I've coded it in ways that make sense to me. I can see several variations that some people might prefer (if I were interviewing me I'd ask about a couple of choices because I think the answers would be interesting, but then I think most things I have to say are interesting), but I think this is clean and maintainable, which I consider the "default" priorities in any code.

Of course you might think that as the test becomes widely known it looses its value - after all, now you've seen it you won't be tripped up. However the sort of person the test is designed to trip up probably doesn't read programming blogs: imagine interviewing someone, you propose the test, and they immediately tell you about how they've read all about it, and proceed to discuss its viability - they already have a tick in the right column. Even if someone did see it and learn a solution, it would be totally clear they were receiving a previous solution, rather than coding it from scratch.

It would be interesting to see how students (and staff!) at various stages of progression handle this. Maybe try it on your programming class (I know I will at some point!), or maybe at your next CDP session.