DSA Patterns for Coding Interviews: The Techniques Behind Almost Every Problem

Part 1 of 16 · ~3 min

Overview

Two hundred problems solved on a judge, and you can still lock up in an interview — not because the algorithm is unfamiliar, but because the costume it's wearing is. A problem about the longest stretch of days a delivery van stayed under its weight limit and a problem about the longest run of a string with no repeated character look like they have nothing to do with each other. Strip the wrapping off and they're the same window sliding across an array. What an interviewer is actually checking is whether you can see through the wrapping fast enough — not whether you've solved this exact scenario before.

So this reference skips the usual approach of a fresh toy for every pattern — one array here, a random string there, a new cast of variable names every few paragraphs. Instead it builds one thing, continuously, from the first pattern to the last: a university course planner, the kind of tool a registrar's office would genuinely run. It starts small and a little naive, the way real first attempts are, and by the last chapter it has grown a search box, a shopping cart, a prerequisite validator, a catalog browser, a semester planner, and a waitlist board — and every one of those features turns out to need one of the patterns below, for a reason you'll be able to point to before you even see the code.

Roughly in the order the planner needs them, here's everything on the itinerary: windows and paired pointers sweeping an array, trading memory for speed with a hash map, stacks (plain and monotonic), recursion that backtracks on itself, tree walks, graphs explored breadth- and depth-first, a binary search that hunts for a number instead of an index, ordering things under dependency constraints, dynamic programming, greedy choices, heaps, and sorting moves that beat what a language ships for free. All the code is JavaScript — swap in any language and the underlying idea doesn't change. Read straight through for the complete mental model, or jump to whatever chapter your current problem is pointing at, and come back to the lookup table in the last chapter once the material is already familiar and you just need the phrasing-to-pattern mapping.

One setup detail before any of that. Everything the planner does for the rest of this piece touches one array:

// CATALOG: every course section offered this decade. Roughly 42,000 entries.
// { code, title, dept, credits, prereqs: string[], rating, waitlistCount }
const CATALOG = [ /* ~42,000 course-section objects */ ];

Forty-two thousand rows isn't much for a database — it's plenty for a loop you write by hand. That's the whole point of picking a number this size: it's exactly where the gap between "touch every element once" and "touch every pair of elements" stops being academic and starts being the difference between a page that loads and one a student closes in frustration. Keep that array in the back of your mind. Every chapter from here searches it, filters it, sorts it, or builds a structure on top of it.