The main thing I look for with FizzBuzz solutions in general is how many modulus operators are used. The junior end of the spectrum tends to use four (% 5 && % 3; % 5; % 3), while intermediate/seasoned developers will either use three (% 15; % 5; % 3), or two (storing % 5 and % 3 in variables, then comparing the combinations).
My personal preference in terms of demonstrating maintainable code is using two modulus operations with variables. However, I fully understand the argument that an additional % 15 is preferable compared to the overhead of storing two variables on each iteration. Both are valid approaches IMO, and the debate can roar on for eternity. Micro-optimizations and whatnot.
I just don't like to see four modulus operations, which IMO shows a lack of basic willingness or ability to refactor while coding. It's fine to initially write the four modulus operations, but if someone doesn't immediately catch the duplication and do something about it, it screams "I write code until it works and then move on without cleaning anything up."
Strangely enough, only once have I seen someone use the % 15 optimization and add a short comment along the lines of "// least common multiple, divisible by both 3 and 5". Spotting the optimization is nice; placing a short comment explaining why % 15 when the test is about % 5 and % 3 is a nice touch. Explains something that might not be immediately obvious to the next person coming to the code.
Aside: it astounds me how many people, when asked to write a short snippet of code during an interview, have basic formatting problems and inconsistent code style. I've seen two lines of code inside an if() block indented at different levels, with no excuse for "different opinions on formatting". Not a wrapped line continued on the next, but just two simple statements inexcusably indented at say 8 and 12 spaces. Don't call us, we'll call you...
How many zero-modulus solutions (and still using a loop, not just a long precomputed string) have you seen? In my experience, this is the rarest type. Of those who can write a correct FizzBuzz (which is already a pretty small fraction of the total candidates), I like to ask "how would you do this without any modulus" and very few of them can easily see the pattern that makes this possible.
Aside: it astounds me how many people, when asked to write a short snippet of code during an interview, have basic formatting problems and inconsistent code style.
If this is being done on paper or an absolutely "non-IDE" text editor then it's probably someone dependent on an IDE to do the right formatting for them. If they still do this in an auto-formatting IDE, it's probably a sign that they have no good idea of the structure/flow of the code.
What is the "optimal" answer you are looking for if you ask to solve it without modulus? Build modulus by hand, or using additional resetting counter variables?
I forgot to mention the variation where you start with an empty string, and % 3 to append 'Fizz' then % 5 to append 'Buzz'. This is also an instant pass in my book (two modulus, no calculation variables), though I don't personally care for the "coincidence" that for this specific problem the two conditions combined happen to provide the end result.
Then again it is FizzBuzz and not FizzBuzzMozz, where numbers divisible by both 3 and 5 produce a string that cannot be concatenated by the individual 3 and 5. So to be fair, this solution is perfectly valid. :p
I know exactly what you mean by the "coincidence" and how taking advantage of it seems off somehow, but I suspect the original problem was written with that solution in mind.
1. You have a dangling check for empty string at the end to set to the current number if the string is empty after the Fizz/Buzz conditions. An "else" clause disguised as an "if" clause.
2. It's just messier to understand. "If % 3, append Fizz; if % 5, append Buzz" has four different outcomes: neither matches, first matches, second matches, both match. A newcomer to the code has to mentally separate out all possibilities (which basically requires re-scanning the same code four times). Whereas the "if, elseif, elseif, else" can be read over and understood with a single scan.
Here is an implementation in Python with only one operator
# Inputs
>>> i = range(1, 100)
>>> d = [(15, 'FizzBuzz'), (5, 'Buzz'), (3, 'Fizz')]
# Let's define some lambdas - calculation, test, reduction
>>> c = lambda x, y: y[1] if (x % y[0] == 0) else x
>>> t = lambda a, b: a if type(a) is str else b
>>> r = lambda e: reduce(t, e)
# Now process
>>> map(r, map(lambda x: map(lambda f: c(x, f), d), i))
My personal preference in terms of demonstrating maintainable code is using two modulus operations with variables. However, I fully understand the argument that an additional % 15 is preferable compared to the overhead of storing two variables on each iteration. Both are valid approaches IMO, and the debate can roar on for eternity. Micro-optimizations and whatnot.
I just don't like to see four modulus operations, which IMO shows a lack of basic willingness or ability to refactor while coding. It's fine to initially write the four modulus operations, but if someone doesn't immediately catch the duplication and do something about it, it screams "I write code until it works and then move on without cleaning anything up."
Strangely enough, only once have I seen someone use the % 15 optimization and add a short comment along the lines of "// least common multiple, divisible by both 3 and 5". Spotting the optimization is nice; placing a short comment explaining why % 15 when the test is about % 5 and % 3 is a nice touch. Explains something that might not be immediately obvious to the next person coming to the code.
Aside: it astounds me how many people, when asked to write a short snippet of code during an interview, have basic formatting problems and inconsistent code style. I've seen two lines of code inside an if() block indented at different levels, with no excuse for "different opinions on formatting". Not a wrapped line continued on the next, but just two simple statements inexcusably indented at say 8 and 12 spaces. Don't call us, we'll call you...