Hacker News Reader

I consider as broken all interviewers who extrapolate a candidate's decision on this issue to real-world "business requirement changes."

This is one of the worst parts of technical interviews.

"Take 10 minutes to write out code for this simple, abstract, poorly defined problem. Okay, now I'm going to ding you because you didn't write it using the same mindset you'd use when writing a large application tailored towards a specific domain and given a detailed set of constraints."

Maybe we should call this sort of cargo-cultism Schroedinger interviews. If you make your code simple and easily readable in order to solve the problem in the most intelligible way, you get penalized for not making your solution scalable/easily adaptable to "business requirement changes". If you structure your code so that it can easily be extended or modified you get penalized for YAGNI and premature optimization. Of course, exactly what the interviewer is looking for is never actually specified as part of the problem statement, because it exists in a state of quantum superposition until right before the interviewer decides whether or not he or she likes your physical appearance/sense of humor/"cultural fit".

It's interesting that you can't imagine code that explicitly prints fizzbuzz with a third conditional. It's as simple as this:

for i in fizzbuzz range fizz = i % 3 == 0 buzz = i % 5 == 0 if fizz and buzz print fizzbuzz else if fizz print fizz else if buzz pritn buzz else print i

If you want to see how they react to changing requirements, then ask them to change it. It's stupid to look at someone's answer to a toy problem and treat it like it's production code.

> It's stupid to look at someone's answer to a toy problem and treat it like it's production code.

There are no toy problems in interviews. The way you approach a toy problem says everything about how you would write production code according to the 'how to hire programmers' manual v 3.3.

Obviously that's not how it should be but if you're going to places where they think 'fizzbuzz' is going to weed out the ones they don't want then you'd better be showing off your capabilities.

A good interview exercise (not necessarily vouching for fizzbuzz here) allows depth of discussion past the initial answer. It is in this discussion stage where I spend the majority of my time with a good candidate.

In such a discussion we might talk about whether it makes sense to make the /15 case "fall out" naturally. Using your example, there's an implicit assumption that the requirements would change to {4: fizz, 5: buzz, 20: fizzbuzz}, but in real life I've found things have the annoying tendency to change to, e.g. {4: fizz, 5: buzz, 15: fizzbuzz}.

How would you handle a case where it's not divisible by either? We need to handle a conditional that evaluates to true when the number is not divisible by either 3 or 5:

    #include <stdio.h>
    void main()
    {
        unsigned int i, is3, is5;

        for (i = 1; i < 101; i++)
        {
            is3 = i % 3 == 0;
            is5 = i % 5 == 0;

            // If both are true,
            // FizzBuzz gets printed
            if (is3) printf("Fizz");
            if (is5) printf("Buzz");

            // Still need to handle
            // the raw number though
            if (!is3 && !is5) printf("%i", i);

            printf("\n");
        }
    }

Well, I'm always a little baffled when I see such great techniques for rejecting potentially awesome candidates.

Why overthink a toy example? The only purpose served by fizzbuzz is to weed out people who can't write any code.

If you want to know anything else, ask a more relevant technical question. It's downright lazy to simply jump to conclusions, and as a result you end up hiring the wrong person.

To be clear, I'm not referring to candidates. I'm referring to the questioners/interviewers suggesting this approach.

Here I have an explicit "FizzBuzz" but only 2 checks. Do you consider this also broken?

   python3 -c '
     for i in range(1,20):
       print([i,"Fizz","Buzz","FizzBuzz"][int(i%3==0) + 2*int(i%5==0)])'

You assumption that a separate case that prints fizzbuzz will break the code is not correct. With correct code, you get three if checks either way, but the readability is higher, code complexity is lower and cases are nicely separated.

  bool is3 = i%3 == 0 ;
  bool is5 = i%5 == 0 ;	
  
  if( is3 && is5 )
  {
  	printf("fizzbuzz\n") ;
  }
  else if( is3 )
  {
  	printf("fizz\n") ;
  }
  else if( is5 )
  {
  	printf("buzz\n") ;
  }
  else
  {
  	printf("%d\n" , i ) ;
  }

And what if there's a is7 woof criteria as well? You going to add another set of special cases for fizzwoof, buzzwoof, and fizzbuzzwoof?

You see the problem, versus just doing fizz, buzz, and woof distinctly?

It is not logical to subvert your code to adhere to some imaginary future requirements.

>But what if the business requirement changes...

Are you kidding? This is FizzBuzz! It is just a quick check to verify that an applicant is even a programmer at all. That's all it is. There is nothing else there.

Depends on how the task is communicated and what's implied.

Also recognize that there are excellent programmers who take to heart Dijkstra's dictum to "Always design your programs as a member of a whole family of programs, including those that are likely to succeed it."

Has AmaTwitBookGooSoft ever asked for a generalization of FizzBuzz? I wouldn't put it pass them.

I don't think you know what the word 'broken' means. You sound like the type of person that would make code as terse as possible with all kinds of traps for future maintainers.

Fizz on /3, Buzz on /5, is the actual requirement. Shortcutting /3 & /5 with a hard coded /15 that has to be edited if /3 or /5 changes, that's the trap.