AlgoExpert vs NeetCode: Why I Still Froze in Coding Interviews

Question

A few years back I had AlgoExpert open in one tab and a NeetCode playlist queued in another, and the prep felt like it was working. Twelve weeks of disciplined viewing, two videos most evenings, the trees module rewatched twice because the postorder helpers weren't sticking on the first pass. Then a real interview opened with a fresh medium nobody had walked through, and the eight minutes spent looking at the prompt before writing anything were the slowest eight minutes of the round.

The problem looked like a graph. The candidate technique wasn't there. The videos on graphs all started after the technique had been named, and naming the technique on a fresh prompt was apparently a different skill.

What I figured out, in retrospect

• The 100 polished AlgoExpert videos and the 400+ free NeetCode walkthroughs were honest about what they were teaching: how a technique works once the technique has been named.
• Naming the technique on a fresh prompt was a separate skill the videos didn't claim to train.
• The reps that were missing weren't more videos. The video count was already enough.
• A wrong attempt written from a blank screen surfaced more about the gap than another walkthrough did.
• Once the practice shape changed, both platforms became more useful, not less.

Quick disclosure before I get into this. I built Codeintuition, a structured learning platform for coding interviews. The retrospective below is from before that, when working through both AlgoExpert and NeetCode the way the platforms recommend.

Where the approach was breaking

The Number of Islands prompt was the one that finally made the gap concrete. The interviewer described a 2D grid of 1s and 0s and asked for the count of distinct islands, where an island is a region of connected 1s. The walkthroughs of this exact problem had been watched twice. The BFS variant could be written from memory if the title was handed over.

What couldn't happen, in 25 minutes against a whiteboard, was reading the prompt and arriving at "this is a connected components count, BFS or DFS from each unvisited 1, mark visited as you go." The video had given that as the starting position. The prompt expected it to be constructed. Twelve weeks of polished video walkthroughs hadn't drilled the construction work.

The pattern wasn't specific to graphs. It repeated on the next round, where the prompt was a string problem with a sliding window solution, and the candidate technique took six minutes to occur. After the round the code re-derived itself in five. The implementation was the easy part. The decision was where the time went.

What changed on the second attempt

The shift wasn't dramatic. Two changes, both unglamorous:

What had been happening	What started happening
Watching the walkthrough first, then attempting the problem with the technique already in mind.	Reading the prompt first with the title and tags hidden, naming the visible triggers that could be extracted, then either trying the technique from those triggers or giving up after 10 minutes and watching the walkthrough.
Picking the next problem from the platform's curriculum order, by topic.	Picking five problems on the same technique, drilling them with titles hidden, before moving to a different technique.
Treating the timer as a final-week thing.	Adding a 25 minute timer to the recognition work, not the implementation work, from week one of the new approach.

The change wasn't from "video led" to "problem led." Both platforms remained part of the loop. What changed was the order of operations: prompt first without the technique label, then the technique, then the implementation, then the walkthrough as a check rather than the starting position.

What that looked like on the next problem

Take Number of Islands again, after the change. Title hidden, no tags. The prompt described a grid, a definition of an island, a count. Reading it cold:

• The input is a 2D grid, not a flat array. That suggests grid traversal.
• The output is a count of distinct regions. That suggests connected-components reasoning.
• The connection rule (4-directional adjacency on 1s) suggests BFS or DFS from each unvisited 1, marking visited as the traversal proceeds.

That's the recognition that wouldn't form on the first interview round. After ten or twelve recognition reps with titles hidden, on different graph problems, the construction came together in under three minutes on a fresh prompt.

The implementation that followed was short, and not the hard part:

def numIslands(grid):
    if not grid:
        return 0
    rows, cols = len(grid), len(grid[0])
    count = 0

    def dfs(r, c):
        if r < 0 or r >= rows or c < 0 or c >= cols:
            return
        if grid[r][c] != "1":
            return
        grid[r][c] = "0"
        dfs(r + 1, c)
        dfs(r - 1, c)
        dfs(r, c + 1)
        dfs(r, c - 1)

    for r in range(rows):
        for c in range(cols):
            if grid[r][c] == "1":
                count += 1
                dfs(r, c)
    return count

The code is six or seven lines of meaningful work. The recognition that the 2D-grid-plus-connected-region prompt is a DFS-from-each-unvisited-cell problem is the part that would have taken eight minutes on a whiteboard before. The change brought it to under three.

A second example: where the wrong attempt taught more

Later in the same week, a course scheduling problem came up. Given a list of courses with prerequisites, return whether all courses can be completed. The walkthrough had been watched. The walkthrough used Kahn's algorithm with topological sort. Reading the cold prompt, "topological sort" wasn't a candidate that surfaced. The graph was visible, the directed edges were visible, but the move from "directed graph with prerequisites" to "topological sort to detect a cycle" wasn't there.

So a wrong attempt got written. A naive DFS that didn't track visit states properly, that would have looped on a real cycle. Wrong, but written. Then the walkthrough got checked.

The wrong attempt did something the walkthrough alone hadn't done. It surfaced the specific missing piece. A directed cycle needs a three-state visit tracking (unvisited / in progress / done) or an indegree-zero queue, and that hadn't internalised. Knowing the missing piece, the walkthrough's three-state DFS clicked. The next two course-prerequisite problems resolved in eight or nine minutes each. Without writing the wrong attempt first, the walkthrough would have produced a nod of recognition, then the same stall on the next variant.

This is the generation effect doing the work nobody told me about during the watch-everything phase. Producing an answer first, even an obviously wrong one, surfaces the missing concept more reliably than reading the answer.

Why this works (the science I dug into later)

The retrospective is what surfaced the underlying reasons. Two effects from the cognitive science literature explained what was happening, both summarised in the transfer of learning Wikipedia article.

The first is the generation effect itself: producing an answer before checking the reference produces stronger encoding than reading the reference first. Watching twelve weeks of walkthroughs is the second pattern, not the first. That's why the prep felt productive (it was) and didn't transfer to fresh prompts (the encoding was recognition-shaped, not generation-shaped).

The second is a near transfer / far transfer split. Watching ten variants of expand around centre transfers reliably to variants close to what was watched. It transfers unreliably to a fresh prompt where the description is just different enough that the recognition memory misses. The prep platforms reward the watching shape. Interviews test the generating shape. One shape doesn't substitute for the other.

What I'd tell someone in the same spot

If you're working through AlgoExpert or NeetCode (or both) and the unfamiliar mediums are still freezing you, here's what would have helped earlier:

1. Cover the title before reading any prompt. The title is the cheat sheet the platform hands you. Hide it and the recognition becomes the work, which is what an interview tests.
2. Write a wrong attempt before reaching for the walkthrough. The wrong attempt surfaces the specific missing piece. Reading the walkthrough cold doesn't.
3. Pick five problems on the same technique before moving to the next technique. The reps on a single technique are what extract the trigger features. Topic-spread reps don't do this.
4. Add a 25 minute timer to the recognition work from the first day. Recognition under timed conditions is the actual interview test. Practising it without the timer doesn't transfer.
5. When you do watch a walkthrough, watch it as a check on the wrong attempt, not as a starting position. The walkthrough is more useful at this point in the loop than at the beginning.

The 100 polished videos and the 400+ free walkthroughs were never the bottleneck. The bottleneck was the practice shape that surrounded them, and the practice shape was something both platforms assume the engineer will construct on their own.

I wrote a longer version on my own blog that walks through how the two platforms compare on depth, breadth, and free access, plus the trigger lists rebuilt for the patterns that broke me first.

What's the platform you watched the most videos on, and what was the prompt where the recognition finally locked in for you?