Patterns, not problems.

Most people memorize “O(n) good, O(n²) bad” without being able to derive complexity from real code — which means they can't debug a slow function or make an honest tradeoff in an interview.

• Deriving time and space complexity directly from nested loops and recursion
• Best, worst, and average case — and why interviewers usually mean worst case
• Why constant factors get dropped in Big-O, but still matter in the real world

// O(n) — one pass
function linearSearch(arr, target) {
  for (let i = 0; i < arr.length; i++) {
    if (arr[i] === target) return i;
  }
  return -1;
}

// O(log n) — halves the search space each step
function binarySearch(sortedArr, target) {
  let lo = 0, hi = sortedArr.length - 1;
  while (lo <= hi) {
    const mid = Math.floor((lo + hi) / 2);
    if (sortedArr[mid] === target) return mid;
    if (sortedArr[mid] < target) lo = mid + 1;
    else hi = mid - 1;
  }
  return -1;
}
// Binary search on 1,000,000 items: ~20 comparisons, not 1,000,000

Two-pointer is the single pattern that shows up in more interview problems than almost any other — but it's usually taught as “just try it” instead of a repeatable recipe.

• The two-pointer technique: opposite ends closing in, or same-direction fast/slow
• Sliding window as two-pointer's cousin — a window that grows and shrinks
• In-place array manipulation without extra memory

// Two Sum on a SORTED array — O(n), no extra space
function twoSumSorted(arr, target) {
  let left = 0, right = arr.length - 1;
  while (left < right) {
    const sum = arr[left] + arr[right];
    if (sum === target) return [left, right];
    if (sum < target) left++;   // need a bigger sum — move left up
    else right--;               // need a smaller sum — move right down
  }
  return null;
}

Hash maps turn O(n²) brute-force problems into O(n) by trading memory for speed. Recognizing WHEN to make that trade — not just how a hash map works — is the actual interview skill.

• Hash map/set operations and real average-case O(1) lookup
• Collision handling basics, and why worst case isn't actually O(1)
• When hashing beats sorting for a given problem

// Brute force Two Sum — O(n²)
function twoSumBrute(arr, target) {
  for (let i = 0; i < arr.length; i++)
    for (let j = i + 1; j < arr.length; j++)
      if (arr[i] + arr[j] === target) return [i, j];
}

// Hash map Two Sum — O(n), one pass
function twoSumHash(arr, target) {
  const seen = new Map();
  for (let i = 0; i < arr.length; i++) {
    const complement = target - arr[i];
    if (seen.has(complement)) return [seen.get(complement), i];
    seen.set(arr[i], i);
  }
}

Linked lists force you to think in pointers/references instead of array indices — exactly the mental shift you need before trees and graphs make sense.

• Singly vs. doubly linked lists, and what each pointer actually stores
• Fast/slow pointer (Floyd's algorithm) for cycle detection
• Reversing a linked list in-place, iteratively

// Reverse a singly linked list in-place — O(n), O(1) space
function reverseList(head) {
  let prev = null, curr = head;
  while (curr) {
    const next = curr.next;  // save before we overwrite it
    curr.next = prev;        // reverse the pointer
    prev = curr;
    curr = next;
  }
  return prev;  // prev is now the new head
}

Stacks and queues aren't just data structures to memorize — they're the actual mechanism behind recursion, undo/redo, browser history, and BFS.

• LIFO vs. FIFO, and matching each to the problems that need them
• Using a stack for bracket matching and the monotonic stack pattern
• Implementing a FIFO queue with two LIFO stacks

// Valid parentheses — O(n), using a stack
function isValid(s) {
  const stack = [];
  const pairs = { ")": "(", "]": "[", "}": "{" };
  for (const ch of s) {
    if (ch === "(" || ch === "[" || ch === "{") stack.push(ch);
    else if (stack.pop() !== pairs[ch]) return false;
  }
  return stack.length === 0;
}

Recursion finally clicks on trees, because the recursive structure IS the data structure — every subtree is itself a complete tree.

• Binary tree traversal: in-order, pre-order, post-order
• Recursive thinking — a base case plus a recursive case, nothing more
• Binary search tree properties and why they matter

// In-order traversal — visits values in ascending order for a BST
function inOrder(node, result = []) {
  if (!node) return result;      // base case
  inOrder(node.left, result);    // recurse left
  result.push(node.val);
  inOrder(node.right, result);   // recurse right
  return result;
}

Graphs are trees generalized — most “real world” problems (social networks, maps, dependency resolution) are graph problems wearing a disguise.

• Adjacency list vs. adjacency matrix, and when to use each
• BFS for shortest path on unweighted graphs vs. DFS for exploring/backtracking
• Representing a grid as an implicit graph

// BFS shortest path on an unweighted graph
function bfsShortestPath(graph, start, target) {
  const queue = [[start, 0]];
  const visited = new Set([start]);
  while (queue.length) {
    const [node, dist] = queue.shift();
    if (node === target) return dist;
    for (const neighbor of graph[node] || []) {
      if (!visited.has(neighbor)) {
        visited.add(neighbor);
        queue.push([neighbor, dist + 1]);
      }
    }
  }
  return -1;
}

DP is just “recursion plus memoization” — it feels scary mainly because most courses teach the formula without first showing why naive recursion is slow and what memoization actually fixes.

• Overlapping subproblems — the same subproblem gets solved over and over
• Memoization (top-down) vs. tabulation (bottom-up)
• Recognizing when a problem IS a DP problem

// Naive recursive Fibonacci — O(2^n), recomputes everything
function fibNaive(n) {
  if (n <= 1) return n;
  return fibNaive(n - 1) + fibNaive(n - 2);
}

// Memoized — O(n), each subproblem solved exactly once
function fibMemo(n, memo = {}) {
  if (n <= 1) return n;
  if (memo[n]) return memo[n];
  return memo[n] = fibMemo(n - 1, memo) + fibMemo(n - 2, memo);
}

Knowing 8 individual patterns doesn't help if you can't tell WHICH pattern a brand-new, unseen problem needs — that recognition is the actual interview skill, not the patterns themselves.

• A repeatable approach: clarify the problem, brute force it, optimize, code it, test it
• A pattern checklist — is it sorted? do I need order preserved? is it secretly a graph?
• Talking through your thinking out loud, the way a real interview expects

// Pattern checklist as pseudocode
if (isSorted || canSort) considerTwoPointer();
if (needsFastLookup) considerHashMap();
if (isTree || isNestedStructure) considerRecursion();
if (isGraphOrGrid) considerBfsOrDfs();
if (hasOverlappingSubproblems) considerDP();
// The problem rarely announces its pattern — you have to notice it