There doesn't need to be a separate test for 3 and 5, his example already handles it properly -- it's two separate if statements, not an if/elsif, so it'll just meet both conditions and print "fizz" then "buzz" to create "fizzbuzz". What's forgotten is printing the number alone if it's divisible by neither.

Fizzbuzz is one of those problems where there's really no clever hidden golfy solution better than the plain old first-reaction naive approach: an iteration with if/elsif/elsif/else.

> Fizzbuzz is one of those problems where there's really no clever hidden golfy solution better than the plain old first-reaction naive approach: an iteration with if/elsif/elsif/else.

There is if you exploit that monoid homomorphisms exist from any monoidal type to both the Optional and Function types.

My favourite solution is this:

    let (m ~> str) x = str <$ guard (x `mod` m == 0)
    in map (fromMaybe . show <*> 3 ~> "fizz" <> 5 ~> "buzz") [1..100]

This is extensible because you can stick as many rules as you want in there, or even factor them out and make it a function

    (m ~> str) x = str <$ guard (x `mod` m == 0)

    fizzbuzz rules = map (fromMaybe . show <*> mconcat rules)

    fizzbuzz [3 ~> "fizz", 5 ~> "buzz", 7 ~> "bazz"] [1..100]

> Fizzbuzz is one of those problems where there's really no clever hidden golfy solution better than the plain old first-reaction naive approach: an iteration with if/elsif/elsif/else.

There are. With a funky calculation.

For example, taken from Rosetta C version:

  for (int i=0;++i<101;puts("")) {
    char f[] = "FizzBuzz%d";
    f[8-i%5&12]=0;
    printf (f+(-i%3&4+f[8]/8), i);
  }

You might say the calculations are hidden if/else, but well...

It's possible to do with a switch statement as well (in C).

Edit: Would be nice if the original author of that code snippet threw in some parentheses for a little clarity with the operator precedence.

Your right, I'd probably dock points for readability though because that's not immediately clear.

I usually give his answer (but in Python), and every now and then the interviewer will make your same mistake (if if, not if else if) Delightfully awkward, the worst was the guy who didn't believe me and popped up a shell to test it. What's the appropriate social response when someone trips over their own weed-out question?

If I were asked I might just go verbally, well; for i from 0 to 100, if i mod print fizz, else if etc. Followed by test it, check loop conditions, edge cases, representative number of ifs and prints for each type; put a header on the code with a description and we're done.

For me it's not about getting it 100% correct, its about showing that you can do basic programming and know how computers work, followed by the simple breaking down of a concept into a program.

The rest I consider details. Even if you implemented it 100%, its so simple that it doesn't nearly guarantee that you will do the same for a large program. And if you don't get it 100% correct, as long as you roughly indicate some fields where you're going to test for issues I'd be more than happy about it. Thereafter the human factor/generics, for example did it take you 30 minutes to think this up or was it pretty much rapid-fire? How learned of a response is programming to you?

But as to your question; people don't really like being showed up, but that works well for filtering for you as well. If he hated it then it might very well not be a place/person you want to work with.

Something like: do I really want to work with you? :)

Nah. Something like: It's ok, don't let it get to you. Technical interviews are hard.

True. I interviewed a guy once who found a bug in my example code so I hired him on the spot.

you leave the interview and say you're not interested in the company anymore :P

you should look at the code again.

I did when others corrected me. I would have docked you for producing something that's not particularly readable. Fizzbuzz isn't about providing a clever one liner.