if !multiple_of_3(i) && !multiple_of_5(i)
output = i
edit: In order to avoid overwriting output, the solution should read... if !multiple_of_3(i) && !multiple_of_5(i)
output << i if !multiple_of_3(i) && !multiple_of_5(i)
output = i
edit: In order to avoid overwriting output, the solution should read... if !multiple_of_3(i) && !multiple_of_5(i)
output << iIf you get "close enough" on paper and pencil under the pressure of an interview, that's great. You can walk through debugging it if you want to see more, but I wouldn't hold even basic logic errors against someone.
I certainly admit that when coding on my own I usually get all kinds of stuff wrong that I fix as I write tests and iterate.
The results were quite frankly a disaster, no better than what Joey found (though I didn't do enough interviews for a statistical sample).
Unfortunately my limited observations have lead me to believe that too many developers (particularly in the enterprise environments) are used to working on legacy codebases that they hack and change until the bug they are fixing goes away. Many rarely implement features much, if at all, and the ones they do are heavily broken.
To my surprise, the candidates' solutions were either bang-on or way off. The guy who asked "Do you think I should use a loop?" had to be cut off at the ten-minute mark, and his paper had only the start of a C-syntax for loop and a lot fo scratched-out lines.
Admittedly, having a variable that contains either an integer or a string is atrocious programming style, but some people do actually like languages that allow that, so it is par for the course in the given situation.
No. Though output << i.to_s will produce the same result, his code is correct. And yours isn't if you do output << i
1. If not a multiple of 3 or 5 or 15, output = i.
2. If a multiple of 3, output << fizz.
3. If a multiple of 5, output << buzz
4. If a multiple of 15, "fizzbuzz". Already covered in 2 and 3 owing to <<
Apparently people mess up fizzbuzz even when they know it:)
In each loop, he initializes the output variable to an empty string. If the current integer is not a multiple, he replaces the empty string with the integer. If it is a multiple, he doesn't know which one it is, or if it's a multiple of both, so he appends the text to the existing string variable. At the end of the loop, the string is output.
Since the `output = i` line is the only assignment that occurs when that condition (not a multiple of either) is met, it makes sense to just reassign the variable rather than append to it. It might be less flexible, sure, but flexibility isn't required here.
"" << 0x41 # => "A"If the number is not multiple of 3 or 5, you must output the number. That's what is he doing.
He prints output at the end of each iteration, setting it to empty string at the beginning.