FWIW, I prefer the "grit" solutions. No modulo, no faking/implementing modulo. Why?
Because the original child's game isn't about "If a number is divisible by X," it's about "Every Xth number." And directly implementing "every Xth" can be interesting.
This is all good, until someone in Product changes the requirements. Now instead of 3 and 5 they need 7 and 11.
All these clever tricks will require a complete re-write and re-test. And since the company decided to pick theit employees based on how they answer these tricky interview questions, the code base is full of opaque idiosyncrasies with unexpected dependencies. Four sprints later, the code is put into production and some other part breaks, causing the company millions.
The pleasure of solving eccentric problems is, of course, a completely separate thing from the question of, "What is the efficacy of asking job candidates to solve well-known programming puzzles?"
When nobody had heard of fizzbuzz, it had a certain value for screening out complete no-hopers when no other signal was available. There were other methods for achieving such a goal, but it had some utility.
Today, using it for job screening it acts like a membership test. "Hey! Are you a member of the programming culture? Have you scoured the internet for examples of problems posed in job interviews? Prove it! Write fizzbuzz!"
There's another thing about your comment. I suggest you reflect on this:
If you believe that someone who solves fizzbuzz in an idiosyncratic way would also do everything at work in an idiosyncratic way, you are essentially supporting the value of asking programmers to solve programming problems in job interviews.
I have a different belief. I have written a blog post on the subject, but the TL;DR is that the purpose of this kind of test is strictly to get rid of impostors whoc an't do any programming whatsoever.
The moment you are convinced that they are not a complete no-hoper, you can stop the test and get on with teh real interview.
As such, I believe it is harmful to take anything other than a single bit of information from it: Can/Can't.
If you actually study how they got it to work, and make extrapolations about them from it, you are incentivizing people to write millions of units tests, ask you whether there is a roadmap for future changes, set up a repo on github and submit their solution as a PR, &c. &c.
If that's what you want to know about a candidate, fizzbuzz is a ridiculously inadequate test.
Because the original child's game isn't about "If a number is divisible by X," it's about "Every Xth number." And directly implementing "every Xth" can be interesting.