4 ms·

Well, the problem is in the Typical Man Month. 10x as many 1x developers will deliver a worse product on a longer schedule than 1x as many 10x developers. Even

• bdavisx 6y ago
  I completely agree with your premise on the 10x developer in concept (although what 10x means is up for debate). I agree with the fact that a team of "good" developers will outperform a team of <good developers, by a huge amount, in many different ways - quality, features, ux, etc. The issue is, whiteboarding people on trivia programming problems doesn't determine if they are a 10x/good developer - it only determines if they understand the particular trivia they are asked.
  • kenhwang 6y ago
    The problem is having people conduct whiteboard interviews without actually understanding what the whiteboard interview is looking for. 10x engineers tend to be force multipliers not because of their technical skills, it's due to their excellent soft skills (communication/leadership). Because organizational communication problems increase cost exponentially, so decreasing communication overhead is far better returns than a slightly better technical implementation. So you have all these people running these interviews focusing on the problem being asked when in reality, the solution to the problem is mostly irrelevant.
  • wegs 6y ago
    Well, no. My experience is that the technical interview is a noisy fizz-buzz. Good developers need to know algorithms and data structures, and be able to write code. If they can't even do that, they're definitely NOT a 10x'er. If they can, the next part is fit. You need to get over both bars to be hired. All of this is incredibly noisy, so part of what happens is you have to set the bar high, since 37% of the people you interview will perform one std. div. above where they actually are, and 5% will perform 2 std. div. above where they actually are. Setting a high bar means you lose a lot of good people due to random error. But the costs of one bad hire are EXTREME compared to missing a few good hires. So it makes sense to do that. People take rejections personally, but in most interview processes, it's pretty random. You have a bar. You hire people who interview 1-2 std. div. above that bar. You might be perfectly qualified, and I won't hire you if you had a bad day (or even an average day). The risk is too high. If you're 1 std. div. above, I'm moderately confident you're qualified. If you're 2 std. div. above, I'm very confident. And having hired people, that's how it plays out: I mostly hire people who interviewed well, and their performance on a typical day is typically lower than at the interview (not always, but usually). Hiring is about finding and bringing in good people as efficiently as possible. I'd rather interview 20 people, hire two I'm confident are good (miss six qualified people among those 20 who had bad days), than I would bring in 10 people and hire two of them. And bad people still slip in. You just can't do that much in an 8 hour interview. For startups, I go for personal recs and github repos. Does that mean I miss people who aren't in my network, and who don't do open source? Of course. But that's okay. I still find enough really good people that way. (And yes, my network IS diverse, thank you very much). But big companies need standardized processes, or things get rife with discrimination, nepotism, and all sorts of other nastiness. That easy to avoid small-scale, but with 1000 employees, it takes one bad apple to land on front page NY Times.
    • oxfordmale 6y ago
      Your approach suffers from regression to the mean. You would hire someone who happens to do very well on the interview, likely someone who thrives on an adrenaline rush.