3 ms·

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

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.