Hacker News new | past | comments | ask | show | jobs | submit login

So have them explain it to you after they complete the problem with you out of the room.



If I’m in the room, I will steer them away from dead ends and ask leading questions when they get stuck. The point of the interview is to give the interviewee as much of a chance as possible to demonstrate their skills.

I’ll say for sure, not everyone interviews this way. A lot of devs running interviews think of it as a “test” with pass/fail. I’d say the better interviewers see it as an opportunity to dig around and figure out how to get evidence of the candidate’s skills. That means being creative, that means responding to what the candidate says and finding opportunities to focus on their strengths.


The problem is that there's lack of transparency in the process. Candidates don't know the "real" rubric that interviewers use, so anxiety could make the situation far more antagonistic than it is. And to some point, it is inherently antagonistic; the interviewee is being judged, vulnerable to being rejected, by someone who may or may not be unfair. So the anxiety ratchets up. This can lead to all sorts of bad behaviors like candidates not asking questions for fear of revealing ignorance or looking stupid. And a lot of interviewers as you say, especially at the top firms, don't really care about "how a candidate thinks" at all; they want to see correctness, they want to see efficiency, they want to see whiteboard code that can compile.

I don't think this necessarily means the "answer question alone and present answer after" approach is the right solution to interviewing, but it does show that interviewers might need to take some steps to make the process less opaque and daunting to lower candidates' potential anxiety.


> And a lot of interviewers as you say, especially at the top firms, don't really care about "how a candidate thinks" at all;

From my direct knowledge of some “top firms”, if you only cared about correctness then you wouldn’t be able to fill out the interview feedback form.

Transparency may help, but in my experience, that’s what recruiters actually do and some of them are fairly good at it. The recruiter has a strong incentive to get you hired (they get bonuses for hiring people!) and will explain as much of the process as they can, if you are willing to listen.

That said, there seems to be a fair bit of turnover in tech recruiting.

And, as you said, every interviewer will be different. But I don’t see a way to fix that without eliminating technical interviews altogether. You are being judged, the interviewers are subjective, they do disagree about the rubric, and a bunch of money is on the line. It’s completely reasonable to be anxious. I don’t really see a way out.


> And, as you said, every interviewer will be different. But I don’t see a way to fix that without eliminating technical interviews altogether. You are being judged, the interviewers are subjective, they do disagree about the rubric, and a bunch of money is on the line. It’s completely reasonable to be anxious. I don’t really see a way out.

Perhaps what we should be working towards is making it more transparent- it's still ubiquitous for candidates to be rejected without feedback- and more objective, and improving the technical interview process further. I'm not arguing for throwing out the baby with the bathwater.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: