Are tech interviews broken — or is the cruelty the point?

Hiring managers say that coding challenges are the easiest way to find the best developers, but I'm not convinced.

Now that I’m nine months on testosterone, I have the white boy confidence to say something that I’ve never said before:

I am a good developer.

By now, I’ve been coding for more than half my life. I can write clean, modular code that’s easy to reuse. I’m a quick debugger because I’ve done it for so long that I have a sense for where error-prone parts of the code might be before I even run it. I’ve also punked myself so many times that I’ve finally gotten into the habit of writing code that I can actually read a year later.

I’ve also never, ever passed a coding interview. Every time I’m in one, I’m overcome by so much anxiety, self-consciousness, and proletariat rage that I have trouble even understanding what the hell the question is. When presented with the problem “reverse this linked list”, I’m thrown into a pit of despair so deep that it takes me entire minutes before I can crawl out of my mind dungeon and recall what the words “linked list”, “reverse”, and “this” even mean. My greatest strength becomes my undoing when I’m confronted with the “find all the bugs in this code” question, where I’m given leetcode with manufactured bugs — the manufacturing process now having undone the instinct all experienced developers have for where bugs are most likely.

Every time I’m in one of these interviews, I feel like maybe I should say something. Like stand up for myself in some meaningful way, or even just drop the zoom call and go jerk off instead. But instead I just sit there, look dumb, miss something completely obvious, and then get a rejection email a week later.

Nowadays, I’ve moved into a tech career that’s more people-oriented and left coding for my own free time. It works for me. But not for people who want to work full-time as a developer and have anxiety about the obscene interview processes involved.

So why are tech interviews like this? To be honest, I still don’t know. Like anything, there’s probably a hundred different factors involved. But I can go through the most common arguments and why they’re not good enough for me, and after that, maybe I can convince you of a factor that I think many people overlook.

Common arguments in support of coding interviews:

This isn’t a big deal at all. Not all tech companies do coding interviews.

True, but they’re common enough to be a problem. It’s not just FAANG that does this. I’ve gotten whiteboarded almost every time I’ve applied for a technical position, including at small companies and especially at startups. Many of my dev friends apply to companies that have no right being selective at all, and still get given coding challenges. It’s not isolated to the “elite” companies.

Interviewers need to know that you can code.

Sure. I get that. If I’m ever put through the mortifying ordeal of being a hiring manager, then I’d also want to know that my candidates can code. But get this: I’d do that by looking at their credentials. If someone has graduated with a software degree, or gone through a bootcamp, or worked for many years in the field, or has their own Github projects — then that person can probably code.

Developers like to think that learning to code is hard, because it makes us feel special. But it really, really isn’t. Anyone who wants to learn to code can do it, as long as they have the time and patience necessary. If someone has worked on projects that they can confidently talk about, then they can code.

All coding interviews do is throw away otherwise incredible developers who just don’t do well with coding interviews.

Okay, so maybe people who fail coding interviews can still code. But anyone can lie about experience and projects, while to pass a coding interview you have to know how to code. And it’s much less costly to have a false negative (accidentally rejecting a good engineer) than it is to have a false positive (accidentally hiring a bad one).

On the surface, this is a fine point. Having to replace someone who isn’t right for your team is a mess. It’s bad for the budget, bad for the codebase, bad for the legal team, bad for morale, and especially bad for the engineer being replaced. Everyone loses.

But here’s the problem with that argument: people who can pass coding interviews aren’t always people who can code.

It’s completely possible to know nothing about writing modular code, nothing about how to read and write documentation, nothing about giving constructive critique on other people’s PRs, nothing about refactoring, nothing about good debugging, even nothing about data structures and algorithms — and still brute force your way through enough HackerRank questions to be an interviewing pro. It’s what a lot of long, pale boys with very poor social skills did back when I was in my compsci classes.

Most people reading this, myself included, could probably spend the next few months studying coding interview questions and become pros as well. The key part is that we don’t fucking want to. And that’s important for later.

Coding interviews are broken, but they’d be fixed if interviewers just asked more relevant questions.

If interviewers posed coding challenges that were relevant to the product they’re building instead of just linked lists and recursion, then the process would be less offensive, sure. But it doesn’t solve the fact that coding interviews are a massive power imbalance between hiring managers and candidates, and that being able to code when put on the spot during an interview is its own skill that needs to be trained at the cost of the candidate’s time.

Lots of people fail our coding challenge, therefore it’s working!

I’m leaving this one in because it’s funny. Someone on Twitter told me that they’ve interviewed candidates who couldn’t complete FizzBuzz, therefore FizzBuzz is a good challenge.

This is the same logic used in many universities, where the administrative bureaucracy punishes professors for teaching classes that are “too easy” if not enough students fail. The success criteria of the tests is the failure of the people tested. It’s an intrinsically antagonistic system.

So tech interviews are broken, right?

They have to be.

Right?

I spent a good portion of my life thinking that capitalism was “broken.” When I heard a deranged Argentinian neckbeard on YouTube explain that no, in fact — it was working exactly as designed — it changed my outlook on how I analyze a lot of other power structures. Maybe a similar analysis can apply here.

I’ve never seen anyone try to apply Hegelian dialectics* to software interviewing, so if I get this right, I really hope someone can give me a Nobel Prize in Being A Pretentious Online Asshole.

So here’s our thesis: tech interviews are broken. Almost every developer you’ll ever speak to hates them.

Here’s an antithesis: tech interviews can’t be broken, because tech companies have been using them for over a decade, swear by them, and are still making more money than ever.

Putting it together: Tech interviews are broken for developers, but something about them is working very, very well for tech companies.

So what’s going on here? I think we can often understand power structures better once we think about what each party has and needs out of the encounter. Here’s how it works for tech interviews:

Tech companies want a candidate who:

• Produces quality code

• Will accept the least amount of salary and benefits for the most amount of labor performed

• Can work well in a team, posing minimal disruption to other developers and management

• Will not attempt to challenge existing power structures by advocating for worker rights or a union

• Is generally willing to perform overtime if required

• Is willing to use their own free time to advance their skills as a developer, at no cost to the company’s training budget

Those are just the key points I can name without making the list too long.

Developers want a company that:

• Pays them well

• Provides the most amount of salary and benefits for the least amount of labor performed

• Has a managerial structure that puts developer interests first

• Respects their time by not expecting them to perform company-related duties outside their formal working hours

These interests are, unfortunately, diametrically opposed. In early stage startups, worker co-operatives, or other structures where employees have a large share of the company, the differences between these two groups blend. But since we live under a zero-sum economic structure, what’s good for employees is generally not what’s good for business owners. Paying developers more means that the company has less money left over for profits and executive bonuses. Giving the developers more time off means deadlines can’t be as tight. Allowing the developers to have more ownership of the company means that there’s fewer shares left over to sell to investors. The very idea of having a union — a structure that exists for almost every other worker, even well-paid ones such as doctors and lawyers — is a fringe, radical concept to software engineers.

Even the most staunch defenders of neoliberal economics admit that this conflict between workers and owners exists. A lot of developers, however, don’t. And I think a key mechanic of the coding interview process is to separate the developers who don’t mind this problem from the ones who do.

I’m not a 19th century English anthropologist, so I don’t like putting people into overly restrictive, problematic categories. But to get my point across, I think many software engineers fall into one of two loose boxes which I’ll sardonically call: 1xers, and 10xers.

1xers are people like me, and probably you as well if you’ve read this far. We code professionally or in our free time, maybe even both. We have some things that we’re passionate about, or maybe this is just something that we just do for a living. 1xers often come from less wealthy backgrounds, and we’re a little roughed up by the challenges we’ve faced getting into tech. Overall, we’re tired, and we don’t care much about hiding it. We’ve seen what the industry has to offer, and we’re not impressed. We’re not interested in putting in back-breaking amounts of overtime, and we’re not unconditional hypebeasts for the company. We’re not dedicated to getting promoted as quickly as possible, so we’re comfortable taking the risk of calling out management when they pull something screwy. A few of us want to start our own businesses, mostly in the hope of one day being free from work — but many of us would rather be in a co-op. Or an non-profit. Or herding goats in the Himalayas.

And then there’s 10xers. I probably don’t even need to explain the 10xer to you, because I bet you’ve already met him, and it usually is a him. The 10xer has no problem with doing overtime — they probably even see it as a point of pride. They want to get promoted as quickly as possible, either vertically or horizontally. They advocate for their salaries just as strongly if not stronger than 1xers do, because they’re less affected by imposter syndrome — though they’re often less likely to do salary advocacy for the benefit of others. They’re not upset about the economic conflict between workers and businesses, because they don’t see a meaningful distinction between the two. They don’t care about politics, either social or economic. They just want to ship.

Like I said earlier, attempting to categorize humans like this is always flawed — no one really fits neatly into either of these categories. But I do believe that when someone has a quality from one of these boxes, they’re more likely to have the other qualities too.

The 10xer is usually the developer that tech companies are looking for. I have no problem with 10xers. Some of them continue to be my friends despite how much anarchist propaganda I send them, and many more of them are my colleagues. But while 1xers like me see coding interviews as a humiliating and gross imbalance of power, 10xers usually see them as something else: a necessary evil in the dog eat dog world of the tech industry, and a cool opportunity to show off how good they are at recursion.

So what the hell am I trying to get at?

I honestly don’t know. This is a complicated topic with a lot of systems at play and I’m no Marx. I’m not even an Engels. I’m just some guy who went viral after posting an IsEven() function made from hundreds of if statements and now people listen to my opinions on computers for some reason.

I’m going to go make tea and sit on the floor until my head stops hurting.

The cruelty is the point

Have you ever met someone who keeps backyard hens for eggs? They’ll talk about how much they love their hens, how spoiled they are, how the hens are part of their family, etc. A fun way to make dinner extremely awkward is to ask them if one of their hens has ever started eating her own eggs.

The thing with chickens is that we’ve fucked them up. Wild chickens only lay 10-15 eggs a year, while domesticated ones can lay over 300. This stresses the hens both psychologically and physically, and one of the ways hens can recover the nutrients they lose during the egg-laying process is by eating their own eggs. Once one hen figures out that she can do this, she’ll quickly teach the other hens that they can do it too. This is why people who own backyard hens are sometimes encouraged to slaughter any chicken they catch doing this, so she can’t influence the others.

Have I told you yet that I’m vegan?

I’m vegan, by the way.

So am I saying that coding interviews were invented to weed out communist agitators? No, obviously not. What I am saying is that subjecting developers to the dehumanizing, anxiety-inducing process of coding interviews is a lot more likely to select for developers who, metaphorically, will not eat their own eggs. Which I wouldn’t do, because I am vegan.

I don’t think that this consequence of coding interviews was an intentional one. More than likely, this happened completely by accident, and it’s stuck around because it works. But if I was responsible for hiring developers at a tech company and I wanted to have a team of neurotypical people who can work well when put on the spot, won’t question cruel decisions by management, and won’t walk away when confronted by unfair working conditions — then I would make my coding interviews as brutal as possible.

This leaves a question that I’m not entirely sure how to answer: if coding interviews are so great for tech companies, then how come other industries haven’t adopted a similar practice yet? Why don’t artists have to draw in front of their interviewers, and why don’t editors have to live edit a magazine article before they’re hired?

The only real answer I can think of is — well, we’re the disrupters, aren’t we?

A better world is possible

As always, it’s important to remember that another world is possible. There’s a potential future out there where we no longer need to “earn a living”, where basic necessities like housing, food, connection, transport and education are available to everyone, and where people develop software because they want to, not because they have to. In this future, the very concept of lying about your experience to get a job will be laughable. Drilling someone about linked lists to make sure you’re not “wasting resources” on a “bad candidate” will be laughable, an absurd relic of a cruel past. People will contribute to projects and organizations that are meaningful to them, maybe similarly to how open source is run today, or maybe in other ways that I encourage you to try to imagine. Software projects will be aimed towards automating away labor, creating abundance, finding new ways to entertain each other and share our joy with one another, and helping undo the catastrophic effect we’ve had on our climate — instead of what software does today, which is anything that can generate profits for investors. And then I’ll have to find a new thing to complain about in this newsletter.

This future is possible, and we won’t find it on a whiteboard.

---

* I have not actually read Hegel. I never will.