How to explain a project you built when the interviewer digs into the details

It is your project. You wrote most of the code, you fixed the worst bug at two in the morning, and nobody in the room knows it better. So when the interviewer asks why the cache is invalidated the way it is, it is a shock to hear an answer that felt obvious fall apart halfway through the sentence.

Psychologists have measured this gap, and knowing how it works makes it much easier to prepare for.

Why your own work is hard to explain

In a well-known set of studies, Leonid Rozenblit and Frank Keil asked Yale graduate students to rate, on a seven-point scale, how well they understood everyday devices such as a zipper, a flush toilet, a cylinder lock and a helicopter. Next the students wrote a step-by-step explanation of how each one works and rated their understanding again. The ratings dropped. They dropped further after a diagnostic question that needed real knowledge of the mechanism, for example how you would pick a cylinder lock. When the students finally read an expert’s explanation and looked back at what they had known before, the ratings stayed low. Their first sense of understanding had simply been too high (Rozenblit and Keil, 2002).

The authors call this the illusion of explanatory depth. It was much stronger for explanations than for facts, procedures or stories, and the reasons they give fit a software project almost too well. While you work, the system is in front of you, so being able to look something up feels like knowing it. You understand the top level and assume the levels under it. And you rarely have to explain the whole thing from start to finish, so you never find out where your explanation breaks.

An interview asks exactly that diagnostic question.

What interviewers are digging for

Amazon’s recruiters are blunt about the most common miss. Candidates do not go deep enough. For each question they want a detailed account of one situation, with the numbers, the people who worked on the project and the results you delivered. They also ask candidates to describe actions in the first person, because the interview is about what you did (Amazon recruiters). One of the company’s leadership principles, Dive Deep, asks people to stay connected to the details (Amazon).

Expect the same shape wherever you interview. You give a short overview, and the interviewer asks question after question, each one a level further down. The overview is the easy part. You are judged on the follow-ups.

A two-minute walkthrough

Open with the problem and the people it hurt, in one or two sentences that include the constraint that made it hard.

Search on our patient portal took close to a second, and support tickets about it doubled after the spring release.

Say in a sentence what you owned and in another what others did. Most of the two minutes belongs to two or three decisions, and for each one name the option you turned down. A decision with a rejected alternative shows judgment. A list of tools shows nothing.

We could have added replicas. I chose a precomputed index because the slow part was ranking, and replicas only help with reads.

Close with the outcome, a number and what you would change.

p95 went from about 800 milliseconds to under 200. If I did it again, I would give the rebuild job backpressure from the start.

Stop there and let the interviewer pick the thread.

Prepare the follow-up ladder

A handful of follow-ups come up in almost every project deep-dive, and each deserves a sentence or two written down before the interview. Interviewers ask why you chose this design over the obvious alternative, what the hardest bug was and how you found it, and how you knew the system worked and what you measured. They ask what happens when a dependency goes down, a job restarts halfway or the input grows tenfold, which parts you wrote, decided or reviewed yourself, and what you would do differently.

The Rozenblit and Keil test works just as well on yourself. Take the core flow of the project, a request or a job from start to finish, and write it down step by step without opening the code. Add one diagnostic question about it, such as what happens if the service restarts in the middle, and answer it. Each place you hesitate is a follow-up waiting to happen. Open the code, close the gap and write the answer as a sentence you could say aloud.

Mistakes that sink good projects

The most common one is naming technologies where you should be describing decisions. React, Node, Postgres and Redis tell the interviewer nothing about how you think. Close behind is speaking for the whole team from start to finish, when you are there to talk about your part. Many walkthroughs never mention a number. Latency, users, money, time saved or error rate, one is enough. Some candidates claim more than they did, and the next question goes one level deeper. Others explain every component. Pick the two that carried the most interesting decisions and leave the rest for questions.

Let the files do part of the work

We built Prepped partly for this. Add the project folder or GitHub repository to an interview in Prepped, and its preparation reads the files and drafts answers to the questions you are likely to get about the code, naming the file each answer comes from. Whatever the files do not support is marked, so you know what to check. The question bank also has a project structure, with the problem, your role, the key decisions and the outcome, for rehearsing the walkthrough until it fits in two minutes.