4 ms·
What’s missing from all these speculations about the best way to hire is any tracking of the applicants performance after the hire. If you showed me data that s
by gcheong 5y ago
What’s missing from all these speculations about the best way to hire is any tracking of the applicants performance after the hire. If you showed me data that said that the highest percentage of candidates that do well at the company all did well on their algorithm interview vs any other screening technique then I would be more convinced. Google claims this is the case and the industry seems to have just followed suit without questioning it. I personally think the best way is probably a short simple fizzbuzz type problem to screen out people who simply can’t code at all then a take-home or in-house coding assignment with a discussion after or (or during if in-house). If the claim that avoiding a bad hire is far better than rejecting a good candidate is to be believed then it behooves the hirer to get as much signal around something that closely resembles the actual works as possible and actually discussing the code at hand would probably eliminate most problems around cheating.
- hansvm 5y ago> behooves the hirer to get as much signal around something that closely resembles the actual works as possible Is there any reason why closely simulating the work environment should be the most efficient way to glean whether a candidate will perform well once hired?
- gcheong 5y agoI wouldn’t think it would be the most efficient but if you’re worried more about accepting a bad hire than rejecting a good one efficiency isn’t the primary metric.
- hansvm 5y agoKind of. Long, convoluted interview processes are expensive in the opportunity cost of not having the role filled and in the actual work that needs to happen to conduct the interviews. That gets weight against the (presumed large) cost of a bad hire, but hiring is expensive, and practices that slow it down across the board to reduce a few bad hires might not be worth it.