The systemic decay of tech hiring<br>Complaining about tech interviews is the favorite pastime of software engineers. We know they're broken, we've seen exactly how they're broken, but, despite a decade of collective hand-waving, we haven't fixed them. In fact, we haven't even understood why they're broken: "interviewers are stupid" is a tempting explanation, but most people I've worked with are quite smart, so it can't be the only reason.<br>I stepped into hiring manager shoes as the job market was descending into AI panic. I've run over a hundred interviews, made a few dozen hires (with a few epic fails), and eventually led a redesign of our process for AI reality. After months of experiments and reflection, I think I see how this works.<br>In this article, we'll trace how an industry full of smart, well-intended engineers created the lunacy of the modern tech interview. This story has it all: chance and fate, fear and bravery, good people crushed by the system that's set up to degrade. I might not have an easy fix, but at least we'll understand the mechanics of this death loop. Let's go!<br>Hiring is not deterministic<br>We engineers expect actions to have a predictable outcome. Assign a variable in code, beep bop, its memory register value changes. Cause and effect. Naturally, we want an algorithm for hiring that reliably separates good engineers from bad ones. Nice as it would be, this is not a realistic expectation.<br>Imagine: I'm a good engineer, your interview process is great, you hire me. One month in, I decide that work is not really my thing, and I won't try that hard any more. The process was fine, but it failed to predict my performance, because the future is inherently uncertain.<br>Hiring is, in essence, a binary classification problem: based on some observations, predict whether a candidate will perform well on our project. Apart from the good outcomes, we have two types of errors:<br>False positive: we hire a candidate who turns out really bad at the actual job.<br>False negative: we don't hire a candidate who would have been a great fit.<br>With enough hires, we're statistically certain to make both types of errors. But their effects are drastically different.<br>The error asymmetry<br>A bad hire (false positive) is costly and visible. On top of the wasted hiring budget, a truly bad engineer creates security risks, damages architecture, and brings down production, all in a day's work. That's the kind of mistake that gets everyone's attention and causes unpleasant questions along the lines of "Vladimir what were you thinking hiring that guy"?<br>Missed good hires (false negatives), on the other hand, are practically invisible. Usually, the rejected candidate just vanishes. In the rare case we accidentally learn they turned out to be a great success somewhere else, it's easy to shake it off — just because they're a great fit over there, doesn't mean they would've been any good over here. We might get some extra time-to-hire and interview load, but this is nothing compared to the costs of a bad hire, right?<br>So, the conventional wisdom is "false positives, avoid at all costs; false negatives, fine". After a bad hire, we'd run a postmortem to understand what went wrong, and how to avoid all this trouble in the future. Focusing on false positives collapses the hiring problem into one dimension: if a low performer sneaked through, the bar was too low, and we must raise it by adding complexity. This makes tech interviews progressively harder. But is harder always better?<br>The tale of two complexities<br>Welcome to our software engineering interview. Here, a surprise awaits: to pass, you must win a game of chess against Grandmaster Anatoly Karpov, former Chess World Champion. This kind of interview will be very hard, but would it be good at selecting productive software engineers? Probably not, because chess is very loosely related to software engineering.<br>While real-world interviews rarely involve chess (I wouldn't mind if they occasionally did), the core principle is clear. Interview complexity has two parts:<br>Relevant complexity predicts the candidate's performance.<br>Incidental complexity randomly eliminates candidates by unrelated criteria.<br>Both kinds make the interview harder, but only the relevant produces useful signals. Incidental complexity produces random noise, and is essentially a time-consuming equivalent of making hiring decisions through dice rolls.<br>"Got it, don't involve chess in the interview and I'll be fine" — I hear you say. But in practice, isolating relevant complexity can be tricky. Say, we're hiring for a realtime dashboard team, and we add a pretty relevant topic — WebSockets. Are we filtering on genuine experience, or on recent exposure to the technology? Does current WebSocket knowledge really predict the overall performance, say, 3 months in? Maybe we've done the right call, maybe we're playing chess — probably a bit of both.<br>So, we're stuck piling up complexity based on our gut feeling. Every new topic...