How to Approach Any Algorithm Interview Problem

You now have every algorithmic tool this course teaches - hashmaps, stacks and queues, linked lists, binary search, recursion and memoization, heaps, two-pointers, sorting, trees, tries, union-find, backtracking, DP, greedy, graphs - plus, from this tier, how they show up disguised as production systems: an LRU cache, a hash ring, a token bucket. None of that guarantees you will recognize the right tool in fifteen seconds when an unfamiliar problem is read aloud to you and a clock starts. This chapter is not new algorithm content - it is the reusable process for getting from "I have never seen this exact problem" to a working, analyzed solution, under the actual conditions of an interview.

Restate the problem in your own words and ask about the edges: what are the constraints on input size, does that rule out an O(n^2) solution? Can inputs be empty, negative, contain duplicates? Is a single answer expected, or all valid answers? Skipping this step is one of the most common ways strong engineers fail interviews - not because they cannot code, but because they solve a subtly different problem than the one being asked, discovered only after they have already written twenty lines.

State an obvious, correct-but-slow approach before optimizing: "the brute force here is to check every pair, which is O(n^2)." This does three things: it proves you understand the problem correctly before investing in cleverness, it gives the interviewer a baseline to compare your optimization against, and it often directly hints at the optimization, because most optimizations are "which part of this brute force is redundant work, and what data structure eliminates the redundancy."

• -Need to find a pair or subarray with a running sum or count constraint over contiguous elements? Two-pointers or sliding window.
• -Need O(1) lookup of "have I seen this before"? Hashmap or hashset.
• -Need the smallest or largest element repeatedly, with insertions in between? A heap.
• -Overlapping subproblems where the brute-force recursion recomputes the same state? Memoization or DP.
• -Need to make a locally-optimal choice at each step and can prove it never needs to be undone? Greedy.
• -A graph of relationships, and you need reachability, shortest path, or connectivity? BFS, DFS, Dijkstra, or union-find.
• -Need every combination, permutation, or subset satisfying a constraint? Backtracking.

Say the time and space complexity of your intended approach before you finish writing it, not after. This catches mistakes early - "wait, that inner loop makes this O(n^2), not O(n) like I said" - and shows the interviewer you think about complexity as a design constraint, not an afterthought bolted on at the end.

Write code while talking through it, not silently. An interviewer grading a live coding round has almost nothing else to observe your reasoning except what you say - a correct silent solution and a correct narrated solution do not score the same, because the narrated one demonstrates you would be legible to a teammate reviewing your pull request, not just a black box that happens to output correct code.