Forem: Prakhar Srivastava

Algorithmic intuition matters more than problem count in coding interviews

Prakhar Srivastava — Thu, 07 May 2026 12:31:30 +0000

Two engineers prep for the same cycle. One solves more than 500 problems and freezes when the medium doesn't look like anything from the practice list. The other solves a fraction of that and works the problem out from scratch on the screen. The variable that decides which way it goes isn't volume.

TL;DR

Volume practice builds memory of specific problems. It builds little of the skill that recognises which technique applies to a problem you've never seen.

Learning science calls these near transfer (familiar problems) and far transfer (unfamiliar ones). Volume practice mostly trains near transfer.

Real interviews test far transfer because the problem isn't labelled and won't match anything in the practice bank.

Recognition is trainable. The training is explicit: read the problem for triggers, name the pattern, then write code.

On the next problem you face, the recognition pass takes 30 seconds before you touch the keyboard. That pass is the gap.

Disclosure up front: I built Codeintuition, a structured learning platform for coding interviews. This post is about the recognition skill that decides whether volume practice converts to interview readiness, not about the product. The closing link goes to the longer version on my own blog.

What 500 problems actually trains you to do

Most coding interview advice tells you to solve more problems. There's a real reason this advice exists. Volume builds fluency: you stop being confused by syntax, you stop misreading constraints, and the interview minutes that used to go to typo-hunting start going to the actual problem. Past a few hundred problems, those skills are usually solid.

What volume doesn't reliably build is the ability to read a problem you've never seen and decide which technique applies. That's a different skill, and the way most engineers practise actively trains around it. You attempt the problem, get stuck, glance at the LeetCode tags, notice it says stack, and read a solution. The next time a stack problem shows up, you might recognise it. The time after, you might not. Recognition is being built by accident, not by design.

In an interview the tag is gone. The problem statement isn't labelled stack or sliding window or dynamic programming. So the skill that's been built by accident has to do work it's never been explicitly trained for. That's where the freeze comes from.

Near transfer vs far transfer

There's a useful piece of language for this from the learning sciences, and it's worth borrowing because it predicts the failure mode precisely.

Near transfer is when you can solve a problem because it resembles one you've practised. You solved Two Sum with a hash map. The interviewer hands you Two Sum II with a sorted array. The visible details changed but the underlying idea is close enough that recognition fires.

Far transfer is when you can solve a problem that doesn't resemble anything in your practice set, by reading the structure of the problem and constructing the approach from first principles. You see "minimum window of an array containing all characters of a target string" and you've never solved a window problem with a character constraint. You read the structure and construct a variable sliding window from scratch.

Grinding 500 problems builds near transfer well. It does much less for far transfer. Whether far transfer is reliably teachable is a debate the research on transfer of learning hasn't fully settled, but the evidence does support one specific intervention. Explicit instruction in when and why a method applies, not just how to execute it, produces more transfer than practice alone.

A worked example: monotonic stack on stock span

Here's the kind of problem where the gap shows up. You're given an array of stock prices. For each day, find how many consecutive days before it had a price less than or equal to that day. The constraints don't mention "stack" anywhere.

If you've practised the technique without practising the recognition, you'll probably try a nested loop first, hit O(n^2), and try to remember which problems you've seen with this shape. If recognition is trained, you read the problem's structure and three triggers fire:

"For each day" means you need an answer per element. Element-wise, not aggregate.
"Consecutive days before it" means a directional search to the left.
"A price less than or equal to" means a comparison condition between the current element and what's to its left.

Three triggers point at one technique: the previous closest occurrence pattern, implemented with a monotonic stack. The triggers are what you read off the problem statement. The pattern is what you write in code.

def stock_span(prices):
    stack = []
    spans = []
    for i, price in enumerate(prices):
        while stack and prices[stack[-1]] <= price:
            stack.pop()
        span = i - stack[-1] if stack else i + 1
        spans.append(span)
        stack.append(i)
    return spans

The implementation is short and well documented across the internet. The bottleneck isn't writing the loop. It's noticing that "for each element, find the previous element satisfying a comparison condition" is one recognisable shape that always uses this technique. That's the recognition skill, and it's the part most prep doesn't train.

What a recognition drill looks like

Before solving a problem, do a 30 to 60 second pass on the statement alone. No code. The output of the pass is a name: which pattern, and why.

For each technique you've learned, you should be able to name the two or three observable features of a problem statement that signal it applies. A few common ones from the techniques most coding interviews lean on:

Variable sliding window: contiguous subarray or substring, plus a condition that holds across the window, plus an optimisation on window length. When all three appear, it's almost always this technique.
Two pointers: a sorted array (or one you can sort) and a search for a pair or triple satisfying a target. The pointers move from the ends inward.
Monotonic stack: per element answer, plus a directional search left or right, plus a comparison condition. Stock span fits. Next greater element fits.
Backtracking: enumerate combinations or paths under a constraint, with the option to abandon a partial candidate when the constraint is violated.

When you start a problem, the drill is: read the constraints, list the features you see, name the technique, then start coding. If you can't name a technique in 60 seconds, you don't start coding. You re-read the constraints with the trigger checklists in front of you and try again. If you still can't, mark the problem and learn the missing feature before moving on.

The first time, this feels artificial. After 30 problems, it stops feeling artificial because the features start firing automatically as you read.

The other thing prep tends to skip

A bit of honesty before the close. Recognition isn't the only thing prep tends to skip. The conditions you practise under matter at least as much, and the default LeetCode loop is much friendlier than an interview.

The default loop has the title visible, the difficulty visible, the company tags visible, the discussion section a click away, and no clock. None of those are present in the actual interview. If your reads of the problem have always been informed by the tag, the moment the tag disappears the read gets harder.

A reasonable practice protocol for the last few weeks before an interview cycle:

Cover the problem name with a sticky note before reading the constraints. Many problem names give away the technique.
Set a 25 minute clock per medium. If you blow past it, that's data: the problem went to "still working" rather than "solved", and the next pass focuses on what slowed you down.
Skip the discussion section on the first attempt. Read it after, only if your attempt didn't converge.
Mix techniques. Three sliding window problems in a row trains nothing about recognition because the third is obvious by inertia. Three problems from different techniques force you to read the constraints.

You can run all of this against any problem bank. It's a practice protocol, not a feature.

When grinding more is the right move

Volume practice is the right call in two cases. First, when your fundamentals on a specific data structure or algorithm are weak enough that you can't implement it cleanly even with the technique handed to you. There, more reps fix the bottleneck directly. Second, when you're a few weeks out from an interview cycle and the goal is speed, not depth. The features you've already internalised get faster with reps.

The cases where volume stops working are different. When implementation is solid but recognition under unfamiliar problems is the bottleneck, more reps don't move the needle because they aren't training what's broken.

What the next problem looks like with this trained

Six months out, you open an unfamiliar problem on a phone screen. The description mentions "for each element, count how many elements to the right are strictly greater before reaching one that's less or equal." Nothing in your practice list looks like it.

Reading for features gets you somewhere. "For each element" is element-wise. "To the right" is directional. "Strictly greater" is a comparison condition. All three match a monotonic stack, written from the right toward the left. You're 30 seconds in and writing the loop.

That's a trained skill. Volume helped, structure helped more, recognition is what closed the gap.

If unfamiliar mediums still freeze you even after hundreds of problems, the bottleneck usually isn't implementation.

It's recognition.

I wrote a longer breakdown covering:

feature checklists for six major interview patterns
near transfer vs far transfer
and the exact recognition drills that made unfamiliar problems feel solvable again

Full breakdown here

Which technique's features finally clicked for you only after seeing it on a problem the explanations had skipped?

How to Prove Your Algorithm Works in a Coding Interview

Prakhar Srivastava — Wed, 06 May 2026 14:00:00 +0000

An interviewer asks you to convince them your algorithm works. You walk through [2, 1, 5, 1, 3, 2] with K=3, get 9, and stop. The interviewer waits. You realise that what you did was test one input, not prove correctness, and you don't have anything else to say.

TL;DR: Proving your algorithm works in interviews isn't a formal induction. It's two things: state what property your loop maintains at each step (the invariant), then check initialization, termination, and edge cases. Tracing one example is testing, not proving. The invariant is what bridges one input to all of them.

What "prove your algorithm is correct" actually means in an interview

If you took a discrete math course, you spent weeks on induction proofs with formal notation. That isn't what an interviewer wants. They want what a senior engineer does in code review: read the loop, ask "what's true at each iteration?", and check whether that property forces the right answer.

The two are related. They share the invariant idea. But the academic version is a paper proof, and the interview version is a 90 second verbal walkthrough. Mixing them up is why most candidates either freeze or write something that looks like exam notation.

When the interviewer says "convince me this works," they want three things in order: the property your loop holds, evidence it holds at every step, and a check that the final state gives the right answer. Doing this clearly is rare, and noticeable when you can.

The two checks

Two checks carry the whole method.

State and verify the loop invariant. Before tracing any code, write down what's supposed to be true at the start of each iteration. Then trace 3 to 4 iterations, confirming the property after each one.
Check boundaries and termination. The invariant covers the loop body. Boundaries cover what happens before the loop starts, after it ends, and on degenerate inputs (empty array, single element, all identical values, maximum size).

Most candidates skip step 1 and jump straight into tracing a specific input. That's testing. Testing tells you it works for that input. The invariant tells you it works for every input.

The difference matters when an interviewer asks about an input you didn't trace. "My sliding window maintains the sum of exactly K elements at each step, and the update adds the new element and subtracts the leaving one" lets the interviewer check the mechanism. "I ran it on [2, 1, 5, 1, 3, 2] and got 9" leaves them wondering about everything else.

A worked example: fixed sliding window

Take the classic problem: given an array and a window size K, find the maximum sum of any contiguous subarray of length K.

def max_sum_subarray(arr, k):
    window_sum = sum(arr[:k])
    max_sum = window_sum
    for i in range(k, len(arr)):
        window_sum += arr[i] - arr[i - k]
        max_sum = max(max_sum, window_sum)
    return max_sum

Step 1: State and verify the invariant

The invariant: at the start of each iteration, window_sum equals the sum of elements in the current window of K elements.

Trace it on arr = [2, 1, 5, 1, 3, 2] with K = 3:

Before the loop: window_sum = 2 + 1 + 5 = 8. The window covers indices 0..2. The invariant holds.
i = 3: window_sum = 8 + arr[3] - arr[0] = 8 + 1 - 2 = 7. The window is now [1, 5, 1], and 1 + 5 + 1 = 7. Holds.
i = 4: window_sum = 7 + arr[4] - arr[1] = 7 + 3 - 1 = 9. Window is [5, 1, 3], sums to 9. Holds.
i = 5: window_sum = 9 + arr[5] - arr[2] = 9 + 2 - 5 = 6. Window is [1, 3, 2], sums to 6. Holds.

The reason the invariant is maintained matters more than the trace itself. The update adds the element entering the window and subtracts the one leaving. That's the mechanism, not just the result.

Step 2: Check boundaries and termination

Initialization: the code computes the sum of the first K elements directly, so the invariant holds before the loop runs.

Termination: the loop runs from K to len(arr) - 1, so the final window covers the last K elements. max_sum has tracked the maximum across every window the loop visited.

Edge cases:

K == len(arr): the loop body never runs, and the initial window_sum is already the answer.
All negative numbers: the invariant doesn't depend on sign, so it still holds.
K == 1: each window is one element. The update shifts by one position correctly.

That's a complete interview-grade correctness argument. You stated what's true at every step, you explained why the update preserves it, and you confirmed the final state gives the right answer.

Where most candidates lose the argument

Five ways correctness reasoning falls apart, all avoidable:

"It works on my example" fallacy. Tracing one input is a single data point. You haven't proven anything about the inputs you didn't trace. The invariant is what generalises.
Not articulating the invariant. You probably have an intuitive sense of what each iteration does. Without putting that into a checkable sentence, the interviewer hears handwaving at the code, not a claim.
Skipping boundary checks. The invariant covers the loop body. It doesn't tell you what happens on an empty array, a single element, or when K equals the array length. Each of those needs separate verification.
Proving termination, not correctness. "The loop runs n times and exits" tells the interviewer the algorithm halts. It says nothing about whether the output is right. Termination and correctness are independent properties.
Overcomplicating the argument. If your reasoning takes three paragraphs, your algorithm might be too complex. Simpler algorithms have simpler invariants. That's part of why interviewers prefer elegant solutions.

Invariants change shape across patterns

The sliding window invariant tracks one running variable. Other patterns produce invariants with different shapes, and recognising those shapes is half of what makes the skill transfer.

Pattern	Invariant shape
Sorted two pointers	The answer, if it exists, lies within `[left, right]`. Each step shrinks the search space without skipping a valid pair.
Binary search	The target, if present, lies within `arr[low..high]`. Every iteration halves the range while preserving that guarantee.
BFS on unweighted graph	When a node is dequeued, its recorded distance equals the shortest path from the source. This depends on FIFO ordering and equal edge weights.
Topological sort via DFS	A node is added to the result only after all its descendants have been added. Reversing the post-order produces a valid ordering.
0/1 knapsack DP	`dp[i][w]` equals the maximum value using items `0..i` with capacity `w`. Each cell depends only on previously computed cells.

The two step structure is the same across all of them. State the property, verify the boundaries. What changes is what the invariant looks like and how many variables it tracks.

Practising under time pressure

Knowing the method and producing one in 45 minutes are different. The bottleneck isn't understanding what an invariant is. It's stating one quickly for an algorithm you just designed.

A drill that works: pick a problem you've already solved. Set a timer for 60 seconds. Try to state the loop invariant in one sentence. If you can't, that's a signal you solved the problem by pattern matching, not by understanding what made it work. Re-read the code and figure out what property the algorithm depends on.

Run that drill on five problems across five different patterns each week. After a month, two things change. First, articulating invariants becomes reflexive. Second, your debugging gets faster, because checking whether the invariant still holds at each step pinpoints the broken iteration faster than tracing the full execution.

A second drill is wrong invariant spotting. Take a correct algorithm. Write down an invariant that sounds plausible but is subtly wrong. Find the iteration where it breaks. This trains the gap between invariants that describe what the code does and invariants that guarantee correctness. Most interview mistakes live in that gap.

I keep watching this play out across engineers I see prep. The ones who can articulate invariants under pressure are usually the ones who solved fewer problems but understood each one more deeply. The ones who froze had solved more but couldn't say what made any single algorithm work.

If you want a worked walkthrough of why the variable sliding window update preserves the invariant before you ever solve a problem with it, the variable sliding window lesson walks through it step by step.

Two halves of the same skill

Correctness reasoning and mental dry running pair together. The dry run gives you the trace. The invariant gives you the claim to verify against the trace. Practising them apart leaves a hole that interview pressure exposes. Practising them together is what makes the reasoning hold up when the algorithm is one you just designed.

The same idea shows up in dynamic programming. When you derive a recurrence, you're implicitly stating an invariant: dp[i] represents the optimal answer for the first i elements. Proving that recurrence correct uses the same two step structure, just with a table-shaped invariant instead of a scalar one.

If you’ve ever frozen when an interviewer said “prove your algorithm works,” the missing piece usually isn’t more problems.

It’s learning to articulate the invariant.

I wrote a longer breakdown covering:

nested loop invariants
wrong invariant drills
DP correctness reasoning
and how to structure interview-grade proofs without formal notation

Which algorithm did you finally feel confident in only after you could state its invariant out loud?

AlgoExpert vs NeetCode: The Interview Skill Neither One Actually Trains

Prakhar Srivastava — Tue, 05 May 2026 22:31:58 +0000

A few years back I worked through both AlgoExpert and NeetCode while preparing for interviews. The 100 polished videos and the 400+ free walkthroughs were useful for what they covered. The interview round that broke me wasn't a problem either platform had skipped. It was a problem they both had a clean walkthrough for, where I could read either solution after the round and recognise the technique, but in 25 minutes against a whiteboard I couldn't see it.

The problem was Longest Palindromic Substring. Both platforms have a video. Both derive expand around centre cleanly. After watching either, the technique makes sense. The issue was the interviewer didn't say "this is a palindrome expansion problem." The prompt said "find the longest substring that reads the same forwards and backwards." That gap, between the technique I could follow on a video and the technique I could spot from a description, is what neither platform set out to train.

TL;DR: AlgoExpert wins on video depth per problem. NeetCode wins on breadth and free access. Both teach how techniques work after you've named the technique. Neither teaches the recognition before the technique gets named, and that recognition is what an unseen medium problem tests.

What AlgoExpert is good at

Clement's videos are clean. There's no other word for them. He picks 100 problems, records each one, walks brute force to optimal in a consistent visual style, and the editing makes the reasoning easy to follow. The single instructor consistency is underrated. After three videos you've adapted to his vocabulary, his pacing, and his shorthand for tradeoffs. From video four onward you spend less time adapting and more time absorbing.

The browser IDE inside AlgoExpert is also the best of any platform I tried that leads with video. After watching the walkthrough you have a workspace already loaded with the function signature, the tests, and the language template. The transition from passive watching to active solving costs you no setup, which matters more than it sounds.

The bundle is the other thing the platform gets right. SystemsExpert and FrontendExpert sit beside AlgoExpert under one account. If you're prepping across DSA, system design, and frontend rounds, paying once for three coordinated curriculums is a real saving in cognitive load alone. The argument that "100 problems is too few" misses what AlgoExpert is going for. The platform aims for depth on a small set, not coverage of everything. On that goal it lands.

What NeetCode does well

NeetCode's free tier is the best reason to start there. The YouTube channel covers more problems than most paid platforms, and the production quality has improved year over year. NeetCode 150 is the most widely shared curated list in the prep community for a reason. You get a defensible problem ordering without any commitment.

The community momentum is the second thing NeetCode does that almost nobody else matches. Engineers swap solutions in the YouTube comments, swap timelines on the subreddit, swap notes in Discord. Studying alone is the failure mode for most preparation. A platform that pulls you into a group of people preparing in parallel is doing real work, even if the work isn't a feature on a comparison sheet.

The mapping to LeetCode is also worth naming. The problems you practise on NeetCode are the same problems Big Tech screening tools serve, which means your practice environment matches your screening environment. AlgoExpert's IDE is more polished, but NeetCode's environment matches what you'll actually face when a recruiter sends you a Codility or HackerRank link.

The shared gap, made concrete

Take Longest Palindromic Substring. The interview prompt is one sentence: given a string, return the longest substring that reads the same forwards and backwards. AlgoExpert's video derives expand around centre cleanly. NeetCode's video does the same with a slightly different style. Watch either and the solution makes sense.

What neither video sets you up to do is the move that happens before the technique gets named. The move is reading the prompt, noticing that a substring is being asked for, noticing the symmetry constraint, and reaching for expand around centre rather than DP because of those two visible features. In an interview, no one labels the problem for you. Your search for a technique starts from the description, not from a category tag.

The pattern repeats across topics. Take a tree problem like Binary Tree Maximum Path Sum. Both platforms have walkthroughs. After watching either you can reproduce the postorder helper that returns the local max while updating a global. What neither walkthrough installs is the recognition that "any node, any path, any direction" signals the helper-with-side-effects pattern. The walkthrough teaches the pattern. The recognition is a separate skill the walkthrough assumes you'll pick up by exposure.

What recognition is, mechanically

Recognition is a small set of features you can name on the prompt before any code is written. For expand around centre, the features are roughly:

The output is a substring of a string.
The constraint involves symmetry, palindromes, or some "reads the same in both directions" property.
Other approaches bottom out at quadratic, so the technique you're looking for is O(n^2) or O(n log n), not O(n) or sub-linear.

When all three apply, expand around centre is the candidate technique to try. Longest Palindromic Substring matches all three. Palindromic Substrings (count, not length) matches the first two. Both fall under the same recognition rule.

This is the part neither AlgoExpert nor NeetCode targets directly. Their walkthroughs assume you've already arrived at the technique, then explain it. The arriving is the work no one is helping you do.

Why volume alone doesn't close it

The cognitive science name for this is the generation effect. Producing an answer from first principles, even imperfectly, builds stronger memory and stronger transfer than recognising a familiar solution. Watching a walkthrough builds recognition of an answer you've been shown. Interviews ask for generation, where you produce the technique from a description you haven't seen.

What you watch and what you generate aren't the same skill. Watching ten variants of expand around centre gives you a strong recognition memory for variants close to what you watched. The interview problem is rarely close enough. It tends to look just different enough that the recognition memory misses, and you stall on what to try next.

The transfer of learning literature splits this into near transfer and far transfer. Near transfer is solving problems that look like ones you've already solved. Far transfer is reasoning through problems that look different but follow the same underlying pattern. Volume in the AlgoExpert / NeetCode mode produces near transfer reliably. Far transfer comes from a different practice shape, where the recognition gets trained on its own.

A recognition protocol you can run this week

If you've worked through either platform's content and unfamiliar mediums still freeze you, the move isn't another fifty walkthroughs. It's a tighter loop on recognition first.

Pick one technique a week. Expand around centre, sliding window, two pointer, monotonic stack, postorder with side effects.
Write down the trigger features for that technique. Three or four specific features you can see in a problem statement that, when they all apply, make this technique the candidate. 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 prompt before reading any constraints in detail.
Solve three or four problems on the technique with the problem name and category tag hidden. The cover-the-name move is what forces you to recognise the technique before coding starts.
Once a week, do one pressure session. Cover the title, set 25 minutes, talk through your reasoning out loud, and don't open the IDE until you've named the technique you intend to use.

A technique a week, eight or ten weeks of focused work. That replaces the hundred-plus mediums where the signal you actually need gets buried under details that don't matter.

Both AlgoExpert and NeetCode are reasonable choices for the watching part of this loop. Once you've watched the technique once or twice, the work that compounds is the recognition reps the walkthroughs don't include.

If you’ve already watched hundreds of walkthroughs but still freeze on unfamiliar mediums, the problem usually isn’t knowledge.

It’s recognition.

I wrote a longer breakdown comparing AlgoExpert and NeetCode on:

depth vs breadth
passive watching vs active recall
and the recognition drills that finally fixed this for me

When did the recognition click for a pattern you used to watch and re-watch without spotting on a fresh problem, and what was the specific problem that broke it open?

The 90 Day FAANG Prep Plan That Actually Works

Prakhar Srivastava — Mon, 04 May 2026 20:30:50 +0000

You count the weeks between today and your on site. Twelve. You pull up a 90 day FAANG prep plan and the structure looks reasonable: easy problems for two weeks, mediums for six, hards for the rest. Six weeks in, you hit binary trees and realise your recursion is shaky. Two weeks later you try a DP problem and can't formulate the recurrence. Suddenly the 12 week plan is a 6 week plan with 6 weeks of rework.

Difficulty isn’t the problem. Order is.

TL;DR: A 90 day FAANG plan works when topics are ordered by dependency, not by difficulty or popularity. The typical "easy then medium then hard" plan ignores that DP needs recursion, recursion needs the call stack, and the call stack needs array fundamentals. Sequence by what each topic requires, not by how hard it feels.

What "wrong order" actually looks like

The failure mode in most 90 day plans is the same shape every time. The plan groups topics by surface difficulty: arrays first because they are easy, DP last because it is hard. Or the plan groups by frequency: arrays first because they appear most, then strings, then trees, then DP. Both shapes ignore that DSA topics have hard prerequisites.

You can't reason about binary tree traversal without recursion. You can't build recursive intuition without the call stack. You can't pattern-match on hash table problems until you have internalised what O(1) amortised lookup actually buys you. These gaps don't show up in Week 2. They show up around Week 5 or Week 7, deep enough into the plan that you've already built a lot on top of unstable ground.

When that happens, the plan quietly stops working. You either skip the prerequisite to "stay on schedule," which compounds the gap into every later topic, or you stop and rebuild, which eats two of the remaining weeks. Either way, the timeline collapses.

The order that actually works

Here's the dependency order that emerges after watching dozens of engineers prep:

Weeks 1 to 2: Arrays and linked lists. Two pointers, sliding window, interval merging on arrays. Reversal, fast and slow pointers, merge patterns on linked lists. About fifteen patterns. Everything else builds on these.
Weeks 3 to 4: Hash tables and stacks. Hash tables unlock counting, prefix sum, and the harder variants of sliding window. Stacks unlock monotonic stack, sequence validation, expression evaluation. Both are prerequisites for tree traversal.
Weeks 5 to 6: Queues, binary trees, BSTs. Queues for level order BFS. Trees for preorder, postorder, root to leaf paths. BSTs for sorted traversal and range operations. Pattern density picks up fast here.
Weeks 7 to 8: Heaps, recursion, backtracking. Heaps for top K and comparator patterns. Recursion formalises head recursion, tail recursion, and multiple recursion. Backtracking introduces enumeration and constraint search.
Weeks 9 to 10: Graphs, sorting, searching. DFS, BFS, Dijkstra, topological sort. Quickselect and custom compare. Binary search variants including predicate search on the answer space.
Weeks 11 to 12: Dynamic programming and review. DP last, because DP is what every previous topic was preparing you for.

The Wikipedia article on the spacing effect summarises why this order also helps retention: practice distributed across weeks, with each week building on the last, produces stronger durable recall than the same volume crammed late. The dependency order isn't only logical, it's also how you keep the early weeks from fading by Week 12.

Why DP belongs at Week 11, not Week 3

Take Coin Change, a standard DP interview problem. To derive the solution rather than memorise it, you need three things lined up:

A recurrence relation. Built on top of recursion fluency.
Recognition of overlapping subproblems. Built on top of seeing how multiple recursive calls share state.
Memoization. Built on top of understanding how cached results map to subproblem states.

Now imagine an engineer who reaches DP in Week 3. They've covered arrays, maybe linked lists. They have not internalised the call stack, they have not seen recursion expressed as a recurrence, they have not seen overlapping subproblems show up anywhere. The Coin Change solution they study isn't reasoning, it's a string of four lines they're supposed to remember:

def coinChange(coins, amount):
    dp = [float('inf')] * (amount + 1)
    dp[0] = 0
    for a in range(1, amount + 1):
        for c in coins:
            if c <= a:
                dp[a] = min(dp[a], dp[a - c] + 1)
    return dp[amount] if dp[amount] != float('inf') else -1

The engineer who reaches the same problem in Week 11 sees this differently. They've spent four weeks with recursion. They've built backtracking on top of multiple-call recursion. They've seen the same dp[i] shape applied to climbing stairs, then to longest increasing subsequence, then to Coin Change. The recurrence dp[a] = min(dp[a], dp[a - c] + 1) doesn't have to be remembered, because they can re-derive it from the invariant: dp[a] is the minimum number of coins to make amount a, and the only way to make a is to make a - c for some coin c and add one.

That's the difference dependency order produces. Not more knowledge. Knowledge that holds together under interview pressure because every piece supports the one above it.

When to add timed pressure (load-bearing)

It is easy to practise in comfort conditions for eleven weeks and then panic in your first mock interview. The gap between "I solved this at my desk with no timer" and "I solved this in 20 minutes with no hints" is wider than most engineers expect. The right time to introduce timed practice is after the foundations are solid but before the advanced topics start. Around Week 6.

By Week 6, you've covered arrays, linked lists, hash tables, stacks, queues, and started binary trees. That's enough pattern coverage to attempt timed problems honestly. You won't know every pattern yet, but you know enough to practise the skill of solving under pressure separately from the skill of learning new patterns.

From Week 6 to Week 8, attempt previously completed problems under a timer. Twenty minutes for mediums, thirty for hards. No hints, no notes. The goal isn't a clean pass rate, it's training the feeling of working without the safety of references while the material is still fresh in your mind.

From Week 9 to Week 12, switch to multi problem assessments under a 50 minute timer, the way actual rounds work. You'll have covered enough of the patterns by then to simulate realistic interview coverage.

Productive struggle vs spinning

Plans break. You'll have a week where work blows up, or you'll hit a topic that takes longer than expected. The better question isn't "how do I avoid falling behind," it's "how do I tell whether I'm stuck productively or just spinning."

The two look similar from the inside but feel different in one specific way:

Productive struggle. You can name what you don't understand. "Merge sort is O(n log n), but the reason the divide step doesn't add extra cost isn't clicking." That's a specific gap you can target with a specific lesson, problem, or question.
Spinning. You're re-reading the same material without forming new questions. You've watched the same walkthrough three times and still can't reproduce the logic from a blank screen.

If you're spinning, change the input. Try solving a strictly simpler variant. Try writing the solution from memory without any reference, even if you produce something wrong. Try explaining the concept out loud as if to a junior. The act of generating an attempt, even a broken one, surfaces the missing piece more clearly than another round of passive review. This is the generation effect doing real work for you.

Concrete checkpoints (because vague progress isn't progress)

Vague progress signals like "things are starting to click" don't survive interview-week stress. Use concrete checkpoints at each month boundary. If three or more items at any checkpoint don't describe you, don't move to the next month. Spend an extra week on the weak areas. A 13 week plan that's solid beats a 12 week plan with holes.

By Week 4, you should be able to:

Solve array two pointer and sliding window problems without looking up the pattern.
Trace linked list reversal mentally, tracking pointer state at each step.
Explain why a hash table lookup is O(1) amortised, not just that it is.
Identify which stack pattern applies from the problem statement alone.

By Week 8:

Trace a binary tree postorder traversal on paper, tracking state at each node.
Reason about BST problems through the sorted traversal invariant.
Write a recursive solution and walk through how the call stack unwinds.
Have attempted ten or more problems under timed conditions, with a pass rate above 50%.

By Week 12:

Identify DP subproblems and formulate recurrences for problems you haven't seen.
Choose between BFS and DFS for a graph problem and explain why.
Complete a 50 minute multi problem assessment with at least one correct solution.
Hit the timer without reaching for the solution tab first.

If you can't honestly check most of these, your plan needs an extra week, not a heroic weekend.

Your final week

Week 12 isn't for new material. If you're still covering fresh topics with seven days to go, something earlier broke. The final week is for consolidation under realistic conditions.

Days 1 to 3 are targeted weak spot practice. Look back at the timed results from Weeks 9 to 11. Which topics had the lowest pass rate? Which patterns did you fail to identify within the first five minutes? Spend three days isolating those specific patterns and attempting two or three problems that test exactly that pattern. Don't re-study the entire topic. Isolate the gap.

Days 4 to 5 are full simulation rounds. Two complete mock interview simulations. Forty five to fifty minutes, two problems, no IDE autocompletion, talk out loud as you write. If you don't have a partner, record yourself. The recording forces the same "someone is watching" pressure that slows people down in real interviews. Pay attention to time allocation. The most common failure pattern is spending thirty minutes on the first problem and having fifteen for the second. Practise the discipline of checking your progress at the 20 minute mark and making a deliberate decision about whether to keep debugging or move on.

Days 6 to 7 are rest and review. Stop solving new problems. Review your notes on the three or four patterns you found hardest. Get enough sleep. The difference between a well rested engineer who's covered 90% of the material and an exhausted engineer who's crammed 100% is measurable in interview performance. Fatigue degrades pattern recognition speed before it degrades anything else, and recognition speed is exactly what interviews test.

The order is the advantage

Compressing the whole roadmap into one rule: study what each topic requires, not what feels hardest. The Coin Change recurrence at Week 11 holds together because every layer below it (recursion in Week 7, stack mechanics in Week 4, array fundamentals in Week 1) was built before it was needed. An engineer who jumps to DP in Week 3 isn't ahead, they're standing on nothing.

If you want the full version of this roadmap with exact problem lists, pattern breakdowns, and weekly schedules I’ve written it here

This post gives you the structure.

The full guide gives you the execution.

What’s the topic in your prep where the dependency chain finally clicked—and which week did it happen?

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.