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.
It's similar to making a decision to fire someone: if you have a suspicion that someone won't work out, probably best to just immediately cut them. Don't think I've ever seen anyone in my entire career come back from poor performance unless it's due to unique / temporary life circumstances.
If their price is too high for their skills and/or I do not have a match, I politely but firmly end the interview. Be polite, wish them the best, but don't waste their time. Its the only way I can show respect to them - they have a hard path to travel.
I think that's a sign right there that you need a phone screening stage before you bring a candidate in and tie up a whole day of your team's time.
It can be an informal 15-30 minute conversation but it should be someone technical performing the screen, not an HR type. Take 5 minutes to explain the role. Then confirm the matching capabilities on their resume and previous jobs and begin to ask some precise questions about how they used them. You can even ask some simple questions. What's a join? What does vacuum do?
You're not asking brain teasers but you're putting a very heavy bullshit filter on their responses. It shouldn't be hard to figure out who is really capable and those that have never written a lick of code. You'll also catch people that can't communicate technical ideas to a stranger, which is typically a red flag for me as well.
At those times I wish the interviewer would leave for a few minutes so I could focus completely and grasp the problem and get started. The observer effect of watching and trying to hold a conversation breaks focus.
If it's important to you to find people who can write code, why are you even interviewing people who "explicitly say they don't know how to write code"? And if you interview them, why are you interviewing them in the same way as people who can write code? And if you interview them, why are you keeping them for 45 minutes on the struggle bus instead of interviewing in a manner they might actually succeed in?
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.