---
title: The Feynman Technique for Interview Preparation (2026 Guide)
description: How to use the Feynman Technique to master technical concepts, behavioral stories, and system design before interviews.
url: https://usegreenroom.app/blog/feynman-technique-interview-preparation
last_updated: 2026-06-22
---

← Back to blog

Interview prep

# The Feynman Technique for interview preparation

June 22, 2026 · 24 min read

![The Feynman Technique for interview preparation — explain it simply or you don't understand it yet, cover from Greenroom, the AI mock interviewer](/assets/blog/feynman-technique-interview-preparation-hero.webp)

You're three weeks into interview prep. Your notes app has 140 pages on system design, your LeetCode streak is 19 days, and you can recite the CAP theorem in your sleep. Then a recruiter asks, casually, on a Tuesday: "Can you walk me through how a hash map works?" And somehow, despite reading the Wikipedia page on hash maps four separate times, what comes out of your mouth is: "So it's like... a map... that's a hash... and it hashes things... into, um, buckets." The interviewer nods politely. You both know what just happened. You didn't understand hash maps. You understood *re-reading about* hash maps, which — as it turns out — is an entirely different and much weaker skill.

This is the single most common gap in interview preparation, and it has a name: the difference between **recognition** and **explanation**. You can recognize a concept on a flashcard, nod along to a YouTube explainer, or follow a worked example line by line, and still be unable to produce that same explanation cold, out loud, to another human, under the mild adrenaline of being evaluated. The **Feynman Technique** is built specifically to close that gap. It's not a new study hack from 2024 TikTok — it's a decades-old method, named after physicist Richard Feynman, that boils down to one brutal but fair test: if you can't explain it simply, you don't understand it yet. This guide covers exactly how to apply the **Feynman Technique for interview preparation** — for data structures and algorithms, system design, behavioral stories, and the project deep-dives that trip up even strong candidates — with worked examples for each.

## What the Feynman Technique actually is

Richard Feynman won a Nobel Prize in physics and was, by every account from people who studied under him, an unusually gifted *explainer* — not because he dumbed things down, but because he refused to accept his own understanding of something until he could rebuild it from first principles, in plain language, without leaning on jargon as a crutch. The technique that bears his name (formalized later by writers studying his teaching notes, not literally invented by Feynman as a numbered list) has four steps:

1. **Pick a concept and teach it, out loud, as if to someone who knows nothing about it.** Not a peer. Not a fellow engineer. A smart twelve-year-old, or a non-technical friend, or — when neither is available — an empty room and your own voice.
2. **Notice exactly where you get stuck.** Where you reach for jargon instead of plain words, where you trail off, where you say "and then it just... does the thing" — that stumble is the precise location of a gap in your understanding. It is not vague. It is a specific sentence you couldn't finish.
3. **Go back to the source material and re-study just that gap.** Not the whole topic again — the exact thing that made you stumble. This is the step most people skip, because it's tempting to re-read the whole chapter instead of isolating the one paragraph that actually matters.
4. **Simplify and add an analogy.** Once you've patched the gap, re-explain the whole thing again, this time with a concrete comparison to something ordinary — and strip out any remaining jargon you were using as a substitute for genuine understanding.

Then you loop. You'll usually hit a second, smaller stumble on the re-explanation — that's normal, and it's the technique working, not failing. Two or three loops on a meaty topic (recursion, the CAP theorem, a system design trade-off) is typical before the explanation comes out clean.

![The Feynman Technique as a repeatable loop — teach it plainly, find the gap, go back and simplify, re-explain with an analogy](/assets/blog/feynman-technique-interview-preparation-diagram.webp)

The loop in one picture: teach, find the gap, simplify, re-explain — repeat until the jargon stops leaking out.

The reason this works for interview prep specifically, more than almost any other study method, is that **interviews are an oral exam**, not a written one. You will never be handed a multiple-choice quiz on binary search trees. You will be asked to explain your reasoning, live, to a person who can — and will — interrupt with a follow-up the moment something sounds memorized rather than understood. The Feynman Technique is the only popular study method that rehearses the *exact modality* you'll be tested in: speaking a concept aloud, under the implicit pressure of being heard, to someone who might ask "wait, why?"

## Why this matters more in interviews than in school

In a university exam, you can partially understand a topic and still pass — recognize the right formula, plug in numbers, get partial credit for showing work. Interviews don't grade on a curve like that. An interviewer who asks "explain how a hash map resolves collisions" isn't checking whether you've seen the term before. They're checking whether you can produce a clear mental model of it, live, and then survive a follow-up like "what if every key hashed to the same bucket — what's your big-O now?" That follow-up is specifically designed to find the edge of your understanding, and a person who memorized the happy-path explanation has nowhere to go when the question moves one step sideways.

This is also why so many smart, hardworking candidates bomb interviews despite genuinely knowing the material *better* than their interview performance suggests. They've built real understanding through doing — building projects, solving problems, reading source code — but they've never rehearsed the specific skill of **producing a clean verbal explanation on demand**. Doing is a different skill from explaining-while-doing-it, and explaining-while-doing-it is a different skill again from explaining-it-to-someone-watching-you-think. The Feynman Technique trains exactly that third, narrowest, most interview-relevant skill — and it's the one almost nobody deliberately practices, because it's mildly uncomfortable and doesn't feel like "real" studying. Reading seven Medium articles on system design feels productive. Standing in your kitchen explaining sharding out loud to nobody feels a little silly. The second one is what actually moves the needle.

## Applying the Feynman Technique to technical concepts

This is the most natural fit for the technique, and the one most candidates have at least half-heard of, usually as "explain it to a five-year-old." Here's the worked version, step by step, with a real topic.

### Worked example: explaining how a hash map works

**Step 1 — teach it plainly.** Try, out loud: "A hash map is a way to store information so you can find it instantly, instead of checking every item one by one. You take whatever you're storing — say, a name — and you run it through a function that turns it into a number. That number tells you exactly which 'slot' to put it in. Later, when you want to look up that name again, you run it through the same function, get the same number, and go straight to that slot — no searching required."

**Step 2 — find the stumble.** A common one here: "...and if two things hash to the same slot, you just... handle it." That's the gap. "Just handle it" is the sound of jargon-shaped hand-waving covering an actual hole.

**Step 3 — go back and study just the gap.** This means actually reading about **collision resolution** specifically — chaining (each slot holds a small list of everything that landed there) versus open addressing (if a slot's full, probe forward to the next one) — not re-reading the whole hash map article from the top.

**Step 4 — re-explain with an analogy.** "It's like a library that assigns books to shelves by the first letter of the author's last name. Most shelves get one or two books — quick to scan. But if every author starts with 'S,' that shelf gets crowded, and finding a specific book on it takes longer — that's a collision, and a good hashing function tries to spread authors evenly across shelves so no one shelf gets overloaded."

Notice what happened: the analogy isn't decoration. It's a forcing function. You cannot map "hash map" onto "library shelving system" while still hiding behind words like "handle it" — the analogy makes the gap impossible to paper over, which is exactly the point.

### A second worked pass: recursion

Recursion is a great Feynman target because it's one of the most commonly *memorized-but-not-understood* topics in technical interviews — most candidates can recite "a function that calls itself" but freeze the moment they're asked to trace through an actual call stack.

**Step 1.** "Recursion is when a function solves a big problem by calling a smaller version of itself, until the problem is small enough to answer directly."

**Step 2 — stumble.** "...and then it, uh, returns back up and combines the answers?" — vague, no specifics on *how* the combining happens or what's actually happening to the call stack.

**Step 3.** Go re-study the call stack specifically — how each recursive call gets its own stack frame, how the function "pauses" at the recursive call and waits for the deeper call to return before it can finish its own line of execution.

**Step 4 — re-explain with analogy.** "Imagine you're handed a stack of nested gift boxes and told to find what's inside the smallest one. You can't open box 5 and report back until you've opened box 4, which means opening box 3 first, all the way down to box 1. Each unopened box is a paused task, waiting on the one inside it — that stack of waiting, unopened boxes is the call stack. The base case is the smallest box, the one with an actual gift instead of another box inside."

If you want a deeper dive specifically on recursion and its close cousin backtracking, with the call-tree visual that makes this even more concrete, see our [recursion and backtracking interview guide](/blog/recursion-backtracking-interview-questions) — it's a natural Feynman target precisely because the call tree *is* a diagram of where most people's mental model goes blurry.

### Topics where this technique pays off hardest

Some concepts are disproportionately rewarding to Feynman-ize, because they're exactly the ones interviewers love probing with a follow-up that exposes shallow understanding:

- **Closures** — most candidates can say "a function that remembers its scope," almost none can explain *why* that matters without an analogy (a backpack the function carries with it, containing the variables it needed at creation time).
- **The event loop / async behavior** — "JavaScript is single-threaded but handles async stuff" is a definition, not an explanation. Tracing through *why* a `Promise.resolve().then()` runs before a `setTimeout(fn, 0)` forces real understanding of the microtask/macrotask queue.
- **Big-O notation** — anyone can say "O(n) means linear." Far fewer can explain, on the fly, why nested loops over the same input give you O(n²) and why halving the input each step gives you O(log n). Our [Big-O and time complexity guide](/blog/big-o-notation-time-complexity-interview-questions) has the growth-curve breakdown that's worth Feynman-izing piece by piece.
- **Database indexing** — "it makes queries faster" is true and useless. Explaining *how* a B-tree index avoids a full table scan, with an analogy to a phone book sorted alphabetically versus one in random order, is the version that survives a follow-up.
- **CAP theorem** — almost every candidate can name "consistency, availability, partition tolerance." Almost none can explain, with a concrete example, *why* you can't have all three during a network partition, and what that trade-off actually looks like in a real distributed system.

## Applying the Feynman Technique to behavioral stories

This is the part most prep guides skip, and it's a mistake, because behavioral interviews fail candidates just as often as technical ones — usually for the exact same root cause. A candidate has a great story buried in their head ("I once resolved a conflict between two senior engineers about which caching strategy to use") but has never said it out loud in full, so in the actual interview it comes out as a meandering, three-minute ramble that loses the interviewer somewhere around minute two.

The STAR framework (situation, task, action, result) tells you *what shape* your answer should have. The Feynman Technique tells you how to actually get there: explain the story out loud, notice exactly where you stall or ramble, go back and tighten that specific part, then re-tell it.

### Worked example: a behavioral story

**Step 1 — tell the story plainly, out loud, to an empty room or a friend.** "So there was this thing at my last job where two senior engineers disagreed about caching, and I sort of had to step in, and... well, it was complicated, there was a lot going on, the team was kind of split, and eventually we picked Redis over Memcached, and it worked out fine."

**Step 2 — find the stumble.** Two stumbles here, actually: (1) "it was complicated, there was a lot going on" — that's the sound of skipping the actual decision logic because you haven't crystallized it; (2) "it worked out fine" — no measurable result, which is the single most common behavioral-answer weakness.

**Step 3 — go back and fill in just those gaps.** What were the two actual positions? What was the deciding factor — latency, cost, team familiarity? What changed, with a number, after the decision shipped? This isn't re-writing the whole story; it's answering two specific questions you skipped.

**Step 4 — re-tell it, tightened.** "Two senior engineers disagreed on our caching layer — one wanted Memcached for simplicity, one wanted Redis for its data structures. I set up a 30-minute working session where each presented their case against our actual traffic pattern, not in the abstract. Redis won because we needed sorted sets for a leaderboard feature shipping the same quarter — a need Memcached genuinely couldn't serve well. We shipped it, and the leaderboard feature came in two weeks ahead of the original estimate because we weren't building sorted-set logic by hand on top of Memcached."

That's a story an interviewer can follow on first listen, with a concrete decision criterion and a real result — and it took exactly one Feynman loop to get there from the rambling version. For more on tightening this specific skill, [behavioral STAR answers for senior engineers](/blog/behavioral-star-answers-senior-engineers) goes deeper into why STAR is a good scaffold and a bad ceiling once you're past a certain seniority — the Feynman loop is how you find the parts of your story that need to go *beyond* the scaffold.

### Why "tell it to someone, not just think it through" matters here specifically

It's tempting to think you can do this step mentally — just review the story in your head and notice the weak parts. This doesn't work nearly as well, for a reason that's specific to behavioral stories: **the stumble only reveals itself under the actual cognitive load of real-time speech production.** When you think through a story silently, your brain smooths over gaps automatically, because thinking doesn't require committing to a specific sentence the way speaking does. Only when you're forced to actually produce the next clause out loud — live, with no backspace key — does the gap become audible as a stall, a filler word, or a vague gesture ("...and stuff like that"). This is the exact mechanism behind why reading your notes feels like mastery and speaking them out loud reveals it isn't.

## Applying the Feynman Technique to system design

System design rounds are arguably where the recognition-versus-explanation gap is widest, because system design knowledge is unusually easy to *recognize* (you've read about load balancers, you know what sharding means) and unusually hard to *produce from scratch under pressure* (laying out an actual architecture, live, while fielding "what happens if that service goes down" follow-ups).

### Worked example: explaining how you'd shard a database

**Step 1.** "So sharding is when you split your database across multiple machines so no single one has to hold everything, and you use some kind of key to figure out which shard a row goes to."

**Step 2 — stumble.** "...and then if you need to query across shards it's, um, more complicated" — this is the tell. "More complicated" is exactly the phrase that means you haven't actually thought through cross-shard queries, which is precisely the follow-up an interviewer will ask next.

**Step 3.** Go study specifically: what does a cross-shard query actually require (scatter-gather across shards, then merge results in the application layer), and what's the real cost of getting the shard key wrong (hot shards — one machine taking disproportionate load because the key distribution isn't even).

**Step 4 — re-explain with the gap filled.** "We'd shard by user ID, hashed, so each user's data lives on one shard — that makes single-user queries fast since they hit exactly one machine. The trade-off is any query that spans users — like 'show me all orders placed in the last hour across all users' — now has to fan out to every shard, collect partial results, and merge them in the application layer, which is slower and more complex than a single-database query. We'd mitigate that by keeping a separate, denormalized read-optimized table for the cross-user reporting use case, rather than trying to make the sharded primary database serve both access patterns well."

This is a meaningfully stronger answer than the first pass, and the difference isn't more knowledge — it's that the Feynman loop forced the trade-off (which is the actual thing senior interviewers are listening for) out of "more complicated" hand-waving into a concrete, defensible decision. Our [guide to what system design interviews actually test](/blog/system-design-interviews-what-they-test) covers the broader framework — requirements, estimation, high-level sketch, deep dive, failure modes — and the Feynman loop is specifically how you stress-test the "deep dive" step before the real interview does it for you.

### Run the loop against your own architecture diagrams

A particularly effective drill: take a system design diagram you've drawn (or a famous one — "design Twitter," "design a URL shortener") and narrate it out loud, component by component, as if explaining it to someone who's never seen a system diagram before. Every box you can't explain the *purpose* of in one sentence — not just name, purpose — is a gap. Most people discover they can correctly draw a load balancer box but can't actually explain why a round-robin algorithm might be worse than least-connections for their specific traffic pattern. That's the gap the technique is designed to surface.

## Applying the Feynman Technique to your own projects

This is the sneakiest place the recognition/explanation gap shows up, because it feels like it shouldn't apply — it's *your own project*, you built it, how could you not understand it? But "I built it" and "I can explain every decision in it on demand, including the ones I made eighteen months ago and have half-forgotten the reasoning for" are different claims. Interviewers who dig into your GitHub repos are specifically hunting for this gap.

### Worked example: explaining a design decision in your own code

**Step 1.** "I used Redis for session caching in this project because... it's fast, and that's what people usually use for caching."

**Step 2 — stumble.** "That's what people usually use" is the giveaway — it's a borrowed justification, not a reasoned one. If you can't say *why*, for *your* traffic pattern, you didn't make the decision — you copied it.

**Step 3.** Go back to the actual project and actually answer: what was the alternative (in-memory cache on the app server? Memcached? a database-backed session store?) and what specifically made Redis the right call (persistence across restarts? pub/sub for invalidating sessions across multiple app instances? the data structure support for something specific you needed?).

**Step 4.** "I used Redis specifically because we ran three app server instances behind a load balancer, and an in-process cache would mean a user's session could be invisible to two of the three instances depending on which one they hit. Redis gave us a single shared cache all three instances could read from, plus built-in expiry so I didn't have to write my own session-cleanup job."

This is also exactly the kind of follow-up Greenroom's interviewer asks when it sees a real dependency in your repo — not "what is Redis" but "what happens to logins when it goes down," which only a candidate who's actually done the Feynman loop on their own decisions can answer cleanly. [Talking about your GitHub projects in interviews](/blog/talk-about-github-projects-in-interviews) covers this pattern in more depth — the technique here is identical to the system design version, just pointed at decisions you already made instead of ones you're designing live.

<div class="verdict"><strong>The core truth:</strong> "I built it" is not the same claim as "I can defend every decision in it." The Feynman loop is how you find out, before an interviewer finds out for you, which of your own project decisions you've actually internalized versus copied from a tutorial.</div>

## Two more worked examples, because the pattern needs repetition to stick

### Garbage collection

**Step 1.** "Garbage collection is when the language automatically frees up memory you're not using anymore, so you don't have to do it manually like in C."

**Step 2 — stumble.** "...it just, like, figures out what's not being used and cleans it up" — "figures out" is doing all the work here, and it's doing none of the explaining.

**Step 3.** Go study specifically how a mark-and-sweep collector decides what's "not being used" — it starts from a set of roots (global variables, currently-executing function's local variables) and walks every reference reachable from those roots, marking each object it finds; anything left unmarked after that walk is, by definition, unreachable from any live code path, and gets swept.

**Step 4 — re-explain with analogy.** "It's like cleaning out a shared office storage room by starting from the people who currently work there, walking through every box they actually still reference — files, supplies, whatever's chained to something they use — and marking those boxes as 'keep.' Anything left unmarked after that walk isn't connected to anyone currently working, so it's safe to throw out, even if it still technically has stuff in it. The walk has to start from real, currently-active people — the 'roots' — or you'd risk marking an actually-used box as junk."

### Load balancing algorithms

**Step 1.** "A load balancer spreads incoming requests across multiple servers so no one server gets overwhelmed."

**Step 2 — stumble.** "...and it picks which server using some algorithm" — true, useless, and exactly the kind of answer that invites the follow-up "which algorithm, and when would you pick a different one?"

**Step 3.** Go study the actual trade-off between round-robin (cycles through servers in order — simple, but blind to how busy each server actually is) and least-connections (routes to whichever server currently has the fewest active connections — better when requests vary wildly in how long they take to handle).

**Step 4 — re-explain with the gap filled.** "Round-robin is the simplest option — it just rotates through servers in order, which works well when every request takes roughly the same amount of time to process. But if some requests are quick lookups and others are long-running report generations, round-robin can stack several slow requests onto the same server while a faster one sits idle. Least-connections fixes that by routing each new request to whichever server currently has the fewest open connections — it actually responds to real load instead of assuming every request is the same size."

These two examples exist for a specific reason: the failure pattern repeats almost identically across completely unrelated technical topics. The stumble is always a vague verb doing the work a specific mechanism should be doing — "figures out," "handles it," "picks," "more complicated." Once you can hear that pattern in your own explanations, you can catch it on nearly any topic without needing a worked example to follow.

## How interviewer follow-ups mirror step two of the technique

It's worth naming explicitly why a good interviewer's follow-up question feels uncannily similar to the moment you catch yourself stumbling in solo Feynman practice — it's because they're doing the same diagnostic. An interviewer who asks "what happens if every key hashes to the same bucket?" right after your hash map explanation isn't being adversarial; they're doing, externally and on your behalf, exactly what step two of the Feynman loop asks you to do for yourself: locating the edge of your understanding and pressing on it.

This reframes interview follow-up questions from something to dread into something genuinely useful to anticipate. Before an interview, it's worth explicitly asking yourself, for every topic on your list: *if I were the interviewer listening to my own explanation, what's the first follow-up I'd ask?* Usually, it's the exact spot where your explanation got vaguest — which means you've essentially run step two of the Feynman loop on yourself, in advance, by imagining the adversary. Then go run step three and four on whatever that follow-up exposed, before the real interview gets the chance to expose it for you.

This is also the single biggest reason solo flashcard or article-reading prep underperforms relative to actually rehearsing explanations: flashcards never ask a follow-up. They confirm you know the headline fact and stop there, which means the part of your knowledge that interviews actually probe — the second layer, the "okay but why" layer — never gets exercised until the real interview, which is the worst possible time to discover it's missing.

## Keeping a gap log

One small addition that compounds the value of the technique over a multi-week prep cycle: keep a running, dated list of every gap you find. Not a polished study guide — just a flat list: date, topic, the specific thing you stumbled on, one line on what fixed it. After two or three weeks, this log becomes more valuable than almost any other prep artifact you'll produce, for two reasons.

First, it's a near-perfect predictor of what an interviewer will ask, because the things you personally find hardest to explain cleanly tend to be the things that are *genuinely* subtle, not just unfamiliar to you specifically — collision resolution, cross-shard queries, the deciding factor in a behavioral story. Other candidates stumble on the same spots for the same structural reasons. Second, reviewing the log the night before an interview is a far better use of twenty minutes than re-reading a textbook chapter, because it's a list exclusively of things you've already proven you don't yet have a clean handle on — there's no wasted review time on things you already explain fluently.

A simple format works fine: a plain text file or a notes app entry per day, three or four lines each. The discipline of writing it down — not just noticing the gap mentally — matters more than the format, because writing forces you to articulate the gap precisely enough to look it up later, which is itself a small Feynman loop on the act of identifying your own gaps.

## How the Feynman Technique compares to other prep methods

It's worth being honest about where this technique fits relative to the other tools in a typical candidate's prep stack, because it's not a replacement for any of them — it's a finishing layer.

**Versus flashcards and spaced repetition (Anki, Quizlet).** Flashcards are excellent for memorizing discrete facts — syntax, terminology, the names of sorting algorithms and their complexities. They are close to useless for verifying you can *produce a coherent explanation*, because recognizing the right answer on a card and generating that explanation unprompted, in your own words, under time pressure, are different cognitive tasks. Use flashcards to load the facts; use the Feynman Technique to verify you can actually deploy them.

**Versus a GeeksforGeeks-style question dump.** Reading through a list of "Top 50 System Design Interview Questions" is a good way to discover *what* you don't know, but a bad way to find out *how deeply* you don't know it. You can read an answer, nod, feel like you understood it, and then discover in your own attempt to re-explain it that you actually only understood the specific phrasing the article used — a brittle, surface-level kind of knowledge that breaks the moment an interviewer rephrases the question.

**Versus LeetCode grinding.** Solving 300 LeetCode problems builds real pattern recognition and genuine problem-solving speed — it is not a substitute for the Feynman Technique, and the Feynman Technique is not a substitute for it either. They train different things: LeetCode trains *doing*; Feynman trains *explaining what you did and why, out loud, afterward*. A candidate who's solved 300 problems but never practiced narrating their approach out loud will still stumble on "walk me through your thinking" — which is, not coincidentally, the exact phrase that opens almost every live coding interview.

**Versus a friend's WhatsApp PDF of "interview questions and model answers."** These are useful as a checklist of topics to cover, and actively harmful if you mistake reading the model answer for being able to produce it yourself. The honest move is to use the PDF to pick topics, then close it and Feynman-explain each one from memory before checking your explanation against theirs.

**Versus generic ChatGPT prompting.** Asking an LLM to "explain recursion simply" gives you a clean explanation to *read* — which is exactly the recognition trap this whole guide is about. Reading someone else's clear explanation (human or AI) is genuinely useful for the *third* Feynman step — going back to fix a specific gap — but it cannot substitute for steps one, two, and four, which require *your own* mouth producing *your own* explanation and stumbling on *your own* gaps. An AI's explanation tells you what a good explanation sounds like; it doesn't tell you whether you can produce one.

**Versus a real mock interview.** This is the closest cousin to the Feynman Technique, and the most important comparison to get right: a mock interview is the Feynman Technique with an added, crucial ingredient — an interlocutor who asks follow-up questions you didn't anticipate. Practicing alone, you control which gap you go looking for; you can accidentally avoid your own weak spots without realizing it. A real interviewer (or a well-built AI one) probes the exact spot where your explanation got vague, the way a real interview will. [How to practice mock interviews alone](/blog/how-to-practice-mock-interviews-alone) is the right companion piece if you're doing the Feynman loop solo — it covers how to simulate the follow-up-question pressure without another human in the room. [Greenroom](/) goes a step further: it runs spoken mock interviews that ask real follow-ups on your actual explanations, the same gap-finding mechanism as step two of the Feynman loop, except powered by a system specifically built to notice when an answer is reciting versus reasoning — which, frankly, is a harder and more honest judge of your own stumbling than an empty kitchen.

## A practical weekly routine

Theory is fine; here's how to actually build this into a prep schedule without it eating your whole week.

**Daily (10–15 minutes).** Pick one concept from your study list — a data structure, a system design pattern, one behavioral story. Set a timer, explain it out loud to your phone's voice recorder or an empty room, no notes. Listen back once, specifically hunting for the stumble — the filler word, the "and then it just does the thing," the place your voice trails off. Note the gap in one sentence. That's the whole session.

**2–3 times a week (20 minutes).** Go back to the specific gaps you logged and actually study just those — not the whole topic again. Then re-record the explanation. Compare the new recording to the old one; you should be able to hear the difference in confidence and specificity, which is a genuinely satisfying thing to notice and a good signal you're on track.

**Weekly (30–45 minutes).** Do a Feynman pass on a full system design problem or a full behavioral story end to end, since these are long enough that the gap often hides in the transitions *between* sections, not within any single piece — the part where you go from "here's our database choice" to "here's how we'd scale it" is exactly where a rehearsed answer reveals it was never actually connected reasoning.

**Before the actual interview week.** Run the loop once more on your three or four most likely topics, but this time with someone else listening — a friend, a study partner, or a mock interview that can ask a real follow-up. This is the step that catches the gaps you've genuinely stopped being able to see in your own explanation, because you've now rehearsed it enough times that it *sounds* fluent to you even where it's still thin.

### Stacking the routine onto an existing prep schedule

Most candidates already have a prep schedule built around problem-solving practice — a LeetCode set, a system design reading list, a stack of behavioral stories drafted in a doc. The Feynman routine above isn't meant to replace any of that; it's meant to sit at the *end* of each study session, as a five-minute close-out rather than a separate block of time you have to carve out. Solved three LeetCode problems today? Before closing the laptop, pick the trickiest one and explain your approach out loud as if to someone who's never seen the problem — not the code, the reasoning. Read a system design article on consistent hashing? Close the tab and narrate it back without looking, then check the article again only for whatever you couldn't reproduce. This framing matters because the technique fails most often not because people disagree with it, but because they treat it as an extra commitment competing for the same hour as everything else, and it loses. Five minutes tacked onto something you were already doing survives; a standalone thirty-minute "Feynman session" on the calendar gets skipped the first busy week.

## Common mistakes when applying the technique

**Explaining it in your head instead of out loud.** This defeats the entire mechanism. The stumble only surfaces under the real-time pressure of speech production — silent review lets your brain smooth over gaps automatically.

**Re-studying the whole topic instead of just the gap.** If you stumbled on one specific sub-point — collision resolution, the microtask queue, the cross-shard query problem — go fix that specific thing. Re-reading the entire chapter again is comfortable and inefficient; it's also a sneaky form of procrastination dressed up as diligence.

**Skipping the analogy step.** The analogy isn't a nice-to-have flourish for making your explanation friendlier — it's a forcing function that makes hidden jargon-as-crutch impossible to hide. If you can't map your explanation onto something ordinary, you likely still have a gap you haven't found yet.

**Doing it once and calling it done.** One loop on a meaty topic almost never gets you to a clean explanation. Two or three loops is normal and expected — the diminishing-stumbles pattern (big gap, then a smaller gap, then a clean run) is what mastery via this technique actually feels like.

**Only ever explaining to yourself.** Self-explanation catches a real share of gaps, but a listener — human or a well-designed AI interviewer — catches the ones you've gotten too comfortable with to notice, plus asks the follow-up question you didn't think to ask yourself. This is the single biggest limitation of solo Feynman practice, and it's exactly the gap a real mock interview closes.

## Practise the explaining, not just the studying

Everything in this guide points at the same underlying truth: understanding that only exists in your head, verified only by your own silent nod of recognition, is not the same asset as understanding you can produce on demand, out loud, while someone is actively listening for the seams. The Feynman Technique is how you build the second kind — and an interview is the one place in your life where only the second kind counts. [Greenroom](/) runs spoken mock interviews — technical, behavioral, and system design — that ask real follow-up questions on your answers, which is the closest thing to having someone else run the "find the gap" step of the Feynman loop for you, at the exact moment a real interviewer would. Pair the daily Feynman habit above with [coding interview communication tips](/blog/coding-interview-communication-tips) for the delivery side, and [how to prepare for a mock interview](/blog/how-to-prepare-for-a-mock-interview) for how to structure the practice sessions themselves.

## Frequently asked questions

### What is the Feynman Technique for interview preparation?

The Feynman Technique is a four-step study method — explain a concept plainly out loud, notice exactly where you stumble, go back and re-study just that gap, then re-explain it with a simplified analogy — applied to interview prep topics like data structures, system design, behavioral stories, and your own projects. It works because interviews test your ability to produce a clear explanation live, not your ability to recognize a correct answer on a page.

### How is the Feynman Technique different from just re-reading my notes?

Re-reading notes tests recognition — whether the material feels familiar when you see it again. The Feynman Technique tests production — whether you can generate that same explanation yourself, out loud, in your own words, without the source material in front of you. Many candidates discover a topic they "knew" from notes falls apart the moment they try to explain it from scratch, which is exactly the gap the technique is designed to expose before an interviewer finds it.

### Can I use the Feynman Technique for behavioral interview questions, not just technical ones?

Yes — and it's one of the most underused applications of the technique. Telling a behavioral story out loud and noticing exactly where you ramble, lose the thread, or skip the actual decision logic reveals the same kind of gap as a technical explanation. The fix is identical: go back, fill in the specific missing piece (usually the deciding factor or the measurable result), and re-tell the story tightened.

### How many times should I loop through the Feynman steps on one topic?

Most meaty interview topics — recursion, sharding, a behavioral story, the CAP theorem — take two or three loops before the explanation comes out clean with no stumbles. One loop on a genuinely complex topic is rarely enough; if your first re-explanation still has a stumble, that's normal and expected, not a sign you're doing it wrong.

### Is the Feynman Technique a replacement for mock interviews?

No — they're complementary, and mock interviews are arguably the stronger of the two because they add a real follow-up question you didn't anticipate, which is exactly the kind of gap-finder solo practice can miss. Use the Feynman Technique daily to prep individual concepts and stories, then validate with a real or AI-driven mock interview that can probe your explanation the way an actual interviewer would.

### What topics benefit most from the Feynman Technique?

Topics with a high rate of "recognized but not understood" responses benefit most: closures, the event loop, Big-O reasoning, database indexing, the CAP theorem, system design trade-offs, and any technical decision in your own past projects you can't immediately justify with a specific reason. If you notice yourself reaching for vague phrases like "it just handles it" or "it's more complicated," that topic is a strong Feynman candidate.

Interviews test whether you can explain your thinking out loud, under a real follow-up question. Greenroom runs spoken mock interviews across technical, behavioral, and system design rounds, and asks follow-ups on your actual answers. Free to start.