6 ms·

>> >> You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. >> Fine. I know this. Will this give me a

>> >> You should know what a binary search tree. You probably don't need to know the specifics of how to balance one. >> Fine. I know this. Will this give me a job? No No, it's not about knowledge. The knowledge is needed. But the real focus of the interview is to tackle a new question. >> I want to be hired for the skills I'm bringing in and not for my ability to solve toy problems on a whiteboard. The ability to see a hard problem, develop your own solution, and translate that into code is a pretty important skill. "Skills" aren't all about knowledge. >> If the interviewer cannot filter out bullshitters, the interviewer is incapable of the "job of interviewing". Maybe hire better interviewers. Why is the burden on the candidate? It's a lot more complex than that. It's not just about filtering out bullshitters. It's also about identifying people who might be great but are unable to talk about it. There's also lots of people who are great but haven't been in situations where they've been able to tackle interesting challenges (either because of their inexperience, industry, etc). Or maybe they've done interesting things but in a related field that's hard to understand. But, yes, absolutely train interviewers. (Interviewing isn't really a role that you hire for.) But even a very well trained interviewer might not be very effective in a behavioral interview. >> I agree with this, only so long as the interviewers don't fret about some stupid edge case. Why is there an expectation of perfect code in 15 mins on a whiteboard? Who does that in production? There generally isn't. What an interviewer should be looking at is not some sort of percent correct element. It's about signal. So if a candidate is totally unable to understand an obvious, that might worry me. The signal the candidate is sending is a poor understanding of details. (Or, maybe not. It depends on the situation.) What I train interviewers on is that correctness in and of itself is not relevant. Why a candidate was correct or incorrect might be. >> The interviewer knows about these edge cases because they've seen the problem before. But I can guarantee that the same interviewer would not be able to 'perfectly' solve some problems that I pose them without having seen them before. The interviewer is comparing the candidate to other candidates on the same question. So if a candidate is getting rejected because they failed to be perfect, this means that other candidates are actually getting to perfect solutions. Or you just have a crappy interviewer who rejects everyone. >> Which brings me back to the question. What is the point of the coding interview (or perfection in coding interview) if the only people who can solve them are the ones who have seen the problem before? If that's the case? Nothing. But that's not the case.

dang 9y ago
Thank you for being so patient with some of the more ornery commenters in this thread. It's a topic that cuts close to the bone for many HN users, that frequently brings up feelings of rejection (e.g. elitism of 'top' companies) and frustration (e.g. irrationality of interview processes).
NTDF9 9y ago
>> No, it's not about knowledge. The knowledge is needed. But the real focus of the interview is to tackle a new question. >>There generally isn't. What an interviewer should be looking at is not some sort of percent correct element. It's about signal. So if a candidate is totally unable to understand an obvious, that might worry me. The signal the candidate is sending is a poor understanding of details. (Or, maybe not. It depends on the situation.) What I train interviewers on is that correctness in and of itself is not relevant. Why a candidate was correct or incorrect might be. This would be great if interviewers actually knew that this is what they are testing for. At this point, interviewers simply do not care about candidates and make a binary Yes/No decision based on "Did the candidate solve the problem perfectly in 15 mins". I'm not opposed to coding interviews. But I am opposed to the way it is implemented right now. The current way would be great if I get to reverse interview the interviewer and prove that I know (knowledge plus problem solving ability) better than the interviewer. If the interviewer accepts this duel, it's fair game. Otherwise, the current process simply selects the people who can pattern match.
- gaylemcd 9y ago
  Yeah, there are interviewers who run crappy interviews. This is not a flaw with the process though. If you replace it with any other process, you're going to find interviewers who are bad at evaluating those too. For example, on behavioral questions, I've seen many interviewers who think "In our company, we handle disagreements by doing X. So I'm going to see if, when the candidate hit a disagreement, they handled it by doing this." But that's not right. Different companies have different cultures. What's good in one company is bad in another. This is essentially the behavioral question equivalent of the scenario you're raising for technical interviews -- people looking for particular answers, and not considering the context. Both situations definitely happen, and are very common. But that doesn't make the process flawed. It generally means that the company hasn't adequately trained interviewers.

dang 9y ago

Thank you for being so patient with some of the more ornery commenters in this thread. It's a topic that cuts close to the bone for many HN users, that frequently brings up feelings of rejection (e.g. elitism of 'top' companies) and frustration (e.g. irrationality of interview processes).

NTDF9 9y ago

>> No, it's not about knowledge. The knowledge is needed. But the real focus of the interview is to tackle a new question. >>There generally isn't. What an interviewer should be looking at is not some sort of percent correct element. It's about signal. So if a candidate is totally unable to understand an obvious, that might worry me. The signal the candidate is sending is a poor understanding of details. (Or, maybe not. It depends on the situation.) What I train interviewers on is that correctness in and of itself is not relevant. Why a candidate was correct or incorrect might be. This would be great if interviewers actually knew that this is what they are testing for. At this point, interviewers simply do not care about candidates and make a binary Yes/No decision based on "Did the candidate solve the problem perfectly in 15 mins". I'm not opposed to coding interviews. But I am opposed to the way it is implemented right now. The current way would be great if I get to reverse interview the interviewer and prove that I know (knowledge plus problem solving ability) better than the interviewer. If the interviewer accepts this duel, it's fair game. Otherwise, the current process simply selects the people who can pattern match.

gaylemcd 9y ago
Yeah, there are interviewers who run crappy interviews. This is not a flaw with the process though. If you replace it with any other process, you're going to find interviewers who are bad at evaluating those too. For example, on behavioral questions, I've seen many interviewers who think "In our company, we handle disagreements by doing X. So I'm going to see if, when the candidate hit a disagreement, they handled it by doing this." But that's not right. Different companies have different cultures. What's good in one company is bad in another. This is essentially the behavioral question equivalent of the scenario you're raising for technical interviews -- people looking for particular answers, and not considering the context. Both situations definitely happen, and are very common. But that doesn't make the process flawed. It generally means that the company hasn't adequately trained interviewers.