The way I structure my coding interviews is to have a simple first question that anyone should be able to solve, and then a follow-up "ok, let's now add this feature" question. I tell them upfront that googling is ok and give hints whenever I notice they are stuck. At the end of the first half, I ask if there's anything about their code that they'd like to change - basically a chance to code review. It tells me a lot about not just technical chops, but also awareness of what good practices are, as well as whether they are proactive and have an eye for quality.
The second half is the brownie points session: it's where the candidate gets a chance to demonstrate that they're better than average, be it by demonstrating strong algorithmic thinking, or good refactoring and/or testing practices or what have you. Good candidates ace questions on multiple dimensions and it's pretty easy to spot a gold nugget.
When the candidate doesn't meet the bar at this point, it becomes geared towards looking for growth potential (as far as me collecting signals go) and being an opportunity for learning for the candidate. It can be me giving feedback about types of things they could take into further consideration or, for less qualified candidates, a discussion of how to formulate an algorithmic idea, either in terms of thinking from first principles, or in terms of erasing dissonance between abstract ideas vs how to express them in code.
I try to always pace feedback in such a way that by the end of the hour, the candidate has completed the exercise. Sometimes, that does mean that I'm literally walking them through the process of coming up with the solution. Some think this is a waste of time, but IMHO, it's important for the candidate to leave with a good impression of the interview process. If a session is a complete bust and a waste of my time, then at the very least the candidate should be getting something out of it.
The second half is the brownie points session: it's where the candidate gets a chance to demonstrate that they're better than average, be it by demonstrating strong algorithmic thinking, or good refactoring and/or testing practices or what have you. Good candidates ace questions on multiple dimensions and it's pretty easy to spot a gold nugget.
When the candidate doesn't meet the bar at this point, it becomes geared towards looking for growth potential (as far as me collecting signals go) and being an opportunity for learning for the candidate. It can be me giving feedback about types of things they could take into further consideration or, for less qualified candidates, a discussion of how to formulate an algorithmic idea, either in terms of thinking from first principles, or in terms of erasing dissonance between abstract ideas vs how to express them in code.
I try to always pace feedback in such a way that by the end of the hour, the candidate has completed the exercise. Sometimes, that does mean that I'm literally walking them through the process of coming up with the solution. Some think this is a waste of time, but IMHO, it's important for the candidate to leave with a good impression of the interview process. If a session is a complete bust and a waste of my time, then at the very least the candidate should be getting something out of it.