You do you.

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.

If you need hundreds of engineers to solve a related set of business problems[1], I wager you've done something wrong.

[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?

There's a difference between hiring your 2-3 buddies that'll work with you on your toy startup (many of which ended up shutting down fairly quickly, reading OP's blog) - and actually staffing a diverse team that works on a complex product that's used by many clients and is held up to a high standard.

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).

No worries at all :)

> 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.

I agree with you, this cannot be regarded as a healthy approach to hiring and comes off as delusional.

At the same time, it might sort of work, just that since they a bit randomly discard a fraction of the job applicants, the company will end up paying more, for those it hires (supply and demand). But maybe the company doesn't notice (and in the end what does it matter anyway)

I felt exactly the same when I read this. Plenty of people who are very good engineers have nothing in public to show.

Entire post can be summed up as "this is my answer, here is me rationalizing correlation=causation without any empirical evidence".

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.

This isn't used widely because it is hard. But it's not but novel.

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).

> "My evidence isn't that great I admit. I've only helped build 3 unicorns (helped found one of them) and started 3 $1M+ companies as a solo founder."

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.

false attribution error and appeal to authority

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

“What if they have no code they can legally show”

> 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

> every evaluation technique the entire industry figured out will mostly by filled with people that cant code

Is there a typo? The sentence doesn't make sense to me

Every evaluation technique will be mostly filled by people that cant code

The industry tries them all

Its the wrong conclusion on the efficacy of the technique

Hmm, and evaluation technique cannot be filled by something

One cannot fill an abstract concept like a technique with things

Maybe you mean that every evaluation technique will detect that most of the job applicants aren't good at coding? And therefore, all evaluation techniques seem to work? (Although some techniques are a lot better than others)

If so, then, yes I agree. That's a good point

Yeah thats my point, but also that none are better than the other

They are poor methods of screening or evaluating good candidates for the actual job duties

Ok then I understand :-)

Very useful!

Posted this on behalf of the silent majority that likes the approach.