The interviewer should ask the candidate, in the candidate's own words, to walk through solving a problem proposed by the interviewer. No whiteboard. Just a simple conversation. The candidate must be provided the opportunity to organize their thoughts with notes on paper and have a short pause of time to think through an answer.
Problem solving is a fairly universal thought experience not limited to writing code. The goal is to ascertain whether the candidate can break down the complexity of a problem into simple steps, organize their thoughts into a clear flow, communicate clearly, and finally recommend a valid solution.
You don't need to test whether the candidate can actually write code, because this is built into the nature of the exercise as qualified by the feasibility of the proposed solution. This exercise also implicitly tests confidence, creativity, experience, and approach style.
Most importantly though, it separates the competent from the incompetent. No amount of framework foolishness and dependency baggage will communicate a solution for you.
I've interviewed many folks over the years who talk the talk and just simply ace problem solving, but they can't write a unit test in their preferred language.
I strongly second this approach. I would also check some code but only as a tie breaker. I've seen people writing such messy code with useless random variable names, inconsistent style, etc. That can be fixed. Attitude at problem solving is harder to teach.
Problem solving is a fairly universal thought experience not limited to writing code. The goal is to ascertain whether the candidate can break down the complexity of a problem into simple steps, organize their thoughts into a clear flow, communicate clearly, and finally recommend a valid solution.
You don't need to test whether the candidate can actually write code, because this is built into the nature of the exercise as qualified by the feasibility of the proposed solution. This exercise also implicitly tests confidence, creativity, experience, and approach style.
Most importantly though, it separates the competent from the incompetent. No amount of framework foolishness and dependency baggage will communicate a solution for you.