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" coding-interview problems are two known patterns stitched together, and the pattern fit only shows up 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.

That restate-and-shrink reflex is what gets you the offer that ends a months-long search, because it lets you say the answer in your own voice instead of reciting a solution you half-remember. It travels, too. Whether the round is a remote phone screen on a shared editor, a FAANG onsite at a whiteboard, or a timed screen on a platform like HackerRank, CodeSignal, or CoderPad, the unfamiliar problem lands the same way. If you want to feel it before it counts, run a practice round and hear yourself work an unfamiliar problem out loud first so the live version isn't the first time.

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. 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, that's fine. Is the input size bounded?" Often the interviewer says "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 say "this feels like a sweep-line problem because…" you're 80% of the way to the solution.

The unfamiliar-problem protocol, step by step

The four moves above, written as a checklist you can run in order during a live coding interview:

1. Restate the problem in your own words. Paraphrase, don't echo. Sixty seconds here kills the misread that costs you twenty-five minutes later.
2. Work a 3-5 element example by hand. On the shared editor or whiteboard, never in your head. A concrete trace is what makes the pattern visible.
3. Check whether the brute force is acceptable. Say the obvious approach and its time complexity out loud, then ask whether the input size is bounded. Let the interviewer tell you if you even need the optimization.
4. Map the worked example to a known pattern. Compare the trace to two-pointer, sliding window, sweep line, monotonic stack, BFS/DFS, dynamic programming, or binary search on the answer.
5. Shrink to the smallest version if you're still stuck. Solve n=1 and n=2 by inspection, then ask what changes at n=3. The delta is the algorithm.

Steps 1 and 2 are the ones new grads skip under pressure, and they're the two that matter most. For the narration habit that makes each step legible to the interviewer, pair this with how to think aloud during a coding interview. I'd skip any fancier framework than these five. Under a clock, more steps just gives you more to drop.

Restate vs. pattern-match: which to do first

The order of operations is the whole game. Most candidates reverse it. They reach for a remembered pattern before they understand the problem, and that's the move that gets strong people downgraded. Here's the contrast:

| Move | When the unprepared candidate does it | When the strong candidate does it | What the interviewer reads | |---|---|---|---| | Reach for a remembered pattern | First, before understanding the prompt | Last, after a worked example | First: panic-matching. Last: pattern fluency | | Restate the problem in own words | Skipped; they echo the prompt | First, in the opening 60 seconds | Comprehension before code | | Work a 3-5 element example by hand | Rarely, and only in their head | Early, on the whiteboard, out loud | Concrete reasoning, not bluffing | | Ask if the brute force is acceptable | Never; assumes optimal is required | Before optimizing anything | Pragmatism and scoping sense | | Shrink to n=1, n=2 | Freezes instead | When the worked example stalls | Composure under an unfamiliar prompt |

Read the table top to bottom and the lesson is one line: invert the default order. Understanding first, pattern last.

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 ("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 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) to 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.

A brute-force solution is the most direct approach that's obviously correct, regardless of efficiency. On an unfamiliar problem it's a tool, not an admission of defeat. Stating it buys you a correct baseline and often reveals the structure the optimized version will exploit. Time complexity is how an algorithm's running time grows with input size, written in Big-O notation. Naming it out loud is how you and the interviewer decide whether that baseline is good enough or needs sharpening.

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

A sliding window is a two-pointer technique that maintains a contiguous range over a sequence, expanding and contracting to satisfy a constraint. It shows up in roughly a third of medium array and string problems, which is why it's worth recognizing on sight. When you 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.

If you want to drill these compositions instead of memorizing one-off solutions, the coding interview cheat sheet lists the core patterns, and the LeetCode 75 vs Blind 75 vs NeetCode 150 breakdown tells you which problem set actually builds pattern fluency for the 2026 hiring cycle.

Building the reflex before interview day

You can't learn this protocol live for the first time. As of 2026, the most reliable way to rehearse the unfamiliar case is to practice from a shuffled, untagged set so you can't cheat by category. Pull a mixed batch of problems, hide the topic tags, and run each one end to end under a 30-minute timer: restate, trace, brute force, map. The goal isn't to solve every problem. It's to make the first 90 seconds automatic so a strange prompt triggers the protocol instead of panic.

Solo practice has a blind spot, though. You can't see your own stalls, and you never feel the pressure of a real person watching. That's where structured reps help. See how mock interview practice actually moves the needle for CS new grads for the format that builds composure, not just correctness.

Don't forget the clarifying questions

An unfamiliar problem is often just an under-specified one. Before you commit to an approach, pin down the input bounds, the edge cases, and the expected output for the weird inputs: empty input, a single element, duplicates, negative numbers. Half the time, the answer to a clarifying question is the hint. The full move set is in how to handle clarifying questions on a coding problem. Run it before you start coding, not after.

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 beats 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 shows that candidates who name a specific gap score higher than candidates who go silent or fish for general help.

The deeper version of this skill is staying composed when the first approach collapses. If a solution falls apart halfway through, the recovery move is its own discipline. See how to recover from a wrong solution mid-interview. The candidates who walk out with the offer that ends the search aren't the ones who never get stuck. They're the ones who get unstuck out loud, in their own words. If you'd rather rehearse that exact moment until it's second nature, see how live coaching turns a shaky start into a clean finish, the same approach that starts at a $3 trial.

Key terms

Brute force

The most direct, obviously-correct approach to a problem, ignoring efficiency. On an unfamiliar coding-interview problem it's a deliberate first step: it gives you a correct baseline and often exposes the structure the optimized solution will use.

Sliding window

A two-pointer technique that maintains a contiguous range over an array or string, growing and shrinking the range to satisfy a constraint. One of the most common patterns "novel" problems decompose into.

Sweep line

An approach that processes events in sorted order along one axis (often start and end points), keeping a running tally as it goes. The classic fit for interval and scheduling problems like "maximum meetings in parallel."

Time complexity

How an algorithm's running time grows with input size, written in Big-O notation (for example O(n) or O(n log n)). Naming it out loud is how you decide whether the brute force is good enough or needs optimizing.

Pattern matching

Recognizing that a problem belongs to a known family (two-pointer, BFS, dynamic programming). It works far better when applied to a worked example than to a raw problem statement, which is why you trace first and match second.

About the author: Sam K. 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.