I Solved 200 LeetCode Problems and Still Froze in Interviews

Prakhar Srivastava — Sun, 03 May 2026 16:27:58 +0000

A few years ago I solved 200 LeetCode problems and still froze on Mediums I hadn't seen. The breakthrough wasn't another hundred problems. It was a different loop.

A problem asks for the longest substring with at most K distinct characters. You've solved sliding window before. Maximum sum subarray of size K, done. Longest substring without repeating characters, done. This third one stalls you. Twenty minutes pass. Discuss says sliding window. You'd already solved sliding window problems. The recognition didn't work on this one.

TL;DR: Practice volume builds memory of specific problems, not the recognition you have to do before you start coding. The skill that transfers to unfamiliar interview mediums is identifying which technique applies from what the problem looks like. That recognition is what most LeetCode-style prep doesn't train, and that gap is what this post is about.

What LeetCode actually does well

LeetCode is the default coding interview prep platform for a reason. The problem bank is the strongest available: 3,000+ problems across every common data structure, tagged by company and frequency. The company tagging is the most reliable public signal you can get for "what does Amazon currently ask." Nothing else is close on that dimension.

The free tier is generous, the discuss forum is open, and the weekly contests are free. If you already understand the underlying patterns and you need volume to drill them, LeetCode is the right platform. The contest system is genuinely underrated for building speed under time. Top voted discuss replies on popular problems also hold up. They often explain the reasoning more clearly than the official editorials.

So the question isn't whether LeetCode is good. It is good. The real question is whether the thing holding you back is the kind of thing LeetCode's design actually fixes.

The gap volume doesn't close

The earlier sliding window problems taught implementation on those specific problems, not the rule for when sliding window applies. The connection between "K distinct characters" and "variable sliding window" was never made explicit anywhere in your prep. You learned an implementation by example, not a recognition rule. When the visible parts of the problem change, the implementation memory doesn't carry over.

Learning research calls this near transfer versus far transfer. Near transfer means solving problems that look like ones you've already solved. Far transfer means reasoning through problems that look different but follow the same underlying pattern. The Wikipedia article on transfer of learning covers it. The short version: practice volume produces near transfer reliably and far transfer unreliably. You can grind 500 problems and still not generalise across the differences in description if no one ever taught you which features signal which pattern.

That isn't a talent gap. It's a gap in the method.

What recognition actually looks like

Recognition is reading a problem statement, naming the visible features, and matching them to a technique before any code is written. Every technique has a small set of trigger conditions, usually three to five. When all of them match, you've identified the technique.

For variable sliding window, the trigger conditions are:

The input is a contiguous range (a substring, a subarray, a window of consecutive elements).
The optimisation target is the length of that range (longest, shortest, smallest valid).
There is a condition you can check incrementally as the window expands or contracts (count of distinct characters, sum within bounds, set membership).

When all three apply, variable sliding window is the technique. K distinct characters hits all three. So does longest substring without repeating characters. So does minimum window substring. The triggers are the same. The descriptions differ.

The skill is matching problems to triggers before coding. That's what doesn't get built by grinding problems sequentially.

A code template you can adapt

Here's the variable sliding window template in Python. Once you recognise the technique, the implementation has very few moving parts.

def variable_window(arr, condition):
    left = 0
    state = init_state()
    best = 0

    for right in range(len(arr)):
        state = expand(state, arr[right])
        while not condition(state):
            state = shrink(state, arr[left])
            left += 1
        best = max(best, right - left + 1)

    return best

For K distinct characters, state is a hash map of character counts within the current window, condition is len(state) <= K, and shrink decrements counts and removes keys whose count drops to zero. The recognition step (this is variable sliding window) is the decision that matters. The code follows.

For longest substring without repeating characters, state becomes a hash set and condition is "no duplicate." Same skeleton. Same invariant.

That's the payoff of recognition trained explicitly. Write the template once. Adapt per problem in two or three lines. Stop staring at problems hoping the right approach surfaces.

How practice and interview conditions diverge

Recognition is half the gap. The other half is the conditions you practise under. LeetCode's practice environment shows you the problem name (which often hints at the technique), gives unlimited code executions, and doesn't penalise failed attempts. Real interviews give none of that.

Dimension	Practice (LeetCode default)	Real interview
Problem name	Visible, often hints at category	Not given
Code executions	Unlimited, no penalty	Limited, every failure costs
Hints / discuss	One click away	Not available
Time limit	Self set, often skipped	20 to 45 minutes hard
Reasoning	Internal	Spoken aloud

The middle column is fine for the early learning phase. Open exploration helps when you're still building the model. The problem comes when those conditions are the only conditions you ever rehearse under, and the actual test wants something the rehearsal never asked for.

Replicating interview pressure on your own takes one friend and a kitchen timer. The friend covers the problem name and reads the constraints aloud. You set the timer to 20 or 30 minutes. You don't open the IDE before stating the technique you intend to use. Two sessions a week against a friend who isn't shy about silence will do more for interview readiness than another fifty problems on the comfort setting.

A protocol you can run this week

If the K distinct characters story sounded like your last three failed problems, the move isn't more volume. It's a tighter loop on recognition first.

Pick one technique a week (variable sliding window, two pointers, prefix sum, monotonic stack, and so on).
Write down the trigger conditions for that technique. Three to five features of the problem that, when they all apply, make this technique the right tool. Write them in your own words, not from a cheat sheet.
Read five problems that use this technique without solving them. For each, name the triggers you can see in the problem statement before reading the constraints in detail.
Solve three to five problems on this technique with the problem name and tag hidden. Force the recognition step.
Once a week, do one timed pressure session: friend covers the title, you talk through your reasoning, no IDE until you've named the technique. If you can't name it inside five minutes, the problem rewinds to the recognition queue, not the implementation queue.

A pattern a week, eight to ten patterns covered, roughly ten weeks of focused work. That replaces the hundreds of mediums where the signal gets buried under details that don't matter.

The longer write up of this is on my own blog, with trigger conditions for prefix sum, two pointers, and monotonic stack alongside the variable sliding window walkthrough above, plus a worked example on minimum window substring that uses the same template.

When did the recognition click for a pattern you used to grind without seeing, and what was the specific problem that broke it open?

Disclosure: I built Codeintuition, a structured learning platform for coding interviews. The post above is about the technique, not the platform.