Effectiveness of FizzBuzz and Beyond [closed]

Question

As part of the interview process we initially ask the candidates to do 'FizzBuzz' nowadays the percentage of candidates that can correctly answer FizzBuzz has increased dramatically - this may be due to it's popularity on the web.

About a year ago, as a second question we began asking a question very similar to the original FizzBuzz. The question was designed to be as simple as the original FizzBuzz, and to also assess a particular ability of the candidate, specifically the ability to order and prioritize in a meaningful and logical manner a set of "business rules" that have been provided in some arbitrary order. The wording of the question initially seems slightly ambiguous, which may make it difficult for non-native English speakers, but if thought through can be correctly resolved - Also it gives the candidate the opportunity to ask questions for clarification, which is always a good thing.

We find this a very important skill to have as a developer, as software development is typically based on functional requirements that are derived in no particular order over time, that may place constraints and conditions upon other areas of the software without explicitly indicating and it is the job of the astute developer to at the very least investigate potential issues and conflicts with regards to the implementation.

What we found was that a little over 65% of the candidates (sample size of 38) that passed FizzBuzz completely failed FizzBuzz v2.0 Normally these candidates would be detected later on in the process, but it seems to be a nice way to detect them early on.

My question is not about whether or not FizzBuzz is outdated, but rather what factors could be contributing to such a high number of candidates failing the FizzBuzz v2 question.

• Is the question too ambiguous?
• Does the stress of an interview environment decrease ones ability to think critically to the point of not being able to complete such a trivial task?

Question:

Write a routine in your favourite programming language that will take a list of strings as input, and for each string in the list will do one of the following:

1. Print only Fizz if the string contains the letter A
2. Print only Buzz if the string contains the letter B
3. Print only BuzzBuzz if the string contains both A and B
4. Print only FizzFizz if the string does not contain both A and B
5. Print only FizzBuzz if the string contains only one A and only one B

---

Some typical questions asked by candidates are:

• Should it be case sensitive?
• Does "contains A and B" mean A should come before B
• What should be printed if none of the points are met?
• What should happen if more than one condition can be met?

We found that the overwhelming majority of candidates that successfully completed the question, didn't ask anything at all they just did it like they did FizzBuzz.

Answer 1

It's has the potential to be a much better test than FIZZBUZZ, but if you have any concept of a correct answer, its the worst test in world. These tests have very little value in interviews to start with.

If a candidate answers it "Correctly" without asking a question, then you have a problem that the candidate selection will select the wrong kind of programmer- He is unable to identify ambiguous requirements, or is unable to comprehend that most people cannot write unambiguous requirements. It does not matter if the program is technically perfect in every aspect, it's likely he's the kind of guy that will deliver software with a "I don't care its not what you wanted, that is what you asked for".

The part of the test here is the priority order of the rules. You do not specify it. Input "ABC" can print Fizz, Buzz, BuzzBuzz or FizzBuzz - any one of these is correct

The candidate I would take is the one who got it (mostly) right, but asked lots of questions and, ideally, did lots of "doddling" on the white board.

For instance, i would explore my understanding of those requirements by giving you a series of samples texts, and asking you what you expected to be printed, and why. - Discussion on my "ABC" example input should lead to some useful insites for you.

Just like FIZZBUZZ, the result of this test is only as good as your observations made on how the result was obtained - the result is irrelevant.

I would tweak it a little - just to make it more interesting - take the 'only' out. It's covered in the line above ("print one of the following"), and see how many people ask about it. If the candidate misses the "only" and you have time, point it out and see what happens. If he deals with the "only", remove it from the requirement and get them to change the code.

Answer 2

The word "only" in your requirements creates a contradiction in all questions.

Thus your question tests requirements gathering while under pressure, are you sure you want to test for that combination of skills?

If you want to test requirement gathering, I would suggest making ONE of the questions ambiguous. If you want a replacement for FizzBuzz, remove the ambiguity.

Prioritizing business rules can only be done with domain specific knowledge -- unless you include some simple context for what you are doing (perhaps they are coupons to be redeemed for various values), there's no basis for the developer to make his own decision.

But requiring someone to ask for clarifcation where doing so has a significant risk of undesirable outcome, is perhaps not the best way of gauging their skill in recognizing the limits of their knowledge. They may figure that it is safer to guess and get it wrong, than to point out that you are incompetent at writing requirements, or if none of the interviewers are developers, being labeled as having a bad attitude.

Answer 3

We found that the overwhelming majority of candidates that successfully completed the question, didn't ask anything at all they just did it like they did FizzBuzz.

With the ambiguity of the requirements one can not finish v2.0 correctly without asking questions.

Answer 4

If you want to remove any ambiguity, you can change the requirements to:

Write a routine in your favourite programming language that will take a list of strings as input, and for each string in the list do the following:

1. Print "Fizz" if the string contains the character '$' and does not contain '?'.
2. Print "Buzz" if the string contains the character '?' and does not contain '$'.
3. Print "FizzBuzz" if the string contains exactly one '$' and exactly one '?'.
4. Print "BuzzBuzz" if the string contains exactly one '$' and more than one '?'.
5. Print "BuzzBuzz" if the string contains exactly one '?' and more than one '$'.
6. Print "FizzFizz" if the string does not contain '$' and does not contain '?'.

Answer 5

Is the question too ambiguous?

Yes, the question is too ambiguous to be answered without clarifications. However, an additional rule saying that in cases when multiple rules apply, your program should pick the most specific thing, should remove the ambiguity.

Does the stress of an interview environment decrease ones ability to think critically to the point of not being able to complete such a trivial task?

It's more likely an indication of the candidate "cramming" the FizzBuzz: stress or not, the program is very simple.

I think the modified FizzBuzz is not comparable to the original one, because its ideal solution is different: although a chain of if-then-else remains acceptable, I think that a table-based solution is more appropriate for this problem:

static string[,] FB = new string[3,3] {
    {"FizzFizz", "Buzz", "Buzz"}
,   {"Fizz", "FizzBuzz", "BuzzBuzz"}
,   {"Fizz", "BuzzBuzz", "BuzzBuzz"}
};
static string FizzBuzz(string str) {
    return FB[
        Math.Min(str.Count(c => c == 'a'), 2)
    ,   Math.Min(str.Count(c => c == 'b'), 2)
    ];
}

The size of the problem space is 3x3, not 2x2, so it maps to a table much more readily than the original FizzBuzz. In fact, I find a table-based solution to the original FizzBuzz problem harder to understand.

private static string[] FB = new[] {"{0}", "Fizz", "Buzz", "BizzBuzz"};
public static void Main() {
    for (var i = 1 ; i <= 100 ; i++) {
        Console.WriteLine(FB[(i%5==0?2:0)+(i%3==0?1:0)], i);
    }
}

Answer 6

Two things here:

1. yes I think most people just googled fizz buzz and then stumble when they try to expand it
2. Check out : http://dave.fayr.am/posts/2012-10-4-finding-fizzbuzz.html It explains nice how you can solve fizz buzz using appropriate abstractions.

Answer 7

We found that the overwhelming majority of candidates that successfully completed the question, didn't ask anything at all they just did it like they did FizzBuzz.

I've seen interview processes that encourage programmers to think out loud and ask questions to see their thinking process. I like this process better.

I read through this fizzbuzz v2.0 and I would asked about #3 and #5 requirement there. I don't know about other people but I find in engineering I don't want any ambiguity so I ask question. Because later down the line (coded and all), I don't want to find out I had to make an assumption and it was wrong.

Answer 8

Perhaps the easiest way to avoid ambiguity is to show some examples:

"A" returns "Fizz" "aAbA" returns "Fizz" "B" returns "Buzz" "aBbB" returns "Buzz" "AB" returns "FizzBuzz" "ABaabb" returns "BuzzBuzz" "" returns "FizzFizz" "ab" returns "FizzFizz"

Answer 9

Instead of giving a candidate contradictory/unclear requirements, just ask them how they handle those situations. Otherwise you're making yourself look incompetent or worse putting competent people on the treacherous balance beam of "how do I get the answers I need without implying that this interview question or the person asking it is stupid?"

Either way, it's irritating as all getout. Interviews are a matching process and by that, I mean a 2-way street. Direct questions and clarity of intent are a lot more important than putting the candidate under a pressure cooker, IMO. FizzBuzz is a good example of a coding question because it's short and sweet. Don't re-use it directly. Write simple questions like it that follow that model.

But for FFS don't get clever about it and hide the real test behind another test. Just ask people how they handle the damn problem. An experienced dev will have dealt with ambiguous requirements repeatedly and will be delighted to tell you their strategies. You might even learn something.

And don't assume everybody wants to use a whiteboard or is comfortable handwriting period. Some of us have been typing since we were 12 (with much thanks to Space Quest). I can't even think straight with a pen or marker in my hand. It's 20-freaking-13, what's with the whiteboards already? When people hand me a pen and paper and ask me to do a code-test it's hard to suppress a laugh.

Answer 10

I think it is a nice interview question. The requirements are unclear, just as they are often in reality. You check whether the candidate is intelligent enough to realize this (even under stress), that he/she is not afraid to ask questions they deem necessary, and is able to put the requirements into a sensible structure. And it does tell a little bit about their programming abilities, though you should also pose some more complicated problems containing recursion and pointers, since this problem is too easy.

However, I do worry a little about the "successful" candidates not asking questions. I'd try to find out whether they realized you can apply up to 4 of the rules in some cases and that there is nothing in the question that would resolve that ambiguity, and have them explain how they dealt with that. Perhaps your question is not ambiguous enough to force them to ask, or perhaps you should ask them to think aloud.

BTW: I find it strange that you are talking about a "correct solution". If you word the question like that, it is legitimate to print either of "Fizz", "Buzz", "BuzzBuzz" or "FizzBuzz" if you get "AB". So IMHO any solution with no questions asked is plain wrong.