Ask HN: How do you make the most of a bad interview
8 comments
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.
I wouldn't say I'm compromising the tested standards, if they can't do it I'm going to be up front about that. It's just that the expected skill level for a particular role gives candidates an amount of leeway in terms of what's considered 'sufficient'.
That said, I've considered doing what you've suggested, but I worry that comes off too obviously as having given up. I also can't always speak to the expectations of the particular role because it's often not on my team (or department in some cases). There's been times where I have cut the interview short and done something similar, but I'm hesitant to try that on a particularly bad candidate, because I worry I wouldn't be able to stay away from asking how much of their resume is a lie.
That said, I've considered doing what you've suggested, but I worry that comes off too obviously as having given up. I also can't always speak to the expectations of the particular role because it's often not on my team (or department in some cases). There's been times where I have cut the interview short and done something similar, but I'm hesitant to try that on a particularly bad candidate, because I worry I wouldn't be able to stay away from asking how much of their resume is a lie.
the smugness
I take the opposite approach and almost always finish the full interview. They took the time out of their day to do this and it at least gives them practice. It also leaves the company you're repping in a better light imo
Just end the interview early: why waste their time and yours?
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.
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.
This doesn't really seem like an option; normally I'm just one of a series of interviews and I can't just hand them off to the next person.
The goal of an interview is simply to identify the skills / personality of applicant. I have a role in mind when I am interviewing someone, but if their skills do not support this but it feels like there may be a good match at another team (at the right price) then I start feeling them out to see if that could be a match for them.
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.
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.
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
I would never ask leetcode questions that have some trick to them. These are ones we've come up with internally and are incredibly straightforward.
i was in a FAANG interview where i was asked such a question that was internal and straightforward. the person assumed that the way they were doing this, was common industry practice. however, i have been in that particular specialization they were interviewing me for for a good 20 years and never heard of a company doing it that way. i am quite sure that the person mistakely assumed that because his FAANG did it that way, it must be industry practice.
normally I'm just one of a series of interviews and I can't just hand them off to the next person
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.
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.
It has happened to me. Sometimes you are tired at times the question/solution doesn't click immediately.
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.
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.
I could try this. I can't really leave since the interviews are all done over zoom now, but I could ask the candidate if they'd like a few minutes without my camera or mic on.
>to people who explicitly say they don't know how to write code and spend the entire 45 minutes in an awkward struggle session
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?
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?
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.
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.
i wish i had an interviewer like you back when i was still in the industry. i might have stayed.
What are you doing now?
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.