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?
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?
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.
Tech interviews are not solely whiteboarding. Even at FAANGs there are system design and hiring manager interviews designed to ask about those sorts of things.
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.
