The Problem-Solving Mindset

A seven-step method

The biggest difference between a beginner and an experienced problem-solver is not raw cleverness — it is having a process to fall back on when the answer isn't obvious. A blank page is paralyzing; a checklist is not. Here is a method you can run on almost any algorithmic problem, in order, without panic.

1. Clarify. Restate the problem in your own words. What exactly are the inputs and outputs? What are the sizes and ranges? Are there duplicates, negatives, an empty input? Ask before you code.
2. Work small examples by hand. Take a tiny input and solve it on paper. The act of solving it manually almost always reveals the structure of the real algorithm.
3. Write the brute force. Find any correct solution, however slow. A working O(n^2) beats a broken "clever" idea — and it gives you something to improve.
4. Find the bottleneck. Analyze the brute force's Big-O and ask: which step is the expensive one? That single step is where all your improvement will come from.
5. Pick a pattern or structure that attacks the bottleneck. Repeated lookups? A hash table. Repeated subproblems? Dynamic programming. A sorted-array scan? Two pointers. (Mapping below.)
6. Analyze the new Big-O. Did the pattern actually lower the cost? State the time and space complexity out loud, the way the earlier rungs taught you. If it didn't improve, try a different pattern.
7. Test edge cases. Empty input, a single element, all-equal elements, the maximum size, negatives. Walk your code through each. This is where most bugs hide.

Mapping problems to patterns

Step 5 — picking a pattern — feels like the hard part, but it is mostly recognition. Each pattern you learned on this ladder has a tell-tale phrase. When you hear the phrase in a problem, the pattern lights up. Train yourself to translate problem language into pattern language.

Problem says ...                          Reach for ...
-------------------------------------     ------------------------------
"have I seen this value before?"          hash table / set (avg O(1))
"find a value in sorted data"             binary search (O(log n))
"smallest / largest so far, repeatedly"   heap / priority queue
"all paths / all combinations"            backtracking (with pruning)
"overlapping subproblems"                 dynamic programming
"contiguous window over an array"         sliding window (O(n))
"pair in a sorted array"                  two pointers (O(n))
"shortest path / levels in a graph"       BFS
"reachability / cycles / components"      DFS or union-find
"split, solve halves, combine"            divide and conquer

A worked example ties it together. "Given an array, are there two numbers that add up to a target?" Brute force: check every pair, O(n^2). Bottleneck: for each number you re-search the whole array for its complement. The phrase "have I seen this value before?" lights up — so use a [[hash-table|hash table]]: as you scan, store each number, and for the current one check whether (target − current) is already stored. That turns the inner search into average O(1), so the whole thing is O(n). One pattern, applied to the bottleneck, collapsed n^2 to n.

bool twoSum(const vector<int>& a, int target) {
    unordered_set<int> seen;
    for (int x : a) {
        if (seen.count(target - x)) return true;  // complement already seen
        seen.insert(x);
    }
    return false;
}
// Brute force was O(n^2). With the hash set, this is O(n) time, O(n) space.

Staying calm and honest

Two more habits separate people who grow from people who stall. The first is talking through your thinking out loud — naming your assumptions, your brute force, and your bottleneck as you go. It keeps you honest and, in an interview, lets someone help you. The second is being willing to say "my first idea is O(n^2); let me see if I can do better," rather than pretending the fast answer arrived fully formed.

Not every problem needs a fancy pattern. Sometimes the brute force *is* the answer because n is tiny, and reaching for [[dynamic-programming|dynamic programming]] would be over-engineering. Part of the mindset is judgment: match the effort to the input size and the requirement. The goal is a solution that is correct, clear, and fast *enough* — not the cleverest possible.