At the time of writing, my last blog post on the subject of hiring has over 150K views and generated a lot of great discussion. It touched a nerve.
Good.
There's lots of agreement that developer hiring is broken. But there's also disagreement, or at minimum, a general feeling of helplessness: if technical interviews aren't the best way to hire developers, what else is there? When I read such comments, sometimes I wonder how sincere the question really is. Because ultimately, what do you get if you take away the technical developer interview? What are you left with?
Well, what you're left with is what every single other profession in the entire world considers sufficient when hiring.
Let's be clear here: the way developers are hired is not the norm. It's the exception. No other industry or profession does what we do.
- When an accountant is in an interview, they're not asked to multiply on-the-spot in their head what 485 x 761 equals because "you have to be good at math to be an accountant"
- When a lawyer is in an interview, they're not asked to recite legal cases on the spot.
- When a surveyor is in an interview, they're not asked to eyeball how far away a random point in the distance is.
- When a digital artist is in an interview, they're not asked to rapid sketch a portrait with a rusty spoon.
Our profession is uniquely broken. We fucked up. We are, simply put, doing it wrong. So how do you hire amazing developers without doing a technical interview?
In every other profession, the "skill assessment" portion of the hiring interview is fundamentally anchored around two key pillars: I) past performance and experience and/or II) portfolio. Why is this not sufficient for developer hiring? Why can't you look at a developer's portfolio, education, projects they've built, GitHub repo, talk with past employers, check references...and from that make an informed hiring decision?
There's one reason I've heard several times now and it's a false belief I use to harbor also, so I want to talk about it. And sadly enough, it actually has nothing to do with technical skills and more to do with low empathy hiring managers: it's the myth of the developer that can't code.
The myth of the developer that can't code
There's a myth about developers that absolutely needs to die. Here’s how it goes: "I once met a developer who claimed to have 7+ years of Python/Java/whatever and when I sat them down in an interview they couldn't even write FizzBuzz."
I used to think I had met such people (with surprising frequency) too when conducting interviews, but then one day I realized I was the one that was wrong. Very wrong. Let me explain, because this myth needs to die.
If you're a developer working at a typical company, you probably don't write code every day. In my career, I've gone for multi-month stretches where I haven't written any code at all. I've spent months setting up and testing a complex MDM solution for iOS devices. Another time, I worked extensively on a CI/CD pipeline. Or I did a lot of code reviews. Or fixed up some CSS errors. Or wrote documentation. Or fixed up cache busting CDN issues. Or spent days pouring through PostgreSQL logs. Or read about and tried to make front-end accessibility improvements. Or talked to customers about their pain points and then summarized them and made recommendations for management.
And then there have been other periods of my career where I've had to juggle at least 10 different technologies simultaneously. I'd jump back and forward all day between iOS development (Objective-C), front-end development (JavaScript, React, Webpack, HTML, CSS), back-end (Python, Django, Celery, Postgres), and more. I'd hack nginx scripts, fight with AWS, ponder about the best HTTP status code to return in some obscure situation, fight a Promise, wonder why my IDE keeps crashing, and on and on and on.
Our jobs are inordinately complex and the array of tools and technologies we work with daily is dizzying. And that's just the tech side of things.
Now here's the crucial bit. If you pull me aside during any such period - for example, let's say after I had spent weeks doing nothing but pouring through PostgreSQL logs and making query performance improvements - and ask me to, on the spot, in a high pressure situation, fix a Python bug (maybe I'm being asked to fix a production outage costing 1 million dollars/minute to match the interviewing pressure stakes) there is a good chance I will absolutely fuck up something trivial. It doesn't matter how many years experience I have or how good I am.
Empathy
The myth of the developer that can't code exists for one reason, and one reason only: we lack empathy.
We lack the empathy to put ourselves in the shoes of someone else, put on the spot, under high pressure, and asked to recite the words to one very specific song out of the thousands of songs we are able to sing as part of our job.
That's it. That's all it is. And it's obvious this is true:
Senior developers brag all the time on Twitter about how they spend hours tracking down a single missing '=' sign or forget trivial language features. I've read comments like this a hundred times from well-respected and prominent developers. And we all laugh about how often we have to refer to documentation we've been working with extensively for years and years. We laugh at how we can google obscure technical problems we're having and find our own blog posts as answers.
And yet we throw all this away, and in an interview setting attribute a missing '=' sign...this inability to perform an arbitrary task in a high pressure, tense, and unfamiliar environment...we attribute this to instead be a signal the interviewee is an idiot! Despite having a CS degree, positive references, a strong GitHub history, multiple shipped projects, and a strong history of employment, they must be a faker!
Read that last sentence again and tell me who's the idiot?
Because make no mistake, that technical interview - that one-shot coding test we do. That's it. If in the heat of the moment you make a mistake or don't pass, absolutely nothing else matters. FAANG (and sadly everyone else who has copied their half-assed hiring practices) will not hire you. Nothing overrides it: you could be a Nobel laureate and it wouldn't make one iota of difference.
A test of my theory
I've interviewed a lot of candidates for developer roles in past. Most recently I was the CTO of RateIt where I probably interviewed over 100 developers. I dismissed quite a few as not knowing how to code - maybe they failed FizzBuzz or some other technical coding question I assigned. So I did something interesting just now. I went back through 10 of the candidates I remember rejecting, looked at their CVs, and then looked them up on LinkedIn. So what happened to these "can't code" candidates?
Every single one got another job as a software developer. And each held that job for many years.
It was never that they couldn't code. It's that I was blindly following the herd and interviewing like an idiot.
Closing notes
Look, let's be clear here. There are of course, in reality, some people who are faking it. Maybe you accidentally hired one once? It happens. But I suspect there are no more developers that cannot code than there are lawyers that don't know the law, or surveyors that don't know how to...I don't know...survey, I guess. Our industry isn't rife with fakers - it's rife with low empathy people. The myth of the developer that can't code is born out of a lack of empathy and a failure to appreciate that truly great developers tackle a wide variety of tasks and aren't just leetcoders hacking away on algorithms 24/7.