How to Handle a Coding Problem You Have Never Seen

How do you handle a coding problem you've never seen before?

Resist the urge to code. Restate the problem in your own words, work one concrete tiny example by hand, then scale that solution up. About 80% of "novel" interview problems are two known patterns stitched together — but the pattern fit is only visible after you've held a real example in your head. Working backward from a small example is the move; pattern-matching from memory rarely is.

The 4-step unfamiliar-problem protocol

Use this every time the problem looks foreign. It takes 5-7 minutes and saves you from coding the wrong thing for 25.

Step 1 — Restate in your own words (60 seconds). Paraphrase what's being asked. Don't echo the prompt verbatim. "So I have a list of meetings, each with start and end times, and I want the maximum number that can run in parallel at any single moment." This catches misreads early, which is where most "I solved the wrong problem" stories begin.

Step 2 — Work a 3-5 element example by hand (2-3 minutes). Pick a small concrete case and trace it on paper or the whiteboard. Not in your head. The act of writing the example out loud — "okay, meeting A is 1-5, B is 2-3, C is 4-7…" — surfaces structure your brain can't see while staring at the prompt.

Step 3 — Ask whether the brute force is acceptable (30 seconds). "For each minute in the time range, count active meetings. That's O(time × n). If time is bounded, it's actually fine — is the input size bounded?" Often the interviewer will say "no, do better" or "yes, that's fine for now, but show me the optimization too." Either answer is gold.

Step 4 — Map to a known pattern. Once you've worked the example, you'll notice it resembles one of: two-pointer, sliding window, sweep line, monotonic stack, BFS/DFS, dynamic programming on a small state, binary search on answer. If you can articulate "this feels like a sweep-line problem because…" you're 80% of the way to the solution.

Why pattern-matching from memory fails

Trying to recognize the pattern before working the example is the most common new-grad mistake on hard problems. You scan your memory for "I've seen this — was it the activity selection one? the meeting rooms one?" — and either you find a near-match and try to ram it into the new problem (often wrong), or you don't find one and freeze.

The fix is to invert the order. Work the example first. Then ask "what pattern does this concrete trace resemble?" Pattern recognition runs much faster on a worked example than on a problem statement. Levels.fyi's interview-debrief writing repeatedly flags "jumped to a remembered pattern" as a top reason strong candidates get downgraded on novel problems — the candidate force-fits and misses an O(n) → O(n²) regression.

Solve the smallest possible version

If even the worked example isn't suggesting a pattern, shrink further. Solve n=1 and n=2 by inspection, then ask: "what changes when I go from n=2 to n=3?" That delta — what makes n=3 harder than n=2 — is almost always the core of the algorithm. For "merge intervals" the delta is did the new interval start before the previous one ended. For "longest substring without repeating" it's did adding this character violate uniqueness. The pattern lives in the delta.

The "two-known-patterns" frame

Per the Pragmatic Engineer's writing on senior interview difficulty, interviewers rarely invent fully novel problems — they almost always combine two patterns the candidate has seen separately. Once you've worked the example, scan for two patterns that might compose:

• Binary search + greedy verification = "minimum capacity to ship in K days" family
• Sliding window + hash map = "longest substring with K distinct" family
• Sort + two pointer = "three-sum" family
• DFS + memoization = "count paths in a grid with obstacles" family

When you can say "this looks like a sort step followed by a two-pointer sweep" out loud, the interviewer will usually nod or redirect — either way, you've turned an unfamiliar problem into a familiar composition.

What to say when you're truly stuck

After 8-10 minutes of honest effort with no traction, the script is:

"I haven't seen this pattern before. Here's what I've ruled out and why. Here's what I'd try next: [specific direction]. Does that direction make sense, or are you nudging me toward something else?"

This is a specific, falsifiable request for a hint. It's much better than vague "I'm stuck" silence. Interviewers want to see how you ask for help, and a precise ask is itself a signal. Generic Indeed Career Guide research on problem-solving under interview pressure consistently shows that candidates who articulate a specific gap score higher than candidates who go silent or fish for general help.

About the author: Alex Chen is the founder of InterviewChamp.AI and writes about the modern tech interview from the inside — what changed, what works for new grads, and where the old playbook fails.