Ask HN: How do you make the most of a bad interview

Context: I do technical interviews for various roles at my company. The interview lasts 45 minutes and I primarily test people on their data modeling and SQL skills, though sometimes I ask some easy scripting questions if it's more relevant. The questions aren't particularly challenging, unless you don't know SQL/programming.

I've been doing these interviews for 3-4 years now, and have seen a wide spectrum of candidates from people who finish everything in 15 minutes, to people who maybe don't know all the syntax but can talk me through their reasoning and get to a solution with coaching, to people who explicitly say they don't know how to write code and spend the entire 45 minutes in an awkward struggle session.

It's that bottom half that I'm looking for advice on how to make the most of the interview time. I don't want the candidates to feel like it's been a complete waste of time, and if I can get them to show me that they can share their thought process and learn something, it can push them from a hard no to a soft no or even a soft yes (depending on the position). I'm not a huge fan of these types of white board interviews so I will always give them answers on correct syntax if they can tell me what they want a line to do (and generally act like a knowledge base because there's never an instance in real life where you wouldn't have any of this info available to you). What are some techniques you've found effective when candidates are struggling? When do you stop giving hints and start to give portions of the answer?

Some things I've been doing are In general: - If it's been silent for more than a minute, and the candidate hasn't said or typed anything, asking what they're thinking about - Asking them to explain what they want to accomplish in a normal sentence, and then hopefully pseudocode - Regularly making sure they've understood the question.

Data modeling and SQL: - Making up example data based off the schema they've come up with and posing situations where their model would have issues - Giving example result sets based on the query they've written vs what I've asked for - Giving example data and asking for a query that would return something similar.

Scripting: - Giving counterexamples that don't work with their solution - Walking through their solution with said examples and pointing out the step it fails on - When time starts to run out, giving them a piece of the solution that's been tripping them up the most and seeing if they can move on from there.

When candidates are clearly unable to finish the interview problems even with hints and help, I conclude the technical interview early and transition to an informal discussion of their career, progress, and goals. I don’t think it’s worth compromising your technical interview standards just because you like a candidate. You have those standards for a reason. However, having a friendly conversation with the candidate can at least leave them on good terms and can give them an opportunity to get some light feedback on what’s expected from the job and where they can go to learn it.

What are you doing now?

the goal of an interview, apparently, is to see to what extent the applicant was willing to repeatedly grind the same leetcode problems over and over again and memorize their solutions

It sounds like a good opportunity to just mentor them. I've messed up some interviews, and what I did was ask the interviewer to walk me through the solution. The best was an interview for a game developer (which I have no formal education for) and learning about applying the Monte Carlo effect to figure out where civilizations were.

You guys have already committed the time to the interview, so there's no added cost. I think it's fine for the candidate to give up when they just can't do it. Doesn't mean they can't learn from the process.