I have no knowledge of your interview, but if I had been the one interviewing, and if I were to present you with a programming problem such as fizzbuzz, I, most likely wouldn't be looking for a perfect, succinct, or idiomatic solution. FizzBuzz is a problem that can be solved a number of ways. Most common solutions involve a loop, some sort of conditional, some Boolean logic, and understanding of the modulus operator. These are all things that a student in his 2nd week of his first CS course would have had exposure to. An early programming course might ask students to solve the "Making change" problem, which probably involves similar tools.

I would be looking at the process; can this candidate plan an implement an algorithm? Does this candidate know how to access the documentation for the implementation language? What approach is used for verifying the output? If there's a need for debugging, how is it handled? Does it appear this candidate has a clear and logical thought process? And afterwards, can the candidate explain his solution? Can he make good observations as to any tradeoffs he made in his algorithm? Did he code for clarity, for golf, for aesthetics, for cleverness? Were these styles intentional? How does the discussion go? Is he defensive, or open to talking about his code?

There's no single solution, and although it might be a red flag if one were to go too far out on the "cleverness" branch, being able to identify the choices made and discuss them comfortably could also win some points.

An interview is to get to know the individual while also gaining comfort that they can actually do the job. A small programming challenge is only one component of that process.