People love to hate leetcode-style interviews. On X, they are regularly described as a waste of time for all parties involved. People point out that real programming jobs are nothing like these artificial 30-60 minute situations, that software engineers can have decade-long careers without ever implementing the algorithms that are regularly discussed during these interviews, and that AI means encyclopedic knowledge of algorithms is even more useless than it was before.¹

Some of that is true. And yet, the critics of leetcode-style interviews are mistaken. When faced with the practical question of assessing within minutes whether a given candidate would be a useful co-worker, leetcode-style questions are hard to beat.

Why is that? I don’t think there is a single mechanism. It’s easy to criticize leetcode-style questions since they assess a combination of skills and desiderata but don’t nail any single one. Let’s therefore describe what leetcode interviews do assess and why that’s a good thing. To make matters more concrete, I’ll describe one of my favorite leetcode-style interview questions in the next blog post.

Leetcode-style questions test if you can code. It’s stupid, but a good fraction of candidates will fail even FizzBuzz. They just cannot code. Any interview that involves coding will find that; having a rule that says a specific interview is for coding exclusively helps get to fast failure for hopeless cases.

Leetcode-style questions can be prepared for. That is the very business model of leetcode.com. Becoming good at these kinds of questions takes a lot of work. Combined with the supposed uselessness of the skill thereby acquired, this is used as an argument against them. But not so: One of the practical questions an interviewer has to answer is just how excited a given candidate is about the job, and about the occupation of programming for a living in the first place. Putting in weeks, or months, of prep time is a strong signal that the candidate is interested in software. That is a lot! In fact, the best programmers I know are excited to discuss new little questions, not too different from how mathematicians discuss little exercises. Being interested in how to find unique triplets of array entries that sum to zero correlates with just being interested in computers and how they work. Sitting down and preparing for a job interview means being at least somewhat interested in the job and the company. That alone eliminates a large fraction of weak candidates. On top of that, companies seek employees who are willing and able to work hard on something. Leetcode graduates proved they can.

Leetcode-style questions test intelligence. While candidates sometimes try to brute-force these questions by remembering all possible answers, people with high IQ have a huge natural advantage. Smart people are generally useful, and assessing how smart a candidate is is a core part of interviews (being smart covers a multitude of other flaws). That is also why universities find SAT results useful. Of course, measuring IQ directly via a test would presumably be more precise, but the US has a history of disincentivizing this since the outcomes are politically disfavored. And a pure IQ test would likely be less meaningful since leetcode-style questions cover more ground, including prior knowledge:

Leetcode-style questions test knowledge. The contrast between rote memorization and skill is not as strict as it’s sometimes made out to be, neither in software engineering nor in other areas such as math. Knowing what, e.g., a Bloom filter is is genuinely useful, as is knowing the name of the thing. Since practically nobody is able to re-derive meaningful parts of computer science from scratch by themselves (there is some content to the field after all), knowing what exists and how to talk about it is a useful skill. During the actual work of a good software engineer, various design decisions and judgment calls about systems have to be made. Knowing the toolbox, and knowing it well, is essential to making these decisions well. This can be traded off with intelligence or other sources of good intuition about these practical problems, but ceteris paribus knowing more is better.

Of course that depends on the type of software engineering role the candidate wants to fill. Folks writing database lookups for a Django app may not need to know Fenwick trees. However, that brings me to

AI’s impact on software engineering. I cannot foresee all consequences of coding models on the ecosystem but it seems likely it will change a lot and fast. It’s possible the role won’t exist at all in the near term, in which case all interview techniques are obsolete. It stands to reason though that the more routine, more obviously automatable tasks will be automated first. Who’s got more job security, the guy who knows about Zobrist hashing or the hundredth CRUD engineer? I don’t know if “be the knowledgeable engineer” is actionable advice – since nobody decided to be somewhat disinterested, most people just are like that – but “hire the knowledgeable engineer” is. Knowledgeable engineers work on harder, more interesting problems and are likely to at some point in their career engage with “low-level fundamentals”. The blunt answer to the “I’ve never needed this” argument is “but the good ones do”. And for what it’s worth, several of the ideas described in the next post did end up being relevant in my career.

Leetcode-style questions are an industry standard for a reason. The artificialness of asking a problem from a predefined pool, again and again and again, is even more obvious to the interviewers than it is to the critics. Trying to do something smarter is a decades-old idea. In his 2015 book, the long-time Google head of recruitment Laszlo Bock described some of the ideas of early Google. They include nifty ideas like programming-related easter eggs in Google search and McKinsey-style brainteasers. Few if any of the cool ideas worked, and Google instead relied on ~four structured interviews from a shared pool with defined rubrics.²

Leetcode-style questions are doable. Is passing a leetcode-style interview the best possible signal a candidate can have? Far from it. Meaningful previous projects are better by far. Being able to talk in detail about related work is better. Being Linus Torvalds is better. But as hard as preparing for coding interviews is, producing those signals is harder still for most candidates, especially the youngest and least well-connected. Companies don’t have the resources to give most candidates an internship, but they can and will interview the promising ones.

This is not to say that all leetcode-style interviews are done well. To give a bit of flavor as to what kinds of questions I like to ask, read about my favorite interview question in part two.