7 ms·

These processes are optimized to reduce false positives not false negatives. So they already know that they might be missing on some great developers.

• theptip 8y ago
  This is the correct explanation; false positives are so much more expensive than the opportunity cost of a false negative.
  • malvosenior 8y ago
    People always say this, but is it true? It’s easy to fire someone. It’s really hard to find someone who can ship (something you won’t get from a whiteboarding challenge).
    • etse 8y ago
      Seems costly to fire, not just because of HR and management process overhead. People are trying to build successful teams, and regular firings distract from goals, ruin morale, and create an unsafe environment.
      • vonmoltke 8y ago
        Regular firings imply a pretty bad hiring process. There's a spectrum between "regularly fire bad hires" and "regularly reject good hires". Also, what evidence is there that these high-false-negative practices are actually reducing false positives by a significant degree? In these kind of threads I read the same arguments and assertions, with the same lack of evidence, as I hear from people trying to defend airport security theater. I should start calling these practices "interview theater".
    • rockinghigh 8y ago
      Engineers who don’t perform well for extended periods of time tend to drain resources from the rest of the team. They require active management; laborious code reviews, they also introduce more bugs and contribute to less robust designs. As for firing, it is a painful process for a manager as it comes with a variety of liabilities and HR involvement.
    • theptip 8y ago
      > is it true? In my experience (hired 10 engineers), yes. It's technically easy to fire people, but it's emotionally draining on the team and on the manager in particular. Every time you fire someone, the team's morale takes a hit, and if you were firing people often, folks would begin to feel insecure and you'd struggle to keep good engineers. Smart, good people want to work with other smart, good people. If you're constantly bringing in bad hires (even if you later fire them) then your good engineers will get fed up and leave. The net value of a bad hire can easily be negative, if you consider the high onboarding costs to get a new engineer ramped up and trained. (Of course, the very best engineers basically sit down and start coding as well as your existing good engineers, but these true outliers are by definition uncommon). Not to mention the cost of the bugs and rework that bad hires produce. If you use a recruiter, you're typically paying a large fee that you can get refunded after N months (details vary, 3 seems common), so you'd have to be making your assessment in the first N months; that's a lot better than trying to make an opinion on the first day, so if all of the above wasn't true, in the abstract, it would be great to be able to hire aggressively and fire likewise. However, good engineers balk at the concept of a "trial hire"; understandably, as personally I'd refuse to work somewhere that didn't have conviction that they wanted to keep me. I imagine the relative significance of these points varies between companies and stages; all of these points are from early-stage (<25 person company) startup life; YMMV. > (something you won’t get from a whiteboarding challenge). I agree with this point, though I think it's orthogonal to the question of false positive vs. false negative cost optimization.
  • ashelmire 8y ago
    You think people that pass technical interviews can’t be false positives? I think they weed out a few, but completely ignore practical development skills, work ethic, soft skills, design and architecture skills, etc. Of course maybe this explains why most of the big tech companies have seemed pretty stagnant for the last decade, largely failing with products and decisions that have poor execution and market fit outside of the products that made them big in the first place. Has anyone actually studied the best way to hire devs? Like a real, independent study that measured and compared results across, perhaps, a wide array of metrics?
    • rifung 8y ago
      > Has anyone actually studied the best way to hire devs? Like a real, independent study that measured and compared results across, perhaps, a wide array of metrics? I don't know how you would ever strive to do such a thing when people can't even agree how to measure productivity. > Of course maybe this explains why most of the big tech companies have seemed pretty stagnant for the last decade, largely failing with products and decisions that have poor execution and market fit outside of the products that made them big in the first place. In most large companies these things have nothing to do with programmers; the decisions are made by management and products are designed by PMs. Hell, you can't even necessarily blame buggy products on programmers: I've been on projects where everyone realizes things suck but if you don't get funding or agreement to work on infrastructure projects what can you do?
    • saagarjha 8y ago
      > I think they weed out a few, but completely ignore practical development skills, work ethic, soft skills, design and architecture skills, etc. This is the whole point of the non-coding portion of the interview, and while it’s not possible to get a full picture of this in the short amount of time allotted, it is generally enough to throw out the obvious ones. > maybe this explains why most of the big tech companies have seemed pretty stagnant for the last decade, largely failing with products and decisions that have poor execution and market fit outside of the products that made them big in the first place I think this is unrelated to hiring and more a result of corporate policy.
    • 8y ago
  • ummonk 8y ago
    Sure, but then they shouldn't turn around and constantly keep complaining about a shortage of tech talent.