8 ms·

Hot take: I like leetcode-style interviews and I've spent a lot of time in them on both sides of the fence (tens of hours as a candidate, hundreds as an intervi

Hot take: I like leetcode-style interviews and I've spent a lot of time in them on both sides of the fence (tens of hours as a candidate, hundreds as an interviewer). > But yet, these interviews quiz me on things that I can easily Google that I may not know off the top of my head. It’s absurd. I don't work at Google so I'm lucky to have freedom in the way I interview engineers and usually I try to squeeze out the quiz aspect as much as possible. If a candidate doesn't know the algorithm for a given problem and can't quickly come up with one, I usually proceed to give a detailed explanation for it. In the end the task is reduced to "write between 6 and 10 lines of code that do X in your favorite language" and yet a majority (80-90%) of inbound candidates for software engineering fail at it (for non-inbound sources a picture can be very different of course). Contrary to a common view, I believe that this approach actually imitates my daily interactions with a developer quite well and the correlation between interview performance and job performance is very strong in my experience. And interestingly I've seen many people who shine in oral interviews (tell me about your experience) and then fail to produce any code at all, both during the interview and at work. So even if I wanted a good alternative approach to hiring of engineers I haven't seen it so far.

radicalbyte 2y ago
I like giving SWEs small coding problems but it's more of a filter against: a) The 90% of applicants who literally cannot code. Although I filter out 99.9% of those by screening CVs and a short telephone interview. b) They can be a point for more discussion. It's silly to give someone, in an interview setting, an exam question style problem and to make that a key factor in the interview. It's up there with giving someone tasks which could potentially take them an evening just for an interview. I've tried everything and I've had the best results by talking, digging into the details. Not only do you get a better idea of the person but it's really easy to rat out those who are less capable (especially those who've studied hard for exam questions but fail at everything else).
- alexey-salmin 2y ago
  > I've tried everything and I've had the best results by talking, digging into the details. That's always the second interview I do: "tell me about your favorite project", then asking questions about details, possible alternatives and pros/cons, fundamental limitations, anticipated issues, real production issues, etc etc, going as deep as possible. This works really well and filters out people who do leetcode but don't pay attention to details in their work or have no real experience (if you're looking for one). However, the couple of times I hired people who nailed this part but failed the coding, they also failed at coding at work. So both interviews are necessary in my opinion.
cherryteastain 2y ago
As an interviewer, what you do seems to make sense and I do similar interviews. Removing the pressure of memorizing leetcode question algorithms (yes almost everyone has to memorize for leetcode hard to solve <1hr, most will need to memorize for medium) puts both sides in a better mood. I also observed starting a process with easier questions still filters out the bad candidates (80%+). Once a candidate 3-4 rounds more open ended questions seem to be much more discriminative anyway.

radicalbyte 2y ago

I like giving SWEs small coding problems but it's more of a filter against: a) The 90% of applicants who literally cannot code. Although I filter out 99.9% of those by screening CVs and a short telephone interview. b) They can be a point for more discussion. It's silly to give someone, in an interview setting, an exam question style problem and to make that a key factor in the interview. It's up there with giving someone tasks which could potentially take them an evening just for an interview. I've tried everything and I've had the best results by talking, digging into the details. Not only do you get a better idea of the person but it's really easy to rat out those who are less capable (especially those who've studied hard for exam questions but fail at everything else).

alexey-salmin 2y ago
> I've tried everything and I've had the best results by talking, digging into the details. That's always the second interview I do: "tell me about your favorite project", then asking questions about details, possible alternatives and pros/cons, fundamental limitations, anticipated issues, real production issues, etc etc, going as deep as possible. This works really well and filters out people who do leetcode but don't pay attention to details in their work or have no real experience (if you're looking for one). However, the couple of times I hired people who nailed this part but failed the coding, they also failed at coding at work. So both interviews are necessary in my opinion.

cherryteastain 2y ago

As an interviewer, what you do seems to make sense and I do similar interviews. Removing the pressure of memorizing leetcode question algorithms (yes almost everyone has to memorize for leetcode hard to solve <1hr, most will need to memorize for medium) puts both sides in a better mood. I also observed starting a process with easier questions still filters out the bad candidates (80%+). Once a candidate 3-4 rounds more open ended questions seem to be much more discriminative anyway.