I can't see how your approach can scale to hire tens or maybe hundreds of engineers.
Sounds like something that may somewhat work for you when you're the only one doing the hiring for your small team of buddies at a startup somewhere.
You're not even trying to tackle things like hiring for multiple roles, interview fairness, subconscious bias, technical diversity, feedback, or making the interview process accessible to a larger group of people that don't fit your cookie-cutter from the get go.
On a different note - I really hate the tone of your post. You come off as an arrogant person who's full of it and "has it all figured out". I'd easily pass on you just by reading these posts.
[1] and if these problems are unrelated (think Uber's human driver app vs self driving), then why are candidates passing through the same committee?
Mature products require competence in areas such as security, architecture, compliance, devops, research and much more. Hiring has to reflect that and account for it.
It's silly and immature to suggest a 90-minute chat about some crap your candidate will bring with them is somehow the answer here (and claiming that if they don't have anything to bring with them, then chances are that they're worthless anyways and you shouldn't waste your time on them). Especially without backing this up with any meaningful data (ie. attrition, number of people hired, actual impact on business, feedback received, etc).
> Sorry to be blunt, but chances are they aren't very good, and they are definitely not as good as they think they are.
I don’t know what to tell you.
It’s just so wrong it’s kinda wild how sure you are about this. At least half of the excellent colleagues I worked with in the past 10 years don’t fit your criteria. You’d be lucky to hire any of them.
We could dissect the entire thing but really, if that is how it works for you, fine. Just don't push it onto others as the absolute truth. If this stuff was really so great, empirical research would've hammered it home decades ago. But it doesn't, and continues to struggle finding any meaningful correlations between these "whacky fun strategies" and actual job performance.
1. Companies want to standardize their hiring when really they should be looking to customize it to each candidate.
2. Lots of companies want to spread the blame of a bad hire across a committee of 4 or 5 people, but I think if you looked you'll find many startups doing it this way. They stop when they grow to a large size. They do it because frankly hiring good engineers is no longer the top priority (it's typically quotas AKA butts in seats).
Again with the awkward appeal to authority.
Cut straight to it. Your post's title is "how to hire actually good engineers". So how many of those have you actually hired? How many of them stayed there 2 years into their roles? How do you know you've actually hired "good" engineers, and not just people you yourself thought were good enough at the time you interviewed and hired them? Have you actually followed up on your hires 3/6/12 months into their roles, to check that they're still as good as you thought they were?
By the way - "$1M+" sounds like a particularly low budget for "actually good engineers", ironically enough.
which was on top of a false dilemma to begin with
amazing
I get that the logical move is to get defensive, but just consider introspection
> Sorry to be blunt, but chances are they aren't very good, and they are definitely not as good as they think they are.
and there it is, one of the other subthreads is making fun of this kind of employer that swear by showing code
this is a false attribution bias where you decided not to notice that every evaluation technique the entire industry figured out will mostly by filled with people that cant code
your technique is simple no better
Is there a typo? The sentence doesn't make sense to me
The industry tries them all
Its the wrong conclusion on the efficacy of the technique
Posted this on behalf of the silent majority that likes the approach.
