How interview prep urges learning data structures and algorithms by patterns

How to actually learn data structures and algorithms

Most people learn data structures and algorithms the hard way: they open a problem site, sort by "most solved," and start grinding. A month later they can recite that a hash map is O(1) but they freeze on anything they have not seen before. The grind teaches recognition of specific problems, not the underlying skill. Here is an approach that actually builds the skill, in three phases. Phase 1: Build the foundations from scratch Before you use a structure, build it once. Implement a dynamic array, a hash map, a stack, a queue, and a linked list yourself. It takes an afternoon each and it changes how you think. When you have written the resize logic of a dynamic array, "append is amortized O(1)" stops being a fact you memorized and becomes something you understand. When you have handled collisions in a hash map, you know exactly why a bad hash degrades it to O(n). This understanding is what lets you reason about a brand new problem instead of pattern-matching to one you have seen. Cover arrays and hashing, then strings, stacks, and queues. Aim for clarity, not speed. Phase 2: Learn the patterns, not the problems The middle phase is where recognition is built. Work through binary search and its variants, trees and their traversals, recursion, sorting, and the windowing patterns. Group problems by pattern rather than by topic: do five sliding-window problems in a row, then five two-pointer problems, until the tell for each is automatic. The goal of this phase is that when you read a new question, your first thought is "this is a monotonic stack problem," not "I have never seen this." Phase 3: The hard patterns The final phase is the one people skip and then get caught on: graphs (BFS, DFS, union-find, shortest paths), backtracking, and dynamic programming. These reward deliberate practice more than volume. Understand the backtracking skeleton once and N-queens, subsets, and combinations all fall out of it. Understand overlapping subproblems once and the whole DP family opens up. A few rules that make it stick Quality over volume. A focused set of around one hundred problems that covers every pattern beats a thousand random ones. Interviews test structured thinking and clear explanation, not how many problems you have seen. Write code, do not just read solutions. You only find out whether you understand something when you run it and it fails. Get feedback immediately. A long edit-run-debug loop is where motivation dies. The faster you see whether a solution passes, the more you learn per hour. Space your reviews. Re-solve a problem a few days later, then a week later. Spaced repetition is the difference between "I solved it once" and "I can solve it under pressure." Where to do it This is the exact arc the Interview Prep track is built on: ten projects that take you from arrays and hashing through dynamic programming, where you build each structure from scratch and then apply it, with every solution graded in your browser the moment you run it. The first project is free. Start at the foundations and work the patterns in order. That is the whole secret.

4 hours ago

The coding interview patterns, explained by building them

Most coding interview questions are not unique. They are variations on a small set of patterns. Once you can recognize the pattern, you stop memorizing individual answers and start seeing the shape of a problem the moment you read it. That is what separates people who grind hundreds of problems from people who solve new ones calmly. Here are the patterns that cover the large majority of interview questions: what each one is for, and the tell that should make you reach for it. Two pointers Two indices walk through a sequence, usually from opposite ends or at different speeds, so you avoid a nested loop. The tell: a sorted array or string, and you are looking for a pair, a triplet, or a property that compares the two ends. Reversing in place, checking a palindrome, and "two sum on a sorted array" are all two pointers. It turns an O(n^2) scan of all pairs into a single O(n) pass. Sliding window A window expands and contracts over a contiguous run of elements while you track something about what is inside it. The tell: the phrase "contiguous subarray" or "substring," plus a constraint like "longest," "shortest," "at most K," or "sum equals." Longest substring without repeats, minimum window, and maximum sum of K elements are all sliding window. Fast and slow pointers Two pointers move through a structure at different speeds. If there is a cycle, the fast one laps the slow one and they meet. The tell: a linked list and a question about cycles, the middle node, or the start of a loop. It uses O(1) extra space where a hash set would use O(n). Binary search (and "search the answer") Halve the search space each step. The classic version finds a value in a sorted array in O(log n). The version interviewers love is binary search on the answer: when the answer is a number in a range and you can cheaply check "is this feasible," you binary search the range itself. Koko eating bananas and "ship within D days" are this. The tell: sorted input, or "minimize the maximum / maximize the minimum." Heaps and top-K A heap keeps the smallest (or largest) element one cheap operation away. The tell: "the K largest," "K most frequent," "merge K sorted lists," or a running median. A size-K heap solves top-K in O(n log K), which beats sorting everything when K is small. Backtracking Build a candidate one choice at a time, and undo the choice before trying the next. This explores every valid combination without repeating work. The tell: "all subsets," "all permutations," "all combinations that sum to," or a constraint puzzle like N-queens. The skeleton is always the same: choose, recurse, un-choose. Dynamic programming When a problem has overlapping subproblems and an optimal substructure, you compute each subproblem once and reuse the answer. Memoization is the top-down version (cache a recursion); tabulation is the bottom-up version (fill a table). The tell: "how many ways," "minimum or maximum cost to," or any problem where a brute-force recursion recomputes the same smaller problems again and again. Climbing stairs, coin change, and edit distance are all dynamic programming. How to actually internalize them Reading a pattern is not the same as owning it. The fastest way to own a pattern is to build the underlying structure yourself, then solve a handful of problems with it until the tell becomes automatic. You do not need a thousand problems. You need the right hundred, organized by pattern, with feedback the moment you run your code. That is exactly how the Interview Prep track is built. You implement each structure and pattern from scratch, then apply it across ten projects, and every solution is graded in your browser the instant you run it. The first project is free, no card needed. Pick the pattern you are weakest at and go build it.

9 hours ago