
The Problem with the FizzBuzz Problem - jasonmp85
http://www.gayle.com/blog/2015/5/31/the-problem-with-the-fizzbuzz-problem
======
jasode
_> But the smart developer might just identify (intelligently) the potential
for a "cool, elegant" solution and never find it. ... They think you want an
elegant solution because the simple one is too obvious and it feels like there
is an elegant solution. _

I think this is the gist of the essay and it's very easily addressed by
stating at the beginning, _" just code something that works, don't try to come
up with the most elegant thing known to mankind."_

I don't see this as an issue in real life if some commmon-sense parameters are
spelled out upfront. It's a 5-minute sanity check to get past false resumes.
That's it.

I guess it's theoretically possible for an algorithms-obsessed programmer to
sit there paralyzed for 2 hours on fizzbuzz. You the interviewer then ask him,
" _is there something about modulus 3 and 5 that 's tripping you up?_"

He says _" Oh, not at all. I was just debating whether I should start with
first principles of lambda calculus and have the program replicate itself in
millions of successive genetic iterations until the final program writes
itself. But then I got on a thought tangent and was thinking if I could just
manually write list of the first 100 correct answers and then feed that to a
machine learning algorithm that I write. It would classify the intervals and
work backward via artificial intelligence to generate the right program. Btw,
how much time do I get to work on this?"_

I suppose scenarios like that _could_ happen, but I don't worry about it.

~~~
arenaninja
I agree. For any interview problem, my approach is to just write something
that works. If you can't, talking it out loud helps whoever's interviewing
know whether you're genuinely stuck or just fumbling with the keyboard

~~~
kstrauser
> If you can't, talking it out loud helps whoever's interviewing know whether
> you're genuinely stuck or just fumbling with the keyboard

Absolutely! I'm also explicit about why I'm solving problems the way I am,
like "this is going to be my brute force solution, and probably won't be
pretty or efficient". This is effective against the occasional interview who
does like to trip you up with followups like "wow, I was hoping for a more
sophisticated answer" (yeah, you know who you are). I can respond with "as I
said, this is a rough draft."

------
lordnacho
Here's a similarly simple question that I used on hundreds of people who were
trying to get a job at a hedge fund:

You have a dice (1-6). Some guy offers to pay you whatever you roll. What are
you willing to pay to play this game?

Somehow, most of the applicants, who all had quantitative degrees, never made
it very far. It's actually a warmup (what would you pay for the same, but with
a chance to re-roll once?).

I just don't believe that people can't figure out the expectation of a dice
roll. It makes no sense to me. Over the years I've concluded it must be
because the way it's asked. People think there's something deeper in it than
the most straightforward explanation. Or maybe they think they missed some
critical detail and are afraid to ask.

Now there are actually some clarifications that would make it more
interesting, but I never got anyone to ask those (Is it an eternal game? Do I
have a limited pot?).

What was really dispiriting was when someone understood it, and were shocked
we'd asked it.

~~~
JoeAltmaier
I'm willing to pay $0!

No, really, statistics are unintuitive and most people, smart people, don't
have a feel for them. Just look at the HN thrash whenever the Monty Hall
problem comes up.

Btw its a 'die'. 'Dice' is plural.

~~~
apalmer
Yeah but he specifically said these are folks with quantitative degrees... I
would expect want to be quants applying at a hedge fund to have an
understanding of statistics.

~~~
meragrin
Yes, but there is a difference between expected payout and a person's
willingness to play a game of chance. The expected payout of a lottery ticket
is the same for every ticket before the drawing, but everyone has a different
willingness to purchase tickets. The person is being asked about their
willingness to take on risk and not their objective analysis of the payout.

------
VLM
The TLDR summary of the article is its really easy to get stuck down a
mineshaft of "I'm sure they're looking for a more elegant way to do this".
(edited to add, because scalability... demand fizzbuzz run 1...1e99 or under
some weird time constraints and all bets are off, but no, its 1...100)

The comment on the article of a similar example of print an ASCII art diamond
claiming cleanly using symmetry is unusable sticks in my brain a bit. There's
gotta be a way! I mean, there has to be, right? But my first bright ideas all
involve limitations that would be very non-clean and limitation inducing,
although they would be cool applications of symmetry.

~~~
detrino
I think I found the symmetry:
[http://ideone.com/KnaAMm](http://ideone.com/KnaAMm)

Edit: Now with more symmetry:
[http://ideone.com/edNgre](http://ideone.com/edNgre)

~~~
detrino
Less repetition: [http://ideone.com/yPQzy6](http://ideone.com/yPQzy6)

------
ilitirit
I did an experiment while interviewing interns once. For half the group, I
posed this problem:

> Given a log file, with each line prefixed with either WARN, INFO, ERROR or
> DEBUG, explain briefly how you would determine the number of errors logged
> assuming that each line corresponds to a single event and vice versa.

For the other half, I posed the same question, but I said the log file was
50MB big. Most people didn't know how to solve the second problem even though
given the scales involved the solution is essentially the same.

(By the way, the question wasn't used as part of the criteria for the job)

~~~
TheLoneWolfling
Those two are not equivalent. Actually, I'm surprised that people didn't find
the _first_ one harder: I've had log files that were larger than RAM before
(mainly due to overzealous logging).

~~~
kstrauser
Exactly! I've been asked the followup question: "now assume that you have 8
petabytes of log files to search", which leads into distributed computing,
realtime vs on-demand collection, eventually consistent counters, the pros and
cons of sampling vs exact counts, and so on.

The unbounded form of that question can be astonishingly hard, and for the
kinds of jobs I'd be interviewing for I'd expect the challenging next
questions.

I'd still answer along the lines of "for a quick solution I'd grep for the
error level and count the number of lines, but that's not scalable".

~~~
TheLoneWolfling
Ditto. (Also, no need to pipe + count: `grep -c` works.)

Also, problem with sampling: you oversample long lines. I'm not actually sure
if there is any way to count probabilistically that doesn't.

I suppose if you had some prior of how long the types were you may be able to
do better, but in general, good luck.

------
kstrauser
If I interview you, you're getting FizzBuzz. I also lay down some ground
rules:

\- Write it in the language of your choice. It's OK if I don't know that
language but be prepared to explain unfamiliar stuff to me.

\- I am not a compiler and I don't care about semicolons, misspellings, etc.
as long as I can understand the point of the code.

\- There aren't any tricks. This is the whole problem.

I _do not_ say anything like "keep it simple" because that can kick candidates
into "OH GOD THERE MUST BE A ONE-LINER AND I CAN'T SEE IT" mode. My goal is to
make the candidate as comfortable as possible in a potentially stressful
situation. I want to give them every chance to succeed.

I've seen people with 10 years as a lead engineer fail horribly. I've seen
people blanch at the concept of loops. Loops! The most common failure mode
I've seen is for candidates to start throwing in lots of state variables like
"is_divisible_by_3" and "has_printed_the_word_fizz", even after I prompt them
toward using "else if" or nested if statements.

One guy laughed and said, "I've done this 100 times. Do I really have to?" I
laughed, too, and replied "OK, just tell me what you'd do." He spat out some
pseudocode that would've worked, I apologized and explained _why_ I make
everyone do this, and we swapped funny stories. My company made an offer that
day, he accepted, and is still successful in that role.

I've also had people complain that this is beneath them. Too bad. You're
asking us to pay 6 figures for your programming skills? Then be prepared to
spend 5 minutes demonstrating them. Your GitHub repo may be a clone of other
peoples' work for all I know. I can and have ended interviews with candidates
who dig in their heels and won't cooperate.

~~~
jknipp
I've started including a small variation of FizzBuzz as part of our developer
screening test - varied so you can't copy and paste from google. Very loose
guidelines, pick your language, access to the internet, etc. We even give a
general outline of what will be tested 24 hours out, and no hard time limit.

3 out of 4 people so far were unable to do the test. One guy boasted 20+ years
of development experience and I used to work with him, he didn't even attempt
it?!? Frankly, I expect candidates of any worth to feel insulted we are asking
them to write this. The guy that did complete it wrote it in Bash, and wasn't
strong in that to begin with. Bonus points for learning a language on the fly,
that's what I'm looking for.

~~~
kstrauser
That matches my experiences. The first time I heard of FizzBuzz, I laughed it
off as ridiculously easy and not worthwhile for screening. I've since changed
my mind.

If a candidate laughs and writes down a canned answer off the top of their
head, I count it as "passed" and we move on to other questions. I've been
horrified at how often it's been a show-stopper, though.

> The guy that did complete it wrote it in Bash, and wasn't strong in that to
> begin with. Bonus points for learning a language on the fly, that's what I'm
> looking for.

I'd give that a double thumbs-up for resourcefulness.

------
henrikschroder
1) If you're doing FizzBuzz at an on-site interview, you've failed in your
process. FizzBuzz is something you use as early as possible to weed out
clearly incompetent developers.

2) I can see how a clever developer might get stuck in analysis paralysis, but
even then you should be able to coax them out of it, and at least get them to
write down a little bit of code that does a loop and an if statement, because
that's what we're really checking: Can this individual write working code from
scratch?

(And if you can't coax them out of it for this, how the hell are you going to
be able to do the same for real problems?)

~~~
talmand
But how do you administer something FizzBuzz outside of an on-site interview?
How do you know they actually completed the task without being with them when
they did?

I'm guessing Skype interview or something similar?

~~~
henrikschroder
I'm using a simple shared editor such as collabedit or similar. You send the
link to the shared space along with the phone number for the interview, and
you let the candidate know that there will be some simple shared exercises so
they need to be at a computer.

And then you ask your questions, and do FizzBuzz or similar, and watch them
code.

------
buro9
> However, I have yet to see one that would actually be better in the real
> world than the simple, obvious solution.

Use counters, avoid modulo, and see a significant performance increase.

Computers suck at division, and FizzBuzz doesn't need division.

The solution is perhaps simpler than the obvious one as even a child could
explain how it works.

[https://gist.github.com/buro9/5345664#file-fizzbuzz-
html](https://gist.github.com/buro9/5345664#file-fizzbuzz-html)

On my laptop, in Firefox:

Fast: 203ms

Slow: 844ms

~~~
thedufer
That depends on how you're defining better. The slow one is somewhat more
readable, and since your test runs a million times farther than the 100 that
FizzBuzz usually asks for, you're looking at a gain of .6 μs. That's an
interesting set of priorities, unless you know something about how often this
code runs.

~~~
buro9
I'm not sure anyone imagines running FizzBuzz in production. It is an
interview tool only, first to determine whether the candidate can program, but
which can also be used as a basis for some interview questions.

The counter example helps to answer whether the candidate understands how
numbers are represented by computers and how addition and division function.

It also helps to answer whether a candidate knows what, in such trivial code,
_could_ (not must) be optimised were the value of n to increase
insignificantly.

As you say, probing questions about how often the code runs, what the value of
n is, or various other questions will all vary the answer. But to suggest that
the priorities are wrong is a little silly, most interview questions are wrong
to some definition.

------
kstenerud
> The dumb (or lazy or new) developer will not notice or care about the
> appearance of a potential cool solution. They'll just bang out whatever
> works.

The _pragmatic_ programmer (aka the person I want to hire) would also not care
about the appearance of a potential cool solution, because experience teaches
us that clever solutions tend to increase complexity and cognitive load,
increasing not only the bug count, but also maintenance costs.

Yes, by all means be clever where it's warranted (strange constraints,
bottlenecks, etc), but please not in regular code!

~~~
gharial
I really couldn't follow his logic at all. Being able to come up with a
working (perfectly correct) solution somehow implies a developer is probably
"dumb" or "lazy"? As if a truly "smart" or gifted programmer would be unable
to come up with a solution because they're just _oh so intelligent and
clever_. You either know how loops work or you don't.

~~~
JoeAltmaier
Most smart programmers I know would prefer to product a good, or even the
best, solution instead of any of the prosaic solutions. Unable to come up with
a solution? Probably not. All the given examples are pedestrian. A really
clever solution would recurse or search the web for a matching solution page
or hash the solution space into a minimal table or something like that.

But agreed a proper programmer would never fail to produce a correct solution.

~~~
kstenerud
That's sort of what I'm getting at. There are two kinds of smart programmers:
Those who look for every opportunity to be clever, and those who are satisfied
to build pedestrian solutions until clever code is called for.

If you're going to build a clever solution (which almost by definition
increases cognitive load on anyone reading or maintaining the code), you'd
better be able to defend your actions. Performance is never a problem until
it's demonstrated to be a problem.

~~~
wtetzner
Yeah, I'd say only go for a non-obvious solution if the result is at least as
readable and maintainable as the obvious solution.

------
hvs
This also points to a situation that I sometimes find myself, where I try to
be "clever" in solving a problem and, even if the solution works, is
ultimately more confusing than the straightforward method. As I've maintained
more code in my life, I've learned to shy away from being "clever", but it's
always there in the back of my mind.

I think this is one of the challenges of functional programming as well. It
allows you to be _really_ clever, to the point of unintelligibility.

------
bobbytherobot
I've seen people fail questions for this reason. We even tell them not to go
down a certain path, or not to worry about optimizing the solution. But they
keep on trying to go down the clever path.

~~~
Sevzinn
The problem is ego. People don't act like the JSON that computers think like.
An array in JSON can represent an unordered set, but people order it according
to how they can become superior to others. People should be more like JSON.

~~~
MichaelGG
> People should be more like JSON.

So needlessly verbose and unable to handle comments?

Oh, and unable to intrinsically distinguish dates from text, or real numbers
from integers?

~~~
Sevzinn
5.0 is real. 5 is integer.

------
z3t4
I think every programmer goes through the "smart" stage, where you start to
get confident and write "clever" solutions for simple problems. Where you will
hopefully transcend to writing simple solutions for hard problems.

Personally I hate stupid tests like these, just give me a real life problem
that you are currently working on ...

Here's my fizzbuzz solution:
[https://github.com/Z3TA/fizzbuzz/blob/master/fizzbuzz.js](https://github.com/Z3TA/fizzbuzz/blob/master/fizzbuzz.js)

And here's my favorite one, on how it would look like if implemented like most
"enterprise code" looks like:
[https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

------
apalmer
This 'problem' with FizzBuzz is really a 'benefit'. I have seen it time and
time again, incredible complex code by intelligent people attempting to chase
an 'elegant' design.

Literally its my number one problem with senior developers where I work,
refusal to leave working simple readable solutions alone.

~~~
chwahoo
But as she points out, FizzBuzz doesn't do a good job in telling you if you've
found one of these developers because the context of interviewing is different
than the context of banging out code on the job.

------
brudgers
Internationalization suggests that "Fizz" and "Buzz" be parameterized...and
maybe we shouldn't hard code "3" and since magic numbers aren't good practice
either...and the possibility of a different search function for the "FizzBuzz"
suggests parameterizing that value, too.

Which is to say that one of the problems with FizzBuzz is that the interviewer
doesn't take it seriously enough to care about engineering practice at the
level that matters. If they did, FizzBuzz would come with a test suite.

~~~
jameshart
So if you're asked to do fizzbuzz in an interview, feel free to bring these
things up. Just don't make it seem like you're looking for excuses not to
write code.

If you approach fizzbuzz by saying 'okay, so you want me to write a program
that generates this sequence on demand - otherwise we could just precalculate
all 100 values - so I'm going to assume that you want something
parameterizable. How about we make it take a dictionary of factors that map to
certain keywords, and we take { 3: "Fizz", 5: "Buzz" } as an initial
testcase?' I'm going to go along with that, so long as the code you write
actually works. I might walk you back from internationalizing the output, but
points for mentioning it.

~~~
brudgers
FizzBuzz suffers from the StackOverflow fastest fingers on the internet
problem, it favors cursory poorly engineered solutions. By which I mean what
is FizzBuzz supposed to do if IO blocks because stdout got redirected to a
resource that's not available?

When the code the interviewer wants to see has IO operations spaghettied
throughout the business logic rather than separated as a concern, is the
exercise selecting for people who are perfectly willing to do only what is
asked rather than what is needed?

How many lines of code would FizzBuzz really be if we were serious about it as
Engineers?

~~~
jameshart
So.... you really are trying to avoid writing any code, then?

~~~
brudgers
I wrote and published a FizzBuzz about a year and a half ago when applying to
Hacker School. It's pass by reference available on Google. The technical
thrust of my first comment largely reflects what I learned from the exercise.
The IO and crosscutting concerns in my second comment are a reflection of more
recent additions to my understanding of software systems and the exercise of
rethinking FizzBuzz brought them to the surface.

The simplicity of FizzBuzz's business logic should not be seen as indicative
that our computer systems are suddenly likewise simplified. Odds are you're
not hiring people to write strings to the console.

------
dlandis
In my experience after reading her book and some of her articles I think Gayle
(and many other interviewers) underestimates the effect nerves have on certain
people. She may be a little too quick to classify certain people as "dumb"
when, in fact, some people's brains just totally freeze up during traditional
coding interviews. I suspect more outgoing, extroverted people have a hard
time fathoming what that's like or even that it is possible.

------
kelukelugames
I can't wait for someone to ask me a fizz buzz question. I am going to write
this out:

switch n case 1: case 2: print n case 3: print "fizz"

it's going to be so much fun.

------
MollyR
Yea I don't know how I feel about this article. I know my team lead asks
FizzBuzz to all new hires, and he's looking for elegance and robustness even
in simple designs because when we work on our complex systems, it matters a
lot for having a good code base.

Just the fact they think in terms larger than just the basic code is what I
think he looks for.

------
imron
'The problem with using light grey text on a white background' would also make
an excellent article topic.

------
sopooneo
Out of curiousity, what is an elegant solution for her problem of finding out
what year had the most people alive? I can think of a couple brute force
methods, but I've not been able to phrase the question properly to find an
ideal solution on Google.

~~~
gaylemcd
Here's a solution that takes O(P + R) time, where P is the number of people
and R is the total range of birth years.

First, notice that you don't really care _who_ died when. All that matters is
someone died. People's birth and death years are fungible, in a sense. Each
birth increases the population by one and each death increases the population
by one.

Basically, you'll create an array where the value at each index represents how
much the population _changed_ in that year (steps 1 to 3). Then you can use
that array to find the highest population (step 4).

1\. Get the min birth year and the max birth year.

2\. Create an array where the size is the above range. Set to all zeros. Each
index will map to / represent a year in the range.

3\. Loop through all the people. For each person, increment the index of their
birth year and decrement their death year (or the following year, depending on
whether or not they're counted as alive the entire year of their death)

4\. Just loop through the array, tracking the running sum at each index. The
biggest running sum will indicate the highest population.

There are some other good solutions depending on what assumptions you make
about P and R's relative size.

~~~
TheLoneWolfling
Hmm...

If you sort everyone's births and deaths you can just walk through the array
keeping track of the number of people alive at each point and the maximum
number of people alive at any point (and the year(s) thereof).

O(P log P) (from the sort), no explicit dependance on R. Are there any other
good solutions? I cannot imagine that there would be anything that's sublinear
in P, so about the only other thing I could imagine would be something that is
linear in P and sublinear in R.

~~~
gaylemcd
Yes, that's another good solution.

You can't really compare O(P + R) and O(P log P).

Of course, you could argue that P could grow a lot faster than R, so O(P + R)
would be better. That's probably true in a "real world" sense, but not in a
mathematical sense.

------
JoeAltmaier
My sister's question was, how many Ping-Pong balls fit in a semi trailer? She
would add no details. The idea was, could they function with limited info,
make assumptions, come up with any answer at all. Most couldn't.

~~~
bobbytherobot
My follow up question if I was in that interview would be, "Is this how you
operate, do you not provide critical information or am I a researcher?"

~~~
mikeash
My follow up to that follow up would be, it's 2015, internet access is
ubiquitous, and if you can't find the dimensions of a standard ping pong ball
and a standard semi trailer without having your hand held, then we don't need
your services.

~~~
yellowapple
In that case, would the interviewer be fine with me pulling out my phone or
laptop and looking things up during the interview? If not, then I'd strongly
question the interviewer's (and, by extension, employer's) sanity.

~~~
mikeash
I'd sure hope so. I'd question any interviewer's sanity if they forbade
standard working tools in an interview that's supposed to gauge one's ability
to work.

