Dynamic Programming Has Five Patterns, Not Fifty

There's a ritual that plays out across tens of thousands of developer Discord servers, Reddit threads, and anonymous forum posts every year. Someone preparing for a technical interview asks how to get better at dynamic programming. The answer they receive, almost universally, is: grind more problems. Do house robber. Do knapsack. Do longest common subsequence. Do enough of them and pattern recognition develops on its own.

Maybe it does. But that framing treats DP fluency as accumulated exposure rather than transferable understanding — and those are different things, with different implications for who ends up on the other side of the interview table.

A new video from Tech With Nikola pushes back on this, and does it clearly enough that it's worth taking seriously.

The Argument

The core claim is this: nearly every dynamic programming problem an interviewer will hand you has a state that takes one of five recognizable shapes. Not fifty shapes. Not one per problem. Five. And once you can identify which shape you're looking at, the rest — the recurrence, the memoization, the table-filling — follows a recipe you can practice separately.

The five patterns are:

Linear — one sequence, one pointer, each decision depends only on earlier positions. House Robber is the canonical example. You're walking a street, and at any house, all you need to know is the best total you could have banked up to here. The entire history of your choices collapses into two numbers.

Grid — two coordinates, restricted movement. You're navigating a grid, moving only right or down, minimizing cost. Your state is your row and column. The hint is in the problem: if you see a grid with constrained moves, you already know what your table looks like.

Knapsack — position in a list plus something you're carrying. The crucial move here is recognizing that the second coordinate doesn't have to be a place. In partition equal subset sum, you're tracking your budget — how much of a target sum you still need. That budget is abstract, not spatial, but it functions like a coordinate because it fully determines what your future options are worth.

Alignment — a position in each of two sequences simultaneously. Longest common subsequence lives here. You walk both strings at once, and you need to know where you are in each. Two strings in means you already know the shape of the table before you write a line of code. (Nikola notes that edit distance falls in this same family — it just compares three moves at each step instead of two.)

Interval — a left edge and a right edge, closing inward or splitting. Longest palindromic subsequence and the notoriously tricky Burst Balloons both live here. You can't walk these left to right with a single pointer because the answer depends on both ends simultaneously.

Nikola's formulation across these patterns: the hard part was never the code. It's deciding what the state is — and once you've named the state, the recurrence follows from it.

The Balloon Problem as a Case Study

Burst Balloons is one of those problems that makes people feel like they've missed something fundamental. You have a row of numbered balloons. Popping any balloon earns you points equal to its number times its two neighbors. The catch: the popped balloon disappears, so the neighbors change. Every early pop reshapes what every later pop is worth. It resists direct reasoning.

Nikola's reframe is worth examining carefully. Instead of asking which balloon to pop first, ask which balloon to pop last. Say you designate the five as the last balloon standing. While it's on the board, everything to its left can be solved independently, and everything to its right can be solved independently — because the five never moves. The two sides can't touch each other while the five exists. So you solve each side, add the final pop, and that's one candidate answer. Then you try every other balloon as the last, take the best result, and you're done.

This reframe — don't choose what happens first, choose what happens last — is specific enough that it's genuinely disorienting the first time you see it. The move works because fixing the last balloon eliminates the dependency problem. Every earlier pop inside a range happens while the boundary balloons are still there, which means the scoring stays stable within each sub-range.

Nikola's summary of the overall method: dynamic programming isn't a bag of tricks. It's one move — define a state, try every decision available there, combine the answers, and solve each state once.

Why the Pedagogy Question Matters Here

Here's where I want to linger, because this is my actual beat.

The developer learning ecosystem around algorithms and interviews is enormous, stratified, and not as neutral as it presents itself. NeetCode built a community of millions around structured problem categorization. Striver's SDE sheet is gospel in large parts of the Indian developer community. AlgoExpert charges for curated problem sets with video explanations. And underneath all of it, LeetCode functions simultaneously as the training ground, the credentialing mechanism, and the filter — "just grind LeetCode" is advice that presupposes you have the time, the money for premium, and the prior CS exposure to make problem repetition productive rather than bewildering.

The problem with teaching DP as a pile of unrelated tricks isn't just pedagogical inefficiency. It's that pattern-memorization scales with access. If you went to a school where someone walked you through the underlying structure of these problems, or if you could afford a bootcamp or prep service that did the same, repetition builds on that foundation. If you didn't, you might grind two hundred LeetCode problems and still struggle on anything novel, because you're matching surface features rather than structural ones.

Nikola's video can't fix that access gap — a YouTube explainer isn't a substitute for institutional preparation, and he'd probably say so. But it does something structurally different from the standard grind advice: it offers a framework you can apply to a problem you haven't seen before, and then demonstrates it live on a problem (stock trading with cooldown) that wasn't covered in the rest of the video. Whether the framework holds up is something you can test. That's a different relationship with the learner than "do more problems until it clicks."

The Flowchart Question

At the end of the video, Nikola presents a decision flowchart — a one-page distillation of the whole system. Does the problem give you two sequences to compare? Alignment. A grid with restricted moves? Grid. Items from a list with a target? Knapsack. A range that shrinks or splits? Interval. A single sequence you walk step by step? Linear. And if none of these fit, go back to the underlying question: what does the future still need to know?

The flowchart is useful, but it's also where the framework's seams are most visible. Nikola is direct about this: the branches are suggestions, not guarantees. Some problems require tracking a mode alongside position — he works through stock trading with cooldown as an example where a day number alone doesn't define the state; you also need to know whether you're holding, free, or cooling down. Others might require a bitmask, or a tree traversal, or turn out not to be DP problems at all.

That candor matters. A framework that acknowledges its own edges is more useful than one that promises to cover everything. The flowchart tells you where to start looking; it doesn't guarantee you'll find what you need.

What This Actually Changes

There are two different things a DP framework can do for you. It can help you recognize problem types faster, which makes you better at interviews. Or it can give you a mental model that transfers to novel problems, which makes you better at engineering. These overlap but aren't the same, and the interview prep ecosystem tends to optimize hard for the first while gesturing at the second.

The tension Nikola's video leaves unresolved — and it's the right tension to leave unresolved — is that even a clean conceptual framework still requires substantial practice to become fluent. Knowing that Burst Balloons is an interval problem doesn't automatically produce the "think about what pops last" inversion. That specific insight still has to land somewhere.

What the framework does is give you a place to stand when you're stuck: go back to the state, name it precisely, ask what the future needs to know. That's not nothing. For developers learning outside institutional pipelines, from YouTube and free resources and community forums, having that question to return to is more durable than a list of problem solutions to memorize.

The grind-more advice will keep circulating because it's not entirely wrong. But it concentrates knowledge in people who already have enough context to learn from repetition — and that's a feature of the ecosystem, not a bug, for the platforms and services that profit from it.

---

Dev Kapoor is Buzzrag's open source and developer communities correspondent.