I've started to treat live coding screening sessions as a "conversation about code." I make sure that the candidate knows that I'm trying to make sure we can discuss code.
Why?
Purely being a "good programmer" isn't just enough for the job. It's important that we can develop a good working rapport, and communicate.
For example: Someone who's an expert programmer might misinterpret a discussion and build the wrong thing; or someone might be a great programmer but otherwise be impossible to actually conduct a technical discussion.
IE, this is why "Fizzbuz"-style questions work so well: It's not really screening that you're a great programmer, it's screening your ability to have a technical discussion.
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.)
Why?
Purely being a "good programmer" isn't just enough for the job. It's important that we can develop a good working rapport, and communicate.
For example: Someone who's an expert programmer might misinterpret a discussion and build the wrong thing; or someone might be a great programmer but otherwise be impossible to actually conduct a technical discussion.
IE, this is why "Fizzbuz"-style questions work so well: It's not really screening that you're a great programmer, it's screening your ability to have a technical discussion.