Hacker News Reader

Comment by lhorie | Hacker News Reader

Yeah, I've noticed a big gap in interviewee's perception of what interviews are supposed to be like, vs what I look for when conducting an interview. Often times, I see people on reddit asking questions along the lines of "I've an interview coming up, what leetcode thing should I cram", but that really misses the picture that a good interview is nothing like a teacher marking a scantron school test.

The crazy part is that some of these interviewees even have work experience and ought to know better!

View on HN

>Yeah, I've noticed a big gap in interviewee's perception of what interviews are supposed to be like, vs what I look for when conducting an interview.

This depends on the person and company doing the interview, I think. I work as a consultant implementing a specific software package and recently interviewed with a Unicorn trying to switch to mroe general purpose coding. The difference in the process is night and day. When I do interviews with consulting firms it's almost always someone with significantly more experience than me. And they are usually pretty free flowing and in depth discussions.

The Unicorn interview was 100% checking boxes. I had 4 leetcode style coding challenges and the only thing that really mattered was solving the problem. The discussion ones were pretty obviously interviewers asking questions from a piece of paper. The only goal there was to give them something good enough to write in the box so that it would pass later review.

I agree. All of my consulting interviews have gone on tangents here, there and everywhere.. And focused more on ability to think, problem solve and be a human. Whereas engineering and software jobs are rote.

I agree that big companies have interviews that look more checkboxy since they generally want interviews to be standardized/fair for candidates, but even then, a lot of the interview is not about the solution to the problem per se. For example, if the candidate struggles with basic syntax, or if they struggle with refactoring, or they don't react to feedback well, these are all things that get considered, even if they do solve the question optimally on paper.

I had one where we solved the problem half way through the session and went on a big tangent about how to engineer a solution to a related fuzzy problem.

I do agree though that interview standardization can lead to mediocre interviewer practices if the interviewer isn't truly committed to improving their recruiting skills (which is sometimes the case if a team is on a crunch, for example).

Reply on news.ycombinator.com