Beyond Cracking the Coding Interview Full Text: Chapters 0-2

Beyond Cracking the Coding Interview Full Text: Chapters 0-2

By Aline Lerner | Published: August 26, 2026

Hello! I'm Aline, founder of interviewing.io and one of the authors of Beyond Cracking the Coding Interview. We're making all of the chapters I wrote freely available on our blog. I'll be publishing chapters every few weeks.

If you don't like reading, here's me reading these chapters out loud. Pick your poison.

Author Reads the First 3 Chapters of Beyond Cracking the Coding Interview Out Loud

Now, without further ado... the full text of chapters 0-2 is below.

Chapter 0: Why job searches suck

Job searches suck— especially for engineers, who are, by and large, rational, well-intentioned people who expect the world to function according to some set of predictable rules. Why do job searches suck so much?

These are just a few of the challenges, but the strategies in this book will help you navigate them and achieve success—however you define it.

Given all these flaws, you might ask: How did we get here, where our technical interviews feel so divorced from the work and so unpredictable in their outcomes? For that, let’s take a brief look at the history of technical interviewing.

Chapter 1: A brief history of technical interviews

A definitive work on the history of technical interviewing was surprisingly hard to find, but we were able to piece together a narrative by scouring books like How Would You Move Mount Fuji, Programming Interviews Exposed, and the bounty of the internets. The story goes something like this.

Technical interviewing has its roots as far back as the 1950s, at Shockley Semiconductor Laboratories in Mountain View, California. William Shockley’s 1 interviewing methodology came out of the need to keep up with the innovative, rapidly moving, Cold War-fueled tech sector, something that traditional hiring approaches taken from established, skills-based assembly line industries simply couldn’t handle.

And so, Shockley relied on questions that could gauge analytical ability, intellect, and potential quickly. One canonical question2 in this category has to do with coins:

You have eight identical-looking coins, except one is lighter than the rest. Figure out which one it is with just two weighings on a pan balance.

The techniques that Shockley developed were adopted by Microsoft during the 1990s, as the success of the desktop computer, and later, the first dot-com boom spurred an explosion in tech hiring. Like Shockley, Microsoft also needed to quickly and scalably assess high volumes of candidates for potential. As software engineering became increasingly complex, it was no longer possible to have a few centralized expert programmers manage the design and then delegate away the minutiae. Even rank-and-file developers needed to be able to produce under a variety of rapidly evolving conditions, where just mastery of specific skills wasn’t enough.

The puzzle format, in particular, was easy to standardize because individual hiring managers didn’t have to come up with their own interview questions, and a company could quickly build up its own interchangeable question repository. Over time, most companies did away with puzzle questions for engineers, and moved to algorithmic questions: these questions seemed more relevant but still assessed problem-solving skills.

At many top companies, such as Google, this need for interchangeable parts ultimately carried over to the interview process as well—rather than having individual teams run their own processes and pipelines, companies standardized it. This way, in addition to questions, you could effectively plug and play the interviewers themselves—any interviewer within your org could be quickly trained up and assigned to speak with any candidate, independent of the prospective team.

At the same time, companies didn’t always create incentives for engineers to work hard at being good interviewers, and as you’ll see later in this book, we believe that much of the flak that algorithmic interviews get is due to the interviewers conducting them (and, often, lack of training or proper incentives).

So where does this leave us? Technical interviews are, at best, a proxy for the day-to-day tasks that a software engineer actually does, and not all interviewers are good. But, regardless, do technical interviews work? Well, that's complicated and depends a lot on your definition of "work." For whom, the candidate or the company? For what type of company? Compared to what?

We would argue that interviewing as a whole is flawed, and it's really a matter of picking your poison. However, even the most ardent defenders3 of these sorts of technical interviews agree that false negatives—great engineers who get rejected—are common. FAANGs and other companies who adopt these processes tolerate a high false negative rate, under the rationale that it's better to reject a good candidate than to hire a bad one. The process is optimized to reduce false positives.

For you, the candidate, that kind of sucks. But it is what it is, and that's what this book is here for: to help you avoid being one of those false negatives.

Chapter 2: What's broken about coding interviews

This chapter dives into the systemic flaws of technical interviews, from the prevalence of bad questions and bad interviewers to the randomness of interview outcomes and the growing interview-industrial complex. But it’s not all doom and gloom. Once you understand the challenges and accept that the system is flawed, you’ll be able to operate within it and win (and do so with confidence and integrity).

IT'S NOT THE WORK YOU DO EVERY DAY

One of the most persistent critiques of technical interviews is that they feel disconnected from the work you do every day. If interviews were like the work you did every day, we’d expect that senior engineers would outperform juniors in interviews. As it turns out, that’s not the case: frustratingly, the more experienced you are, the worse you perform.

We actually have data for this. If you look at performance in their first mock interview on interviewing.io, junior engineers significantly outperform senior ones. In the upcoming graph, you can see the average score that candidates got in their first mock interview on interviewing.io, broken out by seniority. Not only do junior engineers significantly outperform experienced engineers,4 but experienced engineers perform the worst out of all the groups.

This effect gets less pronounced as people practice more; once everyone has done a bunch of mock interviews, they all roughly converge, as you can see in the next graph. But, out of the gate, recency with the material gives you a significant advantage.

You might also notice in this graph that it takes about five mock interviews, on average, to start passing these interviews.

BAD QUESTIONS (AND MEMORIZATION OVER UNDERSTANDING)

There is so much vitriol targeted toward technical interview questions that rehashing it in detail probably isn’t worth the paper this book is printed on. If you’ve ever read any thread on Hacker News about interviewing, you know the main points:5

We do not disagree with any of these points, and yes, these flaws are real. We’ve already talked about how we got here and why technical interviews are the way they are. It’s easier for huge companies to scale if they can reduce interviewer training time and not have to come up with original questions/use LeetCode questions verbatim. Sadly, smaller companies often “cargo cult” large company practices, not realizing that they hire good candidates despite their processes and not because of them.

It's also true that memorizing helps a lot. On interviewing.io, after every interview, both interviewers and interviewees fill out a feedback form. One of the things we ask interviewees is whether they’ve seen this question before. We don’t share whether they have or not with interviewers, so there’s no reason to lie.

Here is a graph of the pass rate for algorithmic interviews as a function of whether candidates have seen the question before.

As you can see, familiarity with a question before gives you a serious edge in interviews: you are 33% more likely to pass. We expect that this disparity would be even higher if we had rephrased our feedback form to say something like, “Have you practiced this question before?”

The fact that memorizing questions gives you an edge is ironic, given that the whole purpose of modern technical interviewing is to evaluate one’s ability to think like an engineer, rather than come to the table with a bunch of specific skills. It’s also one of the things that makes it harder to stomach practicing for interviews. It’s a tough pill to swallow to know that, ultimately, you’re competing with memorizers.

In this book, we’ll arm you with the kind of foundational understanding that will make memorization less important (but will be just as effective at improving your performance).

BAD INTERVIEWERS WHO DON’T WANT TO BE THERE

Good interviewers can get good signal from a bad question. Bad interviewers cannot even get good signal from a good question. For a good interviewer, the question is just a tool to guide the discussion into interesting areas. For bad interviewers, the question is an absolute to which they must hear the exact answer they have in mind.

— Jos Visser, Member of Technical Staff at OpenAI, and formerly of Google, Facebook, and Amazon

Yes, bad questions are bad. However, bad interviewers are, in our minds, the biggest problem with technical interviews. A terrible question, in the hands of a skilled, engaged interviewer, can yield meaningful signal. A great question asked by an unskilled, disconnected interviewer will always be bad. We talked about how large companies adopted modern technical interviewing in part because of the “interchangeable parts” approach to provisioning interviewers. However, human beings are not gears or sprockets—each comes with their own unique hangups and proclivities. It’s naive to think that you can swap one interviewer for another and achieve the same result.

In our experience hiring professional mock interviewers, we saw very quickly that whether someone likes to conduct interviews is bimodal: either they love it or they hate it, with not much in between.

The people who like interviewing tend to enjoy teaching. They tend to have higher-than-average empathy, they remember a time when they were on the other side of the table, and they want to make that experience less painful for their candidates. They also tend to approach interviews with a certain curiosity. They are curious about novel ways to solve the problem, about new rabbit holes their candidates will inevitably go down, and about the candidates themselves.

The people who hate interviewing treat it as a disruption—a necessary evil between shipping features. They do the bare minimum, and it shows. Over the years, we've listened to a lot of interviews. You can immediately identify when an interviewer is checked out. You’ll hear them typing. You’ll hear them go silent for a while. They’ll often need to ask the candidate to repeat themselves. You certainly won’t hear them collaborating with their candidate or gently guiding them away from a perilous rabbit hole. Most of us have been on the receiving end of an interviewer’s callous indifference and know what it feels like.

Bad interviewers are common across companies, even top-tier ones,6 and there is an added complication: companies don’t usually track who their best interviewers are, nor do they reward them. Sadly, it’s often the opposite—bad interviewers get rewarded because they focus on writing code instead of conducting interviews. In other words, curmudgeons who alienate their recruiting team (and get scheduled less often as a result) get rewarded. Engineers who end up being less present in their interviews because their mind is elsewhere, still churning through the code they were writing when they got interrupted, get rewarded. In the rare instances where we’ve seen companies really care about interviewer quality, it’s because an eng leader there has taken it upon themselves, as a labor of love.

Why does it matter if an interviewer is bad, outside of it being a poor experience for candidates? In this graph, you can see the average interview pass rates on interviewing.io, broken out by interviewer quality.7

Interviewer quality matters because the purpose of a technical interview is not to see if you can get the perfect answer. You’re not just solving a coding problem online by yourself. As such:

For all their perceived objectivity (and certainly they’re more objective than ones where you talk about your experience), coding interviews are a complex interaction between two humans. When one of the parties isn’t truly present, the candidate pipeline suffers, and you end up with fewer candidates to choose from and, ultimately, worse hires.

NON-DETERMINISTIC OUTCOMES

Anyone who’s done multiple technical interviews has probably felt in their gut that outcomes are somewhat arbitrary. So much depends on serendipity and, well, clicking! Did you click with your interviewer? Did something click in your head at the right time when trying to solve the problem?

If you’ve felt like this, you’re not alone, and we have the data to prove it. On interviewing.io, after every interview, you get a technical score from your interviewer, on a scale of 1 to 4. The same candidate can do multiple interviews, each of which is with a different interviewer and/or different company, and this opens the door for some pretty interesting and somewhat controlled comparative analysis.

With that in mind, we looked at how the same person performed from interview to interview.

We analyzed interviewing.io’s data to understand how individuals performed across multiple interviews (for this analysis, we included people who did between 3 and 20 interviews). Each circle or diamond represents people with that specific average score and standard deviation across their interviews.

The y-axis is the standard deviation of performance; a higher standard deviation reflects more volatility. Some surprising takeaways from this analysis:

So, what did the most highly volatile performers have in common? The answer appears to be, well, nothing. About half were working at top companies. About 60% had attended top schools. And years of experience didn’t have much to do with it either—a plurality of interviewees had between 2 and 6 years of experience, with the rest all over the board (varying between 1 and 20 years).

When we corrected for interviewer strictness, the effect didn’t go away either.

Why is this bad? This inconsistency means randomness significantly impacts your career. In a way, interviews serve the same function as standardized tests—giving an organization a way to make a value judgment about someone’s ability relatively quickly and without a lot of priors, in a way that’s consistent and repeatable. For all their flaws and biases, standardized testing providers have made a lot of effort to make sure that their results are repeatable because their results often determine the social mobility and livelihoods of millions of students every year. Even though they have a similar impact on outcomes for millions of engineers, tech companies have not done the same for their interviews.

BUCKETED SCORING

Imagine that we wanted to evaluate whether students in a given classroom were tall or short. But rather than measuring people’s heights, we first bucketed them into “very short,” “short,” “tall,” or “very tall.” Inevitably, there will be many cases where two students are nearly the same height, but a few millimeters make the difference between “short” and “tall.”

Any bucketed scoring will lose precision and create arbitrariness, but it’s even worse when we have few buckets and split the middle zone—which is common. That is, if, rather than providing a bucket for “average height” (where most people might fall), we split these people into “short” and “tall” depending on whether they cross some threshold. Now, we don’t just have some arbitrary scores; we have a lot of them.

This is effectively what’s happening in many technical interviews. In fact, it can be a triple-whammy.

A candidate who gets {3.2, 3.3, 2.7, 3.4} on a four-point scale may be hired, but the candidate who gets {3/hire, 3/hire, 2/no-hire, 3/hire} (a possible risk-averse rounding equivalent) may not be. We've effectively lost the information that the "no-hire" was actually really close to a "hire."

No matter how you bucket, bucketed scoring effectively forces interviewers to translate very typical scores into something more extreme and loses fidelity in the process. No wonder we have so much variability in interviews!

INTERVIEW PREP BEGETS INTERVIEW PREP

Technical interviewing has given rise to a booming preparation industry. This is somewhat ironic, as it defeats the purpose of this form of interviewing; the goal was to understand the candidate's aptitude, independent of what they currently know.

The reality is that—as we've shown—interview prep works. We might not like it, but people do better with preparation. That's why interview prep is a multi-billion dollar industry, including everything from books and courses to asynchronous coding challenges and mock interviews. This also means that you are being compared to candidates who are prepping for interviews (and, in many cases, simply memorizing a ton of questions), which means that the expectations for you have gone up too. What do you do about this? You, of course, prepare for interviews too.

It's an unfortunate cycle; interview prep begets interview prep.8 But for the record, memorizing problems without also working on understanding goes against our preparation philosophy, and it’s honestly not that effective.

All that said, it’s time to change our lens and talk about how to work the system. Technical interviews are here to stay, and if you want a job at a top-tier tech company, you have to jump through this hoop.