Algorithms & Data Structures

Algorithms are not just interview trivia. They are the grammar of problem-solving. Every time you choose between a hash map and a sorted array, every time you decide whether to cache a subproblem or recompute it, you are making an algorithmic decision. The difference is whether you make it deliberately or by accident.

That said, let's be honest: most engineers study algorithms because of interviews. That is fine. The material here is organized to serve both goals -- passing interviews efficiently and building lasting intuition.

The 80/20 of Interview Prep

Not all topics are created equal. If you have limited time, focus here:

How to Study

The wrong way: Read solutions, nod along, move to the next problem. You feel productive but learn nothing.

The right way:

1. Learn the pattern first. Before grinding problems, understand the underlying technique. Know why sliding window works, not just how to apply it.
2. Solve without hints. Struggle for 20-30 minutes before looking at solutions. The struggle is where learning happens.
3. Implement from scratch. Do not copy-paste. Type every character. Muscle memory matters.
4. Review and categorize. After solving, ask: "What pattern did this use? What was the key insight?" Tag it mentally.
5. Revisit after a gap. Spaced repetition works. Solve the same problem a week later without looking at your old solution.
6. Time yourself. In real interviews you get 20-35 minutes per problem. Practice under realistic constraints.

How This Section Is Organized

Complexity Analysis

The language for reasoning about performance. Big-O, amortized analysis, space complexity. You need this vocabulary before anything else.

Data Structures

The building blocks. Each data structure has a sweet spot -- problems where it is the natural fit.

• Arrays & Strings -- The most fundamental structures and the manipulation patterns that recur endlessly.
• Hash Maps -- The single most useful data structure in interviews. Constant-time lookup changes everything.
• Trees -- Binary trees, BSTs, traversals, and the recursive patterns that dominate tree problems.
• Graphs -- Representations, traversals, shortest paths, topological sort. Graphs generalize trees.
• Heaps -- Priority queues, top-K problems, and anything involving "the K largest/smallest."

Algorithm Patterns

Reusable strategies that apply across many problems. Recognizing the pattern is usually the hard part.

• Two Pointers -- Fast/slow, left/right squeeze, partition. The workhorse of array problems.
• Sliding Window -- Fixed-size and variable-size windows for subarray/substring problems.
• Binary Search -- Not just "find element in sorted array." Search space reduction for optimization problems.
• BFS & DFS -- Graph and tree traversal. When to use which, and how to implement both.
• Dynamic Programming -- Breaking problems into overlapping subproblems. The pattern most engineers fear -- demystified.
• Backtracking -- Systematic enumeration with pruning. Permutations, combinations, constraint satisfaction.

A Note on Language

Code examples use TypeScript as the primary language, with Python where it makes the solution clearer. The concepts are language-agnostic. If you interview in Java, C++, or Go, the patterns transfer directly -- only the syntax changes.

Beyond Interviews

The real payoff of learning algorithms well is not the job offer. It is the ability to:

• Estimate feasibility. "Can we process 10M records in under a second?" becomes answerable, not guesswork.
• Choose the right tool. Knowing that a trie gives you prefix search in O(k) while a hash map does not changes design decisions.
• Read others' code. Many codebases use algorithmic patterns implicitly. Recognizing them makes the code legible.
• Debug performance. When something is slow, you can reason about why it is slow, not just profile and pray.

The material is practical. Every article includes code you can run, patterns you can reuse, and the kind of reasoning interviewers want to hear.