How Interviewers Tell Memorization From Understanding (It's the Follow-Up Questions)

There's a worry I've heard from almost everyone I've coached for coding interviews, usually phrased as some version of "what if they can tell I've seen this problem before?" The fear underneath it is that recognizing the question, or reaching for a pattern you deliberately drilled, will come across as cheating, and that the writeup afterward will contain the word memorized. The worry is aimed at the wrong thing. Interviewers fully expect you to arrive with drilled patterns; that is what preparation is, and most of us prepped the same way when it was our turn. What an interviewer wants to know is whether you understand the solution you just gave, and in my experience nobody finds that out by asking. We find it out by changing the problem.

The move is consistent enough across interviewers to have a name: perturbation. You present your solution, and instead of anyone accusing you of anything, the question shifts a little. A constraint changes, a comparison gets requested, the input grows by an order of magnitude. What happens in the next ninety seconds tells the interviewer more about your understanding than the entire first solution did, and the two possible outcomes are surprisingly easy to tell apart just by listening.

The three follow-ups interviewers reach for

Practices vary, and not every interviewer runs all of these, but at the reasonably well-run companies I've seen, some combination of three moves shows up in most coding interviews once a working solution is on the table.

Change a constraint. "Suppose the input arrives as a stream now." "Suppose duplicates are allowed." "Suppose k is about half of n." The change is small on purpose, chosen so that the drilled solution no longer applies word for word while the idea underneath it still does. Someone who understands the idea adjusts the affected part and keeps the rest. Someone replaying a script has no way to know which part was affected.

Ask about the runner-up. "Why not just sort it?" "You went straight to BFS, what would DFS have cost you here?" A person who chose their approach deliberately can defend the choice, because choosing means they weighed it against something at some point. A person who replayed a solution never made a choice, so the question has nothing to grab onto, and the answer tends to come out as "this way is better" with nothing underneath it.

Ask what breaks at 10x. Ten times the input, ten times the request rate, a tenth of the memory. This one probes whether you know which resource your solution spends and where it runs out, which is also the version of the question production traffic will eventually ask about your real code.

When the answer was memorized, the perturbation tends to shatter it: a long pause, then either the original solution restated more slowly, or the change bolted on somewhere it doesn't belong. When the answer was understood, it degrades gracefully instead, something like "okay, that breaks my assumption that the whole array is in memory, so this part has to change and the rest survives." You don't need years of interviewing to hear the difference. It's audible within a sentence or two, and it's usually what the debrief ends up being about.

Using patterns you drilled is fine and expected

The anxiety on prep forums runs in the opposite direction from what I've seen in real loops. Interviewers pick well-known problems knowing full well that candidates practice. There is no rubric line for novelty, and recognizing "contiguous substring with a condition" as a sliding-window smell is the skill the pattern trigger catalog exists to build. Saying that recognition out loud gets graded positively, as recognition.

For whatever it's worth, I can't recall a single debrief where I argued against a candidate because their solution used a well-known pattern. The debriefs that went badly on this point were about candidates who couldn't bend the pattern when the question moved, and even then the note was about adaptability rather than about the pattern itself. Where suspicion of memorization does creep into writeups is a different situation: a long silence followed by a flawless answer, which leaves the interviewer with no visible reasoning to grade. I wrote about that mechanic in talking while you code, and I've had to write the "possibly memorized" note myself in those conditions. Narrating your triggers and your plan clears most of that up before any follow-up is even needed.

A worked example, solved and then perturbed

Here's how this plays out concretely. The problem is a classic: find the kth largest element in an array. Most people who've prepped seriously have the standard answer ready, and it's a good one. Keep a min-heap of size k, push each element, pop whenever the heap grows past k, and the root at the end is your answer, O(n log k) time and O(k) space. Suppose two candidates both produce exactly that, clean and correct, in about the same time. Their first answers are indistinguishable; everything that separates them happens in the next five minutes. (Both transcripts below are composites of candidates I watched, with details changed.)

The interviewer asks the runner-up question: "Why not just sort the array and index from the end?"

Candidate A: "The heap is more efficient." Asked how much more efficient: a pause, then a re-explanation of how the heap works, which was not the question.

Candidate B: "Honestly, sorting is fine for a one-off on a smallish array, and it's simpler to write. It costs n log n against the heap's n log k, so the heap is worth it when k is much smaller than n, and doubly so if elements keep arriving, because a sorted array goes stale the moment anything new shows up."

Then a constraint change: "Suppose the array is ten times too big for memory."

Candidate A: hears "too big for memory," concludes the heap is dead, and starts sketching something vague about splitting the file into pieces and merging partial results. The change killed the answer, even though it didn't have to.

Candidate B: "That's actually where this approach gets stronger. The heap only ever holds k elements at a time, so I can stream the input from disk in chunks and nothing about the algorithm changes. The sorting approach is the one that dies here."

Candidate B is the one to study, because they produced no new algorithm under pressure. They simply knew why the heap worked, and that let them see that the perturbation missed everything the solution depends on. Candidate A had the same solution and no map of it, so a change anywhere looked fatal. A third probe was available if needed (suppose k is around half of n, where the heap's advantage mostly evaporates and a plain sort or quickselect becomes the better answer), but by this point the writeups have already diverged: something like "solid initial solution, could not adapt when constraints changed" for one, and "understood the tradeoffs, adapted immediately" for the other, out of an interview whose first fifteen minutes were identical.

Why the two kinds of answers behave so differently

The mechanism matters, because it tells you what to practice. A memorized solution is stored as a finished object. You can replay it faithfully, but there's nothing underneath it to consult when the question moves: no record of which assumptions it leans on, what the runner-up was, or which line pays the main cost. Understanding is mostly that missing layer: knowing that the min-heap answer depends on only ever needing k elements at once, which is the fact that survives contact with the memory constraint.

I cook a lot, and this is the same gap as the one between following a recipe and knowing the technique underneath it. Early on, a recipe was a script for me, and any deviation stranded me: the store is out of shallots, the sauce splits, the pan runs hotter than the author's did, and the recipe has no line for any of it. A few hundred dinners later, a missing shallot just triggers a substitution, because by now I know what the shallot was doing in the dish. Nobody thinks cooking from a recipe is cheating, and good cooks use recipes forever. A night that drifts off script is where you find out whether there's technique underneath, and interview follow-ups push you off script on purpose.

"Degrade gracefully" can sound like a standard you either meet or you don't, so to be clear: it does not mean solving the perturbed problem cleanly on the spot. "That breaks my assumption that everything fits in memory, so let me rework the input side and keep the heap" is strong signal even if the rework comes out rough, and getting visibly, productively stuck on a follow-up is survivable in the same way being stuck generally is. Being perturbed at all is often a good sign, since interviewers tend to escalate when the first answer was too clean to grade any further.

Why this carries more weight in 2026

There's a reason I'd weight this skill more heavily today than I would have five years ago. A polished first answer to any classic problem is now nearly free. Solution videos cover every problem you'd want to drill, prep resources have never been better, and an AI assistant will produce a textbook-clean kth-largest solution in seconds. Interviewers know all of this. I can't speak for every company, and practices vary, but in the interviews I've conducted recently and the debriefs I've sat in, a clean first solution counts for less than it used to, for the simple reason that everyone in the room knows how cheaply one can be produced. The signal has moved to the parts that can't be handed to you in advance, and the follow-ups are where those parts live. The AI-enabled interview formats (which I covered in a separate writeup) make the same shift explicit: when the assistant writes the first draft, nearly all of the grade lives in the verifying, adapting, and defending. I'd be surprised if that trend reversed.

Training for the follow-ups

The good news is that this trains directly, and the training is cheap. Three drills, in rough order of value:

1. Generate three what-ifs for every problem you solve. Before moving on from a solved practice problem, produce three perturbations yourself and answer them out loud: change one constraint (duplicates become allowed, the input becomes a stream, k grows to half of n), scale something by ten (input size, call frequency, or a tenth of the memory), and swap the goal slightly (largest becomes smallest, find-one becomes count-all). This takes about five minutes, and it turns a problem you merely recognized into one you actually understand. Generating the what-ifs is itself part of the skill, and the first week of doing it tends to feel slow, which is normal and passes.

2. Defend your approach against the runner-up, every time. Name the second-best approach and say specifically why it loses here, plus the conditions under which it would win instead. If the honest answer is "I don't know, this is just the version I learned," you've found a real gap, and filling it usually takes ten minutes of thought rather than new study material. This drill doubles as narration practice, since stating the rejected alternative out loud is valuable in the room anyway.

3. Have a mock partner mutate the question mid-solve. If you run mocks with a friend (there's a full kit for that), add one instruction to the interviewer script: around minute twenty-five, change one constraint and let it play out. This is the highest-fidelity version of the drill, because the perturbation arrives on someone else's schedule and lands on whatever you actually built, which is the one condition the solo drills can't reproduce.

None of this requires anything paid. Three self-generated what-ifs, a named runner-up per problem, and one friend with permission to move the goalposts will build the skill within a few weeks of ordinary practice. If you'd like the follow-ups generated for you, by something that listens to your solution and then pushes on the constraint you least want moved, that's the kind of practice we built Preppable around. Either way, make sure some of your prep hours go to the second question and not only the first, because in my experience the second question is the one the debrief ends up quoting. And if your first few what-ifs come out clumsy, learning to ask them is how the understanding gets built, and it comes faster than you'd expect.