“So here are my thoughts:
"Live programming sessions can be really insightful for the interviewer and the company. As the interviewer you get immediate feedback from both the code and the body language and any conversation about thought process from the interviewee. But from the interviewee's point-of-view it can be hell. Think about it like this: they're looking for a job, trying to impress you, working on a task they've never seen and in an environment that IS NOT AKIN to how they would work normally if given the job: everyday Jira tasks aren't timed, with a proctor looking over your shoulder taking notes. We work at our leisure with Google and have colleagues to assist us. So with all that being said there are ways to make the live coding interviews less scary.
I like to re-frame the whole exercise and make it less like an exam and more like a pair-programming session. I also incorporate the idea from code-review that we review the code not the programmer, i.e: "The code here at this line is confusing or I don't think it does exactly what the algorithm suggests..." vs. "Why did you do it like this? Why is it this way?" where the latter has charged language that is accusatory and anxiety inducing.
So now that the interviewee hopefully sees me as a peer in a pair-programming scenario and I've made overtures to help them feel comfortable to ask questions and talk through their process then only do we begin.
I ask them to read the question. I ask them to ask me any questions about the question if something is not clear.
Really strong candidates often restate the question back to me and ask for confirmation if what they've understood is what I've understood. I find this a very strong indicator of success at $JOB as it means they will seek to solve the real problem and not the perceived one and thereby potentially waste engineering time on a task that was not needed.
Prior to the coding challenge part I try to do as good a job in time management as I can to allot enough time for the coding challenge. It is on the interviewer to have an understanding for how long a task should take and allot that time and some buffer.
Lastly, I like to have programming challenges that don't come from leet code or hackerrank but that come from work or tasks I have personally done before. I tell the candidates about this in the interview itself: "The SQL question you have before you today is something I worked on recently myself. This is similar to the kinds of things you'll see when working here at $JOB of course this task is just a small part of what you might work on but it is a real-world problem I've seen. Let's chat about how you will go about solving it and then why don't you write the SQL and we can tweak it together if necessary..."
And finally, the goal should be to see how the candidate thinks through things, how they ask questions to fill in gaps in understanding about tasks or technical things, and if they have the minimum level of skill to be successful at the company.”
