
5 Alternatives to the Fizzbuzz Test for Hiring Programmers - standout
http://david.elbe.me/developers/hiring/2014/09/17/fizzbuzz-alternatives.html
======
lohengramm
I like questions that bootstrap productive discussions. Showing code might
work, but asking to write code is a bad idea. Even simple code can become a
nightmare to write if the person is uncomfortable due to the natural pressure
that arises in a technical interview. The best programmers transform
themselves while alone, in front of their computers, and there is no way to
induce this kind of behavior in an interview. There is no way to get
completely "in the zone" there. The best you can do is to read code previously
written and talk - a lot. Talk about algorithms and data structures if that's
the case, but don't ask the subject to write it down. He is not prepared to.

To filter out extremely unskilled candidates, simple questions might suffice:
"how many bits does a byte have?", "what's the difference between an array and
a linked list?", "what is the difference between GET and POST?", "what is the
difference between a function and a macro?", and also more informal questions:
"what technologies are you watching lately?", " what fields of computer
science you would like to dive more?". These make it very easy to spot people
who have no idea of what they are doing.

One thing that I have never seen but I suspect it should work is to ask the
candidate to write the code days before the interview, and then bring it to
discussion in the moment of the interview. In this method, you eliminate the
uncomfortable process of writing code in an unusual circumstance but keeps the
feature of discussion.

~~~
spdionis
Agreed that coding is not a very good idea on an interview, especially during
a phone-screen. But it's good to pose a problem and make the candidate roughly
describe the approach he would take. Combined with a small homework task that
sounds good enough.

------
jammycakes
It's important to remember the purpose of questions such as these. The purpose
is to short-circuit the interview process when you're presented with someone
so hopelessly unqualified that they're wasting your time and everybody else's.
That's why they tend to be laughably simple.

More detailed questions -- how they react in real-world situations, how they
manage under pressure, and so on -- can come later, once they've cleared that
first hurdle.

An article well worth reading here is "The Five Essential Phone Screen
Questions" by Steve Yegge.[1] He gives some good advice on what to look for in
the candidate's answer as well as how to construct FizzBuzz-style questions of
your own.

[1] [https://sites.google.com/site/steveyegge2/five-essential-
pho...](https://sites.google.com/site/steveyegge2/five-essential-phone-screen-
questions)

~~~
raverbashing
I understand the reasoning.

You want to test my programming ability that's fine. Just don't make me be
present on site (if this involves more than going somewhere in the same city
or in the vicinity)

Or do a phone screen. You can filter people that can't code FizzBuzz with
that, with a high confidence level. Just ask the right questions.

Because you can believe that to get called for a senior job interview and
being asked to do FizzBuzz P! me off! It's extremely disrespectful.

~~~
sokoloff
I don't see the issue in being asked to write FizzBuzz. If you're remotely
qualified, this is a 3-5 minute task before I can see, "OK, you pass the 'can
fog a mirror' level of test; sorry about that, but you wouldn't believe the
trainwrecks we get sometimes..."

I had a senior level candidate on-site about 15 years ago who seemed ready to
physically fight me when I asked him to write some (approximately) FizzBuzz
level code on the whiteboard. I'd gotten a whiff of, "Johnny can't code" from
some of his answers and figured I needed to see how deep the rot went.

Come to find out, he couldn't do it and had snowed the phone screen and first
two interviewers and was angry that the jig was up. Interviewing for a senior-
level position is, sadly, no guard against hopelessly unqualified applicants.
With the advent of glassdoor and pre-briefed interview candidates, phone
screen questions are fairly game-able as well.

~~~
raverbashing
I find it funny that I never needed to do such test to gauge people's ability.
Also, when I saw people using, I never saw it fail.

Example questions:

(Python) When should you use a list instead of a tuple? What's the difference
between range and xrange? What does ' %s' in a string means? Then elaborate
from there.

I don't think that anyone who can't pass FizzBuzz knows the answers to those
questions.

------
Narretz
"Write a function that takes three measurements in centimeters as input and
returns a the volume over a litre"

I have a hard time understanding what this us supposed to mean. Is there a
typo somewhere? "returns a the volume over a litre" sounds like gibberish, but
then I am not a native speaker.

~~~
JDDunn9
It means the volume in excess of 1 litre, since it talks about returning a
negative number if it is less than that.

~~~
kbart
This. But as for non-native English speaker, that " _over_ a litre" part is
easy to miss. Special care should be taken when interviewing candidates not in
their mother tongue and such single word catch should be emphasized more.

~~~
usea
I am a native English speaker, and I've never seen that. I was very confused,
and I would have had to ask many questions to figure out what "the volume over
a litre" meant.

------
chrisbennet
#5 (write a bad version of fizz buzz) is a great question. Just asking such a
unique question in an interview would raise my estimation of the company.

~~~
aw3c2
I think that generally "how to write bad code" is a great interview topic as
you probably get a positive fun response from those are know and get a nice
insight what things they might be caring about.

~~~
dalke
Just how useful is it as a test? Suppose the "good" code is:

    
    
      for (1..100) {
        my $fizz = ($_ % 3 == 0) ? "Fizz" : "";
        my $buzz = ($_ % 5 == 0) ? "Buzz" : "";
        ($fizz ne "" || $buzz ne "") ? print "$fizz$buzz\n"
                : print   "$_\n";
      }
    

and the "bad" code is the one-liner:

    
    
      print ( ((($_ % 3) ? "" : "Fizz") . (($_ % 5) ? "" : "Buzz"))
         || $_, "\n") for (1..100);
    
    

or is the following:

    
    
      #!/usr/bin/perl
      @v=(0, "Fizz", "Buzz", "FizzBuzz");
      for($v[0]=1;$v[0]<=100;$v[0]++){
    	$k = ($v[0]%3)?0:1;
    	$k += ($v[0]%5)?0:2;
    	print($v[$k]."\n");
      }
    

(All three from
[http://c2.com/cgi/wiki?FizzBuzzTest](http://c2.com/cgi/wiki?FizzBuzzTest) .)

What does that reveal about the interviewee that makes this a great interview
topic? To my eye, I prefer #1, #3, and #2, but it starts to get into personal
preference rather than anything seriously indicative.

Do you want to dock someone for not being able to give a seriously bad
implementation?

~~~
collyw
The worse the code is, the greater the understanding of the language in these
cases.

~~~
dalke
So how would you answer my question? Would you really dock someone who could
give all three of those implementations, but struggled to give a truly
horrible implementation? How bad does it need to be truly horrible?

I ask because I struggled coming up with a horrible implementation of
FizzBuzz. My best attempt was to have Python create a sqlite table then use
SQL to do the test. Such implementations occur all too frequently at
[http://thedailywtf.com/](http://thedailywtf.com/) .

But surely this would not be an example of great understanding of either
Python or SQL. Therefore, I don't see how you can draw your conclusion.

Could you explain more fully?

~~~
collyw
I got the impression the idea wasn't about writing the poorest code, but
getting a chance to discuss what would make something better worse. I
personally put readability and maintainability close to the top of my list.

~~~
dalke
The question was "Write the worst – but working – implementation of Fizz Buzz
that you can think of." It is designed to 'bring up some good laughs, and
takes some of the pressure off of the applicant' with the assumption that the
candidate will respond "Write bad code? I can do that!".

My question is, what if the interviewee is unable to produce bad code? Or even
better, if the interviewee's worst code is better than the interviewer's best
code. Does that inability to produce bad code on demand count as a negative?

~~~
collyw
Well that's up to the interviewer. I would say it doesn't count as negative,
but that's me. I am assuming the conversation around it is what is important.

I recently got asked to do fizzbuzz in an interview. Then "fizzbuzz without
the modulo operator". It's such an obvious way to approach the problem, that
coming up with an alternative was surprisingly tricky. Caused a bit of a
mental block for me.

~~~
dalke
If it's up to the interviewer then it isn't really a test of one's skills, is
it? ("The worse the code is, the greater the understanding of the language in
these cases") Instead, the interviewee needs to intuit what it is that the
interviewer is looking for.

Doesn't that restriction reduce to "how do you implement modulo?"

    
    
      def modulo(a, b):
        return a - a // b * b
    
      def modulo(a, b):
        while a > b:
          a -= b
        return a
    

or pulling a hack from
[http://graphics.stanford.edu/~seander/bithacks.html#ModulusD...](http://graphics.stanford.edu/~seander/bithacks.html#ModulusDivision)
, which is equivalent to casting-out-9s but in base 16:

    
    
      def mod15(a, b):
        while a > 15:
          b = 0
          while a:
            b += a & 15
            a >>= 4
          a = b
        if a == 15:
          return 0
        return a
    

If it doesn't reduce to that, then it's another example of trying to guess
what the interviewer is really asking, rather than trying to demonstrate one's
expertise.

~~~
bugstomper
There are much simpler ways without using modulo than defining your own modulo
and using it. For example (in Java)

    
    
       class FizzBuzz {
          public static void main(String[] argc) {
            int next5 = 5;
            int next3 = 3;
    
            for (int i=1; i<=100 ; i++ ) {
                String output = "";
                if (i == next3) {
                    output = "Fizz";
                    next3 += 3;
                }
                if (i == next5) {
                    output += "Buzz";
                    next5 += 5;
                }
                if (output.isEmpty()) {
                    output = Integer.toString(i);
                }
                System.out.println(output);
            }
            return;
          }
       }

~~~
dalke
Yes, that works. But I don't understand the goal of these variant question.

The original goal was to weed out obviously incompetent programmers. I accept
that for some positions that's reasonable. But if I were given that question,
and end up implementing my own modulo function to replace the missing
operator, is that a mark against the interviewee, compared to someone with
otherwise identical qualifications who implements your solution? Or someone
who does this sieve solution:

    
    
      def fizzbuzz(n):
        n += 1
        values = ["%d"]*(n+1)
        for i in range(0, n, 3): values[i] = "%d Fizz"
        for i in range(0, n, 5): values[i] = "%d Buzz"
        for i in range(0, n, 15): values[i] = "%d FizzBuzz"
        for i in range(1, n): print values[i]%i
    

All of these have different performance/memory/maintenance characteristics,
but the full constraints are unspecified. At some point it feels like the
interviewer just wants to see the monkey dance, by throwing in non-realistic
constraints.

------
frywhy
Question for the HN community: I've been learning Python on and off for about
6 months and I can answer all of these questions with ease. I'm subscribed to
Interview Cake's emails and generally figure out their programming tasks.
Question is, am I good enough to make the leap to doing 'proper' programming?
The gulf between hobbyist and professional coded seems huge. How did you all
cross it?

~~~
Cthulhu_
Thing is though, these questions / exercises are just that - exercises. If you
can write real code / real applications (could you build a contact form,
forum, shopping cart, order form etc in Python?), then you're ready.

~~~
collyw
I have been using Python for 4 years, and honestly I don't think I know the
language so well (not compared to the knowledge I had of Perl before I started
using Python).

I use Django, and I have an in depth knowledge of the framework. It has done
pretty much all the hard work, so its a case of understanding its high level
concepts and plugging them, together, rather than being able to implement
every one of its features myself.

Whats going to be more use in the real world? Knowing how to use Django's
reverse function, or being able to write my own in less than an hour?

------
jakub_g
I'd add to this list some simple binary logic questions. I've noticed that
some programmers struggle with De Morgan's laws. Also many prefer to write
hardcore one-line boolean expressions, often with multiple negations, instead
of splitting it into smaller subexpressions assigned to properly named
variables.

An interesting question would be hence to show a candidate some complex, buggy
logical one-liner, with the comment above the code stating something different
than the code actually does, and ask him to fix it.

A good candidate should extract booleans out of it and then see the flaw in
reasoning, fix a bug, and perhaps write code so self-explanatory, so that the
comments can be removed.

~~~
onion2k
What you should be looking for in a candidate is the ability to do what a good
developer would do in a real world situation. In your test a good candidate
would just bin the opaque, broken code and write it from scratch in a better,
more readable way. If something is quicker to rewrite something than it is to
work out what the previous developer did wrong the right answer is always
going to be a rewrite, and that's _always_ going to be the case for a one-
liner.

If you want to test someone's ability to fix broken code then you need to give
them a test that reflects that, not a test where you tell them not to work
properly.

~~~
Sir_Substance
Also, in the real world a candidate would probably google De Morgans laws.

Coding is not bomb disposal, if anything it's bomb construction. I would argue
it's desirable for a developer to look these complex-and-not-frequently-used
concepts up when they need them, to ensure they are not misremembering. It
would be better to test a candidates ability go search for good reference
material than whether they can remember your specific question off the top of
their head. Wouldn't you want your nitration chemist to be regularly looking
at his textbook?

~~~
copsarebastards
De Morgan's laws are complex-and-not-frequently-used? What are you even
programming?

I don't want to hire programmers who have to constantly be looking up how to
program--that's an enormous waste of time. It makes sense to be looking up
APIs, because interfaces change and have caveats. But DeMorgan's laws, divide
and conquer algorithms, basic data structures, should all be in your brain.
These are the building blocks of software and if you don't have them you can't
build software.

> Also, in the real world a candidate would probably google De Morgans laws.

So I hand you a function to optimize:

    
    
        def is_taxed(transaction):
            return (not transaction.buyer.is_nonprofit()) and (not transaction.location.is_duty_free())
    

What about this problem would indicate to the candidate that they should
Google "De Morgan's Laws" if they didn't already know it?

~~~
onion2k
Most developers would be able to work out that the answer to the test is
"return not (X or Y)" (unless Python has a nor operator.. I don't know because
I rarely use it) without even realising they're using De Morgan's laws, but...

1\. If the app is anything bigger than a trivial case there will be bigger
things to optimize. Individual code optimizations give you so little in return
they're rarely worthwhile.

2\. Unless you're doing it _millions_ of times a second you won't actually see
the time saving. If you are then you're probably better off generating
is_taxed when the transaction object is generated (eg generating and caching
the result).

3\. If you're still at the point where this change will actually make a
difference you probably should be using something that isn't Python.

I wonder if something like Nuitka would be able to optimize it automagically.

~~~
copsarebastards
> Most developers would be able to work out that the answer to the test is
> "return not (X or Y)" (unless Python has a nor operator.. I don't know
> because I rarely use it) without even realising they're using De Morgan's
> laws, but...

> 1\. If the app is anything bigger than a trivial case there will be bigger
> things to optimize. Individual code optimizations give you so little in
> return they're rarely worthwhile.

> 2\. Unless you're doing it millions of times a second you won't actually see
> the time saving. If you are then you're probably better off generating
> is_taxed when the transaction object is generated (eg generating and caching
> the result).

> 3\. If you're still at the point where this change will actually make a
> difference you probably should be using something that isn't Python.

Yes, and that would be a _great_ answer to my question.

------
dalke
For the tax one, what rounding rules apply? How many significant digits are in
the dollar amount and tax rate? Do I have access to IEEE 854 decimal or should
I used scaled integers? And to how many digits?

This is important! Consider the following Python code, which shows how the
order of operations can change the result by a penny:

    
    
      >>> d = 6405  # amount in dollars
      >>> r = 0.018   # tax rate of 1.8%
      >>> int(d * r * 100)
      11529
      >>> int(r * 100 * d)
      11528
    

This occurs because:

    
    
      >>> d * r * 100
      11529.0
      >>> r * 100 * d
      11528.999999999998
    

whereas if I use 854 math:

    
    
      >>> from decimal import Decimal as D
      >>> d = D("6405")
      >>> r = D("0.018")
      >>> int(d * r * 100)
      11529
      >>> int(r * 100 * d)
      11529
    

The person who proposed the question believed that the key point was for the
interviewee to ask why the result was to be returned in an array. As an
inverted fizz-buzz test, this question really reveals that the questioner has
little experience with the details of doing accurate math on a computer.

~~~
raverbashing
You're absolutely right in your worries, but I think they usually don't
consider those factors in the interview (bonus points if you mention it
usually)

I usually prefer to work using integer cents, Decimal has some quirks in
Python (like a unique precision for all numbers)

~~~
dalke
Well, that is why I called it an 'inverted fizz-buzz test'. The test itself
reveals limitations in the organization doing the interviewing.

While you may be able to work in integer cents, there is still the question of
how you handle rounding. Does Richard Pryor get your fractional cent, a la the
salami slicing in Superman 3?

Banks typically work in five or six decimal places, and not the 2 decimals you
can use. As a specific example, the final conversion rates from the national
currencies to the Euro are given to 6 significant digits, eg, 1.95583 Deutsch
marks to the Euro. Zimbabwe had problems when their hyperinflation caused
overflows in systems that assumed 64 bit integers was enough for any currency.

I don't understand what you mean by "quirks in Python". Your concern seems to
be with the General Decimal Arithmetic Specification, and not its
implementation in Python.

~~~
raverbashing
Sure, rounding is important as well.

> I don't understand what you mean by "quirks in Python"

Setting a precision for decimal numbers "globally" in the module.
[https://docs.python.org/2/library/decimal.html](https://docs.python.org/2/library/decimal.html)

But of course, working with cents might get complicated if you're doing a lot
of calculations, people should use Decimal

Then there was Django's Decimal field which wouldn't even do comparisons
correctly and was filled with bugs (in 1.2 at least)

~~~
dalke
Minor correction; the decimal context is thread-local, and not set '"globally"
in the module'.

It's similar in philosophy to C99's support for IEEE 754's rounding modes and
exception modes. Compare to
[http://en.cppreference.com/w/c/numeric/fenv](http://en.cppreference.com/w/c/numeric/fenv)
:

> The floating-point environment is the set of floating-point status flags and
> control modes supported by the implementation. It is thread-local, each
> thread inherits the initial state of its floating-point environment from the
> parent thread.

Since standard floats in C have similar behavior, it's hard for me to agree
that it's really a "quirk".

------
JDDunn9
I don't think these type of silly questions tell you anything meaningful as
this is not how you code in the real world. Most people get nervous during
interviews or don't perform well under timed tests. These type of interview
questions really only test if you've heard these questions before. You're
basically testing their interview skills.

There's no substitute for reading code they've written in production.

~~~
daurnimator
The majority of candidates I've interviewed do not have code they can show me.
Usually because they don't have permission to share code from their previous
job.

The idea of these questions is to filter out those that cannot program _at
all_ ; any competent programmer should be able to solve these; or at least
talk about them for a while.

The point is to avoid making a bad hire; not to find an excellent person.

~~~
JDDunn9
Sure, any competent programmer could solve these under normal circumstances,
but I've had a few interviews where I was kicking myself right afterwords for
giving such stupid answers under pressure.

------
ddellacosta
While I still believe that a short (paid, ideally) project is a more
meaningful test of a developer's skills than whiteboard coding or the like, I
thought this made a reasonable case for a quick set of heuristics to filter
out non-starters.

I especially like the "bug fix" item (#3), as it contains a variety of
different possible issues and seems like it would expose how the candidate
thinks and approaches reading code (which they will be doing a lot of, if it's
like every programming job I've ever had...), in a meaningful way. Combined
with a nice but simple problem like the anagram (#1) question it seems like
you could filter the wheat from the chaff rather quickly.

Semi-off-topic:

Unless I'm mistaken there's a typo in the little "about this author" blurb at
the bottom: "David Elbe is web entreprenur..."

It also seems like the problem statement for #4 is not quite correct, I'm
having trouble parsing it (as some others in this thread also seem to be):

"Write a function that takes three measurements in centimeters as input and
returns a the volume over a litre"

Everything past "and returns..." needs some editing, methinks.

~~~
Fuxy
"the remaining volume past 1 liter" would sound more accurate maybe?

I still find it surprising people with no programming knowledge actually apply
to these kinds of jobs.

This is like a construction worker applying for a doctors position.

Do they really think programming is just that easy that you can pick
everything up at work.

We don't spend years learning this just for fun.

------
Cthulhu_
There's two questions here - anagram and something with centimeters and liters
those with the imperial system may not be familiar with. I wouldn't actually
bother explaining those - if the applicant can't figure out what an anagram is
or how to calculate volume in liters from centimeters (which is simpler in the
metric system), they're inept and completely unsuitable for software
development.

I'd rather hire someone that can't write a word of code - yet - but can figure
it out on his own using some googling than someone that passes fizzbuzz but
gives me a blank stare when I mention the word "anagram". "I don't know what
an anagram is /yet/" would be the correct answer.

------
webtards
A good set of questions - they don't rely on too much esoteric knowledge, and
look to see how the programmer would apply any experience gained to date in
solving them.

One question we often use early in interviews is "could you show me something
neat you have learnt whilst programming?" \- we want to see if they have
actually programmed before, if they took the time to dig in a bit more than
hello world or the fabulous Paula bean (dailywtf classic) and importantly, why
they thought it was neat.

------
meesterdude
I enjoyed this and felt it was a more reasonable set of tests than what
fizzbuzz usually equates to.

I do not test well. ever. Especially if there is a timer going. Thankfully,
I've been able to get work from just taking about the stack or problems, and
that's worked so far.

------
fallat
That anagram question...I would have never figured out to use sorting. I would
have done a simple loop that checks to see if the letter exists in the other
word. Loop until false is returned...The length check seems 100% necessary to
solve this problem.

~~~
sesm
Solution they've described doesn't account for duplicate letters in a word.
The right solution would be to build frequency maps of letters in each word
and compare the maps.

(defn anagram? [a b] (= (frequencies a) (frequencies b)))

~~~
fallat
No, it does. Once both strings are sorted alphabetically, you just compare
them.

"tallaf" -> sort -> "aafllt"

"laftal" -> sort -> "aafllt"

Does "aafllt" == "aafllt" ? yes? Then we're good!

What you're saying:

"tallaffffff" -> sort -> "aaffffffllt"

"latfal" -> sort -> "aafllt"

Does "aaffffffllt" == "aafllt" ? Of course not.

The length check is just early exit. Actually for my solution the length is
necessary.

Your solution is good too - I actually googled after to see other possible
solutions and counting characters was the "second" solution.

------
gumby
These are great kinds of questions because they can spark discussion, which is
the point. Whether someone can solve the problem or not doesn't teach you
much; what they say while solving it is illuminating.

------
lordnacho
These little questions are only going to weed out people who have never
programmed.

I suppose some such people will try their luck from time to time, but how
different is this to picking soccer players based on whether they can juggle
the ball? Any pro soccer player can juggle the ball, but that's not what they
do at work at all. And not everyone over the threshold is equally good at the
actual job.

You can try to gather data to figure out a smart way to hire programmers, but
then you have the problem that you aren't going to hire the ones you think are
bad. So how do you know how they would have done?

It's a tough nut to crack.

~~~
nothrabannosir
_Let me emphase that; 75 out of 100 applicants to a programming job can not
program. At all._

...

 _Remember, the goal is not to make people fail on tests - only to quickly
discard the people who can not write software at an early stage to save time
and effort for both of us._

...

 _I again want to emphasize that this is only to sort out the real developers
from the crowd. I really don 't want to waste anyone's time and energy on
doing multiple interviews when we both can find out with a simple test that
they're not going to make it. No pointing fingers, no harsh comments - just a
simple test to find who we are looking for._

I was surprised at the need for all those disclaimers, but I guess it was
necessary, after all.

If you want to hire a professional soccer player, and a candidate can't juggle
a ball. Would you hire him?

Who cares if he does it at work? If he fails a test that, supposedly, "any pro
soccer player" should pass, then he's not suited, is he?

And the other commenter is right---fizzbuzz isn't juggling a ball, it's
knowing how to walk upright.

~~~
lordnacho
I am surprised, actually. And yet not.

I've interviewed hundreds of people in the past who all on paper had a degree
in something numerical. And somehow they can't answer the question "what's the
expectation of a dice roll?". That's supposed to be a warmup question.

It simply stretches credulity that someone, anyone, doesn't know this. Same
with FizzBuzz. Just about any kid in a high school math class should be able
to do either? The fact that people can't do it suggests a number of
hypotheses.

\- They think it's a harder question than it really is. One highly qualified
lady made a "WTF" face when it dawned on her I was asking a grade 10 question.
She didn't want the job later on.

\- They think they've missed something, and are scouring their minds against
hope that they'll figure out the missing piece.

\- I've intimidated them like a bully. People aren't used to interviews where
they might fail. Perhaps there's some psychological trigger I've inadvertently
hit, and they've turned into rabbits in the headlights.

\- They've lied on their CV but have shown up to the interview anyway. Maybe.
How long can you blag this kind of thing though?

Maybe my priors (or evidence credulity) are just different from yours.

