David Heinemeier Hansson

January 10, 2022

The merit of hiring by merit

I've spent years pushing back against hiring practices based on years of irrelevance, pedigree gates, and brainteasers. These indirect measures of talent have proven both unreliable and unfair. If you can, why not look directly at merit?

When it comes to programmers, that merit is chiefly their ability to program! And program well. It's not the only thing that matters, and being a good programmer isn't alone sufficient to be hired at Basecamp, but it is a prerequisite. It doesn't matter what else is true about you, if your programming chops aren't up to par, there's not going to be a job offer.

So far, so uncontroversial, you'd think? But I'm increasingly seeing this basic lean on merit, as the key hiring assessment, becoming contested. Perhaps that started with the broad attempt to discredit meritocracy. The idea that the best not only should rise to the top, but that they deserve to do so.

Meritocracy has been criticized from a number of angles. Like maybe the people evaluating the merit don't actually have a clue, and undeserving people who aren't good at what they do never the less rise to the top from chummy relations or pattern-matched personality traits. I can get absolutely behind a criticism like that.

The criticism I cannot get behind is the one which claims an injustice if the assessment of merit fails to produce the desired diversity. Whether that distinction is made along the lines of age, gender, race, or any other identity marker. Diversity certainly can be of merit in itself, as the team acquires a broader perspective and more closely resembles its customer base, but not as a displacement for core competency.

Contesting the value of merit in hiring isn't limited to tech. There have been calls to unblind the auditions for orchestras, since this basic notion of merit – who best plays the cello – is claimed to fail the the diversity objectives. (That argument also advances the contradiction that there is simultaneously no "pipeline problem" and blind auditions are unjust.)

But perhaps no bigger skirmish is being had on this question than the one about merit assessments via admission tests for the most elite educational institutions in the US. Whether that is in top high schools, like Stuyvesant in New York or Thomas Jefferson in Virginia, or universities from Harvard to the University of California. Letting students test into these institutions is falling out of favor under the same arguments that underpinned the calls to end blind auditions for orchestras.

John McWhorter tackles this question from an interesting perspective in his new book: Does it help someone to be admitted to a school if their core competency isn't up to par? And answers this with a persuasive "no". Being admitted to a school where it's hard to keep up does not help the student. I'd argue that the same is true in most domains.

I see the same thing with programmers. If a programmer isn't able to keep up with the bar set by their team, they're going to have a bad time, and so is that team. And it isn't about seniority either. A junior programmer who's showing aptitude and trajectory can work out just fine. It's when someone has hit the steady-state of their career that the trouble is unavoidable.

Nobody wants to sit through review after review where their code is being sent back for major revisions time and again. And nobody wants to perform such reviews either. If the gap is too big, it'll eventually swallow up the best intentions, the broadest patience, and the deepest empathy. Leading to the person being reviewed feeling bad about themselves, and the person giving the review being guilty about inflicting such emotions.

That does not mean such an individual couldn't prosper somewhere else! That's the crux of McWhorter's argument about matching a student's abilities to a school that fits. Once you're working with others of like capacity, you're going to have a much better time, and accomplish more too.

The world needs people and programmers of all sorts of different levels. The majority of front-ends-on-a-database work that employs millions today doesn't exactly ask for geniuses. But perhaps part what underpins this discussion is a growing dispute as to whether people even are on "different levels", or if programmers are all mostly the same in skill, just of different identities. (Witness the exasperated eye-rolling at the notion of the 10x programmer in some circles.)

That still doesn't change the fact that making people of significantly varying competence work together – when it's not mediated by differences in seniority – is a struggle. And that this struggle can be avoided by making direct assessments of merit a crucial component of the hiring process.

So that's what we do at Basecamp. With programmers, we ask the finalists to complete a substantial take-home assignment that's a realistic sliver of the work they'd do if hired. The assignment can be completed in 3-5 hours, but some applicants end up spending a whole day. Cue the outrage!

How dare you make the top 2-5% of candidates work for free!!

This opposition has always puzzled me. Which is what brought me to think about the broader opposition to merit testing. But let's just take this as a good-faith objection. 

First, "working for free" makes no sense if the work has no value, which is the case of these assessments. It's not like after someone submits their assignment that we then crack an evil laugh and deploy to production. By their very nature, we already have the answer to these assessments! They're usually extracted from some problem we faced, and solved, in the past. There's no real economic value in a new set of solutions.

Second, it seems that most of the people with the most strenuous objections to this assessment of merit wouldn't bat an eye having to spend a day on travel and traditional interviews. Isn't it more fun to exercise your skills and creativity on a technical challenge than to do that?

Third, the alternative to direct assessments of merit is usually indirect assessments of merit! Like those pedigree gates. Or those brainteasers. Isn't that worse? Because the alternative is certainly not nothing. And by nothing I mean "we look at your CV and just have a conversation about work". That's a complete crapshoot that gives the smoothest talkers the best chance, and is that really the programmers who are most "deserving"?

However you slice it, it's difficult to hire well. But you can make it substantially easier if you're able to gauge merit from direct observation. Whether that's a blind audition for the orchestra, standardized tests of admission for college, or a take-home test as a programmer.

Merit is not a dirty word. Letting everyone have an equal shot is equality of opportunity. Once we veer off that path, we're into the wilderness.

May the best candidate get the spot, the admission, or the job.

About David Heinemeier Hansson

Made Basecamp and HEY for the underdogs as co-owner and CTO of 37signals. Created Ruby on Rails. Wrote REWORK, It Doesn't Have to Be Crazy at Work, and REMOTE. Won at Le Mans as a racing driver. Fought the big tech monopolies as an antitrust advocate. Invested in Danish startups.