I think that's a good approach. I can write FizzBuzz in 4 different programming styles, in at least 3 different programming languages, and I'd be happy to talk about all 12 permutations of them.
It's important to avoid well-known questions where the candidate can present a memorized answer. When the candidate has memorized the answer in advance, it's not a conversation, it's a presentation.
Likewise, I'm not looking for the candidate to show off. To be very specific, I'm trying to gauge two things:
1: The candidate's ability to problem solve around a set of immutable constraints.
2: The candidate's ability to listen.
The above pretty much go hand-in-hand: Someone might be able memorize "all 12 permutations" of Fizzbuzz; but can they comprehend the constraints in a discussion and intelligently discuss tradeoffs?
A different way to say it: It might take me 2 minutes to explain a problem. If the candidate only listens to the first 10 seconds, it shows, and demonstrates that they will be difficult, if not impossible, to work with.
(There's usually very predictable mistakes that I've anticipated. For example, one question I used in the past I would explicitly say, "do not worry about multithreading," and some candidates would still including locking.)
