You've Seen This Coding Interview Problem Before. Now What?

You see the problem on the screen and your stomach does something weird. Not the dread of staring down an unfamiliar graph problem you have no business attempting in forty-five minutes. The opposite. Relief washes over you. Then, almost immediately, a different and worse kind of dread.

You've done this one. Two-pointer trick on a sorted array, or maybe it's the classic sliding window you've ground through fifteen times on four different platforms. You know the data structure. You know the time complexity before you've written a character. You might even remember which LeetCode number it is.

And that's exactly where a lot of candidates quietly blow the interview.

Prior knowledge is not the unfair advantage it feels like. The interview isn't measuring whether you can produce the answer. It's measuring how you think and communicate while you get there. Skip that demonstration because you already know where you're going, and you can fail a problem you know cold.

The Disclosure Question Is the Wrong Question

Candidates spend whole forum threads agonizing over whether to tell the interviewer they've seen the problem. The answer is: it matters much less than you think.

If the interviewer directly asks whether you've seen it, tell the truth. Lying to a direct question is a character signal that overrides everything else. You don't get hired on the basis of a single algorithm question. You do get unhired on the basis of getting caught in a lie.

If they don't ask, you don't owe them an unprompted confession. Studying real problems is normal and expected. Every candidate who passes a LeetCode-heavy loop has seen some percentage of the problems. The assumption is baked in. Interviewers know.

A useful middle path, if you feel uneasy: early in your approach, say "this structure feels familiar from something I've worked through before" and keep going. Honest without being theatrical. Nobody needs a confessional booth.

What you should not do is pretend the problem is a complete mystery and perform a scripted "discovery" of the optimal solution without any real reasoning. Interviewers who've asked the same problem dozens of times know what genuine problem-solving sounds like. A rehearsed performance without process is an integrity red flag on top of a process red flag. It's the worst combo. You lose points for both.

What Speed Without Process Signals

When a candidate solves a hard dynamic programming problem in ninety seconds without narrating a single thought, interviewers notice. Not because speed is suspicious on its own. Because speed without process is a tell.

Genuine problem-solving has noise. A real engineer pauses, asks a question, considers the naive approach, rejects it, tries another angle. They say things like "my first instinct is a nested loop but that's O(n²), which probably isn't acceptable here." They think out loud about whether a hash set or a sorted structure fits better.

When all that texture is missing and the optimal solution appears in sixty seconds, interviewers pivot to harder follow-ups. They modify the problem. They ask why you chose that data structure. They ask what happens if the constraint changes. A candidate who genuinely solved it can answer those questions. A candidate who retrieved a memorized solution often can't, because retrieval skipped understanding. Cue the awkward silence.

Shooting star meme: I wish I could ace the interview without grinding LeetCode

The wish is relatable. But interviewers can tell the difference between someone who ground it out and someone who memorized the punchline.

Speed also puts you in a tactically bad spot. Finish in two minutes, and you're looking at thirty-plus minutes of variants you weren't expecting. The candidate who spent eight minutes with visible reasoning usually handles the pivot better, because they built the understanding, not just the answer.

Run the Playbook for Real

When you recognize a problem, run the exact same interview playbook you'd run on any other problem. Not a performance of it. The actual thing.

Start by restating the problem. You're checking your mental model against the exact version they're asking, because problems with the same shape can have different constraints. Can the input contain duplicates? Is the array guaranteed sorted? What should you return when there's no solution?

These questions are worth asking even when you know the standard version. Interviewers sometimes add a wrinkle that the problem you practiced didn't have, and if you charged ahead assuming you knew it, you'd code the wrong solution with perfect confidence. Nothing is sadder than optimally solving the wrong problem.

Then give the brute force. Always. Even when you can already see the optimal answer. Say something like "the naive approach here is two nested loops, O(n²). Let me think about what's redundant in that." Then think out loud about the redundancy. Arrive at the optimization through visible reasoning rather than by conjuring it from the ether.

This is not faking ignorance. This is demonstrating the habit that actually matters at the job: knowing what the naive solution looks like before you optimize, explaining why the optimization works, not just pattern-matching to a memorized trick. The brute force narration also buys you time if anything about their version differs from what you practiced.

Clarifying Questions You Actually Mean

There's a version of clarifying questions that is pure theater. Candidates who've memorized the "ask clarifying questions" advice ask three pointless questions about edge cases that don't affect the solution, then code the thing they were going to code anyway. The interviewer has seen this bit. It doesn't land.

The useful version is different. On a familiar problem, constraints still matter. Ask because they genuinely change your approach.

"What's the expected input size? I want to make sure my solution fits the constraints."
"Can elements be negative, or are we working with positive integers only?"
"Should I handle the empty input case, or can we assume the array is non-empty?"

These are real questions. Whether elements can be negative actually changes which approaches are valid. On a sliding window problem, negatives can break the invariant that shrinking the window always helps. On a prefix sum problem, negatives mean you can't short-circuit early.

You can read more about what clarifying questions signal to interviewers in Ask These Clarifying Questions First. The short version: a question with a real answer is always better than one you're asking to fill time.

After the questions, before the code, say what you're about to do. "I'm going to use a hash map to track frequencies as I scan left to right, O(n) time and O(n) space. Want me to walk through the approach first, or go straight to implementation?" This pause is where interviewers give you signals. It also demonstrates the kind of collaboration that shows up on actual rubrics.

What the Rubric Is Actually Measuring

Most FAANG-style interview rubrics evaluate four things: communication, problem solving, technical competency, and testing. The correct algorithm is one component of technical competency. It's not close to the whole score.

Communication covers whether you asked good questions and explained your approach clearly. Problem solving covers whether you considered multiple approaches, identified complexity correctly, and explained tradeoffs.

A candidate who knows the optimal solution but communicates nothing can score worse than a candidate who reaches a suboptimal solution while narrating clearly. Rubrics are built this way because design discussions, code reviews, and debugging sessions at the actual job have the same shape. The process of thinking is the product.

Your prior knowledge is less valuable than you think if you use it to skip the demonstration. Its real value is freeing up cognitive space. You spend less energy on "will I find an approach at all" and more on communicating clearly and handling follow-ups. That's the leverage. Use it.

At SpaceComplexity, we structure mock interviews around rubric-based feedback across all four dimensions, not just whether the algorithm was correct. That's where candidates figure out what they're actually being measured on.

When They Ask You Directly

You've been narrating, you've been genuine, and then the interviewer pauses and asks: "Have you seen this problem before?"

Say yes if you have. One sentence on where: "I've seen a version of this on LeetCode" or "I've worked through a problem with this structure in practice." Then keep going with your narration as if the answer were yes all along. Because the answer should be yes all along.

Two things usually happen next. They say "okay, let's keep going" and assess you on communication and execution regardless of familiarity. Or they swap to a different problem. Fine either way. You just demonstrated honesty under mild pressure, which is exactly the character signal they were probing for.

Lying under direct questioning is the one thing that turns a strong performance into a hard no. Not because the problem is sacred. Because the interviewer goes back to the hiring committee and says the candidate was evasive when asked a direct question. That's a different conversation than "candidate needed hints on the optimization."

The honest answer, delivered without drama, is just the efficient move. No speech necessary.

The Part That Matters Most

Most of the anxiety about known problems is anxiety about getting caught. Caught performing something fake, skipping a process you know you're supposed to run.

The fix is simple. Just narrate.

Narrating your actual reasoning, including reasoning you've done before, is not dishonest. You can genuinely explain why two pointers work here. You can genuinely explain the O(n) proof. You can genuinely ask about edge cases and test your code methodically. None of that becomes fake because you've thought about it before.

Don't pretend the problem is new. Demonstrate the skills the interview is designed to measure. Those skills are real whether or not you've seen the problem.

For more on what goes wrong in interviews candidates think they aced, see 4 Coding Interview Mistakes That Get You Rejected Even When Your Code Works. The pattern is almost always the same: the algorithm was right, but the interviewer couldn't see the thinking.

Quick recap:

Don't volunteer disclosure unprompted, but answer honestly if asked directly
Speed without narration reads as a red flag; real problem-solving has visible texture
Run the full playbook: restate, brute force, narrate the optimization, ask real questions
Clarifying questions matter because constraints genuinely change your approach
The rubric scores communication and process as heavily as the final algorithm
Prior knowledge helps most when it frees cognitive space for better communication, not when it lets you skip the process