I was once presented this during an interview which wasn't going too well (I decided I didn't want to work there after seeing the working conditions of the developers: 60+ developers crammed in a small room with minuscule desks, distributed in rows where people would bump into the chairs whenever they had to get up and move) and they told me that a lot of the candidates couldn't solve it and would be an elimination test. They told me I could use any language I wanted, so for kicks I did a simple Haskell version of it (nothing complicated, just a fizzbuzz function mapped over the list). I was told on the spot that I failed and they wouldn't continue the interview.
Why the this story, just if you give anyone a choice of any language to solve fizzbuzz or other problem, be sure you are open to see code that looks strange to you.
I love FizzBuzz. The great thing about it is that it's easy to write code that works so candidates can feel happy that they've 'passed' but flexible enough that people's solutions will differ. And that's what you want in an interview situation - working code that you can talk to the candidate about. If you question what they've done and the candidate can explain and defend their decisions then you can figure out if they'll be able to speak up and contribute to technical discussions, to communicate their ideas and comment on other people's solutions. That's the sign of a good developer (in my opinion).
If a person cannot do FizzBuzz, they cannot program. But a lot of terrible programmers are fully proficient at the FizzBuzz level of programming. I don't think it really provides a useful venue for assessing skill beyond bare minimum levels. I have another interview question that I use for chemistry matching, but it's more algorithmic than coding.
Even a simple solution to FizzBuzz can lead to interesting discussions. Why did the candidate use nested ifs rather than a cascade or a switch, why did they use a modulus operator instead of division, why didn't they bother to catch errors if a non-integer value was passed to their function, how could you efficiently make the code scale to work with a bigint, what would you do if the code required abstraction so the parameters could be defined at runtime, and so on pretty much ad infinitum.
The beauty of FizzBuzz is that while it's obvious it can lead to interesting places. If a candidate just knows a way or two to implement it they'll quickly run out of things to say when you're talking about their solution. Discussing a solution and improving it is a skill you want in a developer. FizzBuzz can discover how competent they are at that. The way I use FizzBuzz isn't really about finding out if someone can code. It's about something bigger than that.
Where's the fun in the simple straightforward implementation ? How would you judge a candidate that, on the spot, decided to go with a new way to solve it just so (s)he could see if it worked out well. For example ... something like this ?
print '\n'.join(("fizz" if x % 3 == 0 else "") + ("buzz" if x % 5 == 0 else "") or str(x) for x in range(1, 100))
or even:
from __future__ import print_function
map(print, (("fizz" if x % 3 == 0 else "") + ("buzz" if x % 5 == 0 else "") or str(x) for x in range(1, 100)))
What if they come up with a solution, you have no idea why it works, but it works ?
Sadly, I expect most interviewers would react very negatively. I've already learned never to demonstrate actual programming ability, even when asked. Instead, answer every question the way you would answer physics problems in high school. You know, the problems asked by the teacher who has a bachelor in biology.
People are even justifying this with "clean code" arguments and the like. "Why aren't you using the framework ?". "Is that the best way to write such a complex thing". Worst of all : "what does that mean ?". You don't want to be asked those questions, it will not end well.
Interviewers who can't program will then start arguments about how programs should be designed/written, and the answer boils down to "design by committee, manned 90% by people who cannot pass FizzBuzz". Of course, best to leave out the second part if you point this out and instead add "ask for feedback".
I'm a little bit surprised of "if-else if-else if" mindset in c2.com wiki entry for this. I always thought of FizzBuzz solution without a single else, like this:
for (int i = 1; i <= 100; ++i) {
boolean pureNumba = true;
if (i % 3 == 0) {
System.out.print("Fizz");
pureNumba = false;
}
if (i % 5 == 0) {
System.out.print("Buzz");
pureNumba = false;
}
if (pureNumba) {
System.out.print(i);
}
System.out.println();
}
I like to think it's matter of readability. "if (pureNumber)" vs. "if (i % 3 != 0 && i % 5 != 0)". Also, one extra variable vs. reversal of already mentioned condition. Yes, we're splitting hair here :)
The solution doesn't takes into consideration the 'fizzbuzz' output. Your solution would print both fizz and buzz when the int is divisible by both 3 and 5.
"[FizzBuzz helps to] filter out the 99.5% of programming job candidates who can't seem to program their way out of a wet paper bag."
He's not saying 99.5% of candidates can't do it, but rather 99.5% of candidates who can't seem to program their way out of a wet paper bag can't do it. Presumably 1 in 200 of the candidates who can't program manage it by blind luck.
i dont think its correct though - the first time i got asked this problem was the also the first time i heard of fizz buzz - and i had already been doing c++ perl and shell scripting for 15 years... there was no written explanation, and i had no f clue what he was talking about. i couldnt solve it then and today 3 years later i could probably barely solve it.
when he said "print every number up to one hundred and if its the 3rd line print fizz and if its the fifth line print buzz"... honestly my train of thought was "why the fk would u print every line and print again if its the 3rd line and print again if its the fifth line...?? and why would you print 6-100?"... not the best explanation either, and i had no idea he meant print the string "Fizz" when he said print fizz... i thought maybe he meant some ruby gem rails.Fizz or what not...
of course the commenters code example above is clear as day, maybe i just read code better than i talk about code (this so much... for a lot of us). and i didnt get that job.
I've run into this as well. Of course, it was ultimately a good negative filter; if the interviewer could not clearly explain what he wanted out of such a simple program, how would he have done at explaining the requirements for a much more complicated program?
I had a few interviews just out of university. One place gave me a list of boring questions about C++ regarding inheritance, etc. seems straight from a text book. At the other place they asked questions about the political situation in East-Europe and why design patterns might be detrimental to the quality of code. Regarding the fact that I love AI/ML and programming is just a means to me, this wasn't a difficult choice.
The job of the person that gets interviewed is to weed out the places where you do not do anything interesting intellectually.
Sure, ask this question, but you'll ask quite a lot from your applicant to still consider your company an interesting place to work for.
This is by far my favorite interview question to give. In case the candidate may have memorized it, I might make a slight alteration. Like count backwards from 102 to 2 and don't print anything for prime numbers.
Is it? Seems to require about the same knowledge as the original FizzBuzz. Even if it didn't, if a candidate couldn't write the logic to determine if a number is prime or not... that's another red flag.
def is_prime(x):
if x%3 and x%2:
return True
else:
return False
print is_prime(4)
print is_prime(7)
EDIT: Oops, nevermind... you're all right and I'm wrong. I'm not fixing this code so everyone can see exactly how I screwed up.
I can't even tell if you are being sarcastic or not. Either way I certainly wouldn't hire you.
Edit: Perhaps you should keep this in mind next time you declare 99% of programmers incompetent because they made a typo when you asked them to write code down with pencil and paper in a high pressure interview situation.
It's amazing how much doing a few interviews inflates people egos.
Hmm, the only off-the-cuff way I can think of to do that would be an Eratosthene's Sieve -- unless I hardcoded the primes in a fatty switch statement. I think I could remember/figure all the primes in that range in a few minutes.
Am I missing something, or is that basically what you're looking for?
I actually don't think I've had anyone completely blow up on it, except once a long time ago in a previous company with someone who turned out couldn't even do helloworld. They usually do it and later all the devs look at the solution if they like it or not. In my company you can't know how everyone votes. It's just a bunch of anonymous "+1"s or "-1" and after the votes are added up if the candidate got a huge negative number it's a no-go. Around zero is handled case-by-case I think and huge positive is extend offer. A neutral person does the vote-counting. I guess the phone screens are doing a pretty good job of dropping anyone who'd bomb it in the office.
So... actually, I don't know if it's filtering anything really. It's just interesting to watch people do it and it at least establishes that the candidate isn't a complete faker.
It also pisses off the 0.5% that know how to program
Best programming test I've seen was one that was done online, and automatically ran your test through unit tests.
Doing a test is fine, but do it, don't waste my time and move on accordingly to the result. Also, make me do it first, so the technical ability is off the table at an interview, don't make me 1) do it "on paper", (or like a quiz show) and in your location and 2) rate on objective measures (like passing/failing some test) and be transparent about scores (like they would be in a code review)
It doesn't piss off anyone I know that knows how to code because it's simple and it only takes a few seconds to complete. Everyone I know that can code is done the exercise before its even a second thought.
I agree with being transparent about the discussion around the result of any programming done during an interview but having the person do it before hand defeats the purpose of using it to catch out people who can't actually code because they will just Google the result.
I just had a make this app in 2 hours. Usually I like to think about a design for at least half a day before coding. So I did this, evolved my design on the way got it 80% finished, then was criticised for not including tests. Seriously, who even has to produce something other than a two line bug fix with a 2 hour deadline? As I get more experienced, I realise thoroughness is way more important than raw speed. Over the long term it saves a lot of time.
I had to implement a spreadsheet (with formula) in Perl with a 2 hour deadline. Completed the task (apparently no-one else had) but didn't get the job because the CTO had a hard-on for Scala and I said it was stupid to rewrite existing money-making systems into a brand new language for no good reason.
You're not the target of Fizzbuzz though clearly. But with that in mind you should be able to finish it so quickly that it would take less time than a standard question about your last job.
>FizzBuzz irritates me because they haven't gone to the trouble of thinking something else.
Because they don't have to. It's simple and easy to use filter that will remove a lot of noise. It's not perfect, some people will memorize a solution to it but simple changes to the question solve that. But it does really work.
I think having to sit on the other side of the table for a while gave me a lot more respect for the pain that is being an interviewer.
>Another thing I was given was "make me something interesting in 30min" or "try to solve this problem in 2 hours"
Which are totally different and often useless beasts though done right really helpful but honestly I was never willing to invest 2 hours into a single interview nor make someone sit in a room for 2 hours while I went back to work.
This is an example in Python using list comphrension.
["Fizz" if isinstance(x,int) and x%3==0 else x for x in ["Buzz" if isinstance(x,int) and x%5==0 else x for x in ["FizzBuzz" if x%3==0 and x%5==0 else x for x in l]]]
I'm using a triple check, I'll find a better solution with just two check.
Using a triple check with map:
z=map(lambda x: "FizzBuzz" if x%3==0 and x%5==0 else x, range(1,101))
y=map(lambda x: "Fizz" if isinstance(x,int) and x%3==0 else x, z)
t=map(lambda x: "Buzz" if isinstance(x,int) and x%3==0 else x, y)
What I find strange about this test is that it also weeds out 99.5% of candidates who can't seem to google for "programming interview" before turning up at one! Amazing how many (3rd year Comp Sci) students have never heard of it.
Thing is, I graduated CS without ever hearing about this, but that doesn't make it any less trivial. The amount of HN articles on this question makes me feel like I'm missing some huge "gotcha" secret about the answer.
This test still seems to be under the radar of a lot of candidates. We'll need something else to weed out the surprisingly large amount of candidates who don't seem to be able to actually code one day though. Any ideas?
I have downloaded a description for a random (relatively simple) algorithm off Wikipedia before, put it as the comment in a text file, and then asked people to implement it.
Do it yourself first, so that you have interesting questions to ask; and you can keep iterating on it too. Get them to write tests for it, documentation, what are the error conditions, how do they want to do error processing, and so on.
I used to ask them to find average of array of ints. For bonus points to make code bullet-proof (what if someone passes null array, what if integer overflow happens etc). Surprisingly how many candidates failed because they used integer division (in Java), and how many didn't even think that something can be null...
I find my version much more readable. I am a hobbyist, is there anything better in beardo's version apart from being re-usable? Mine seems more like a direct transformation of the "verbal" logic into simple code.
<?php
for ($i=1;$i<=100;$i++) {
if ( ($i%3===0) AND ($i%5===0) ) {
echo "FizzBuzz\n";
} else if ($i%3===0) {
echo "Fizz\n";
} else if ($i%5===0) {
echo "Buzz\n";
} else {
echo $i."\n";
}
}
?>
Three things, mine is PHP 5.6 (Generator), second, I'm only using both 'Fizz' and 'Buzz' once. Maybe you can try to rewrite your code to something similar that concatenates the two strings ;) Last, mine version does not rely on `echo`, it generates a list and uses an foreach to print it.
Why the this story, just if you give anyone a choice of any language to solve fizzbuzz or other problem, be sure you are open to see code that looks strange to you.