LetItCrash

How a strong solver approaches an algorithm problem

LLM-authored, human-reviewed

Learning how to learn

The Reasoning Replays on this site show how a strong solver attacks a problem, one move at a time. You predict each move before it appears. This article explains those moves, why a strong solver makes them, and how to use them on algorithm problems.

The replays have two jobs. First, they prepare you for the algorithm exercises: watch the moves, then solve the isomorphic problem yourself. Second, they are a refresher. When an algorithm problem leaves you stuck, come back and watch how a strong solver gets unstuck.

The moves are a vocabulary, not a recipe

There are twelve moves, and a replay walks through them. Do not treat them as a fixed recipe. Strong solvers do not march through a checklist. They loop: state a hypothesis, hunt for a counterexample, pivot when one appears, and state a new hypothesis. The moves name what you are doing at any moment, which matters more than their order. Name the move: “I am hunting for a counterexample right now.” Then you can see when you are stuck in one move and need another.

The replay player prints a subgoal label on each move. Those labels are the same words this table uses:

Move Subgoal the player shows
Cue scan Frame Problem Space
Complexity budget Resource Bounds
Hypothesis Formulate Approach
Counterexample hunt Stress-Test Invariant
Pivot Strategic Shift
Decompose Divide Subproblems
Reduce Pattern Transformation
Invariant Core Invariant
Implement Execute Solution
Trace test Ground Evaluation
Debug Targeted Diagnosis
Retrospect Pattern Generalization

Stress-Test Invariant and Core Invariant are the look-alike pair. A counterexample hunt tries to break the current hypothesis with an executed input. An invariant states a property that must hold at every step. One is an attack on a guess. The other is a claim about the algorithm that survived.

Phase 1 - Understand before you write anything

Cue scan

Read the problem for cues: input sizes, orderings, data shapes, and phrases that suggest a known technique. Experts pattern-match these signals first, narrowing the search instead of starting blind.

In the Two Sum replay, the first move reads the cue: “return the indices” and an unsorted array means pair-finding where order matters. Sorting would destroy the indices the answer needs. Nothing is written yet. The cue has already narrowed the approaches worth considering.

Complexity budget

Estimate how much time and space the solution can afford from the input size before committing to an approach. This is a budget, not a verdict. Its job is to rule out approaches that could never fit.

Two Sum’s budget is typical: if the array holds 10_000 numbers, checking every pair is about 50 million additions. Can we afford that, or does the size force us to look at each number far fewer times? That estimate dismisses the naive solution before a line of code exists.

Phase 2 - Design by hypothesis

Hypothesis

State a candidate approach plainly enough to test. Naming the guess out loud makes it killable: you can hunt for a counterexample against a claim, not against a vague feeling.

The Two Sum replay’s first hypothesis is deliberately naive. The friendly examples pair neighboring elements, so maybe scanning adjacent pairs is enough. A weak solver might quietly assume this. The replay states it as a claim because claims are what the next move can destroy.

Counterexample hunt

Search deliberately for an input that breaks the current hypothesis, then run the candidate on it. A wrong turn in these replays is killed by an executed failure, never by assertion.

The adjacent-pair hypothesis meets [6, 2, 9, 3] with target 9: the answer needs indices 0 and 3, which are not adjacent. The replay runs the candidate code on that input and gets nothing back. The hypothesis is dead, demonstrably, in front of you. That is the point of the move: an idea that survives a real hunt for a counterexample is worth keeping.

Pivot

Abandon the current approach and change direction after evidence shows it fails. Strong solvers pivot on demonstrated failure, not doubt. The failed attempt still narrows what the answer must look like.

After the counterexample kills adjacency, the replay pivots: walk once, remember every value already seen with its index, and ask each element whether its complement is in the memory. The pivot is not a reset. The previous failure points at what must be true.

Decompose

Split the problem into smaller subproblems that can be solved and checked independently, then recombine them. Each piece is easier to get right and easier to test than the whole.

Reduce

Recast the problem as another problem that is already understood (“this is really a graph search”). Solving the known problem solves this one, and its standard tools come for free.

Cue scan and reduce sit next to each other on the player’s palette and are easy to mix up. A cue scan reads wording. A reduce names the known problem.

Cue scan (Frame Problem Space) Reduce (Pattern Transformation)
read this wording this is a known problem
Islands: a grid of 1s and 0s whose land touches up, down, left, or right Islands: counting touching land is counting connected components
Binary Search: the input is a sorted ascending list Binary Search: the sorted array recasts as interval narrowing

Invariant

State a property that holds at every step of the algorithm, for example, “everything left of i is already sorted”. Experts state invariants because you cannot argue that a loop is correct if you cannot state an invariant for it.

Phase 3 - Execute and verify

Implement

Write the actual code for the chosen approach. In these replays, the code runs against the problem’s real test cases. A check mark means it genuinely passed, not that the author says so.

Trace test

Run a small concrete input and watch what the code actually does, step by step. Tracing grounds intuition in observed behavior, not in what the code was meant to do.

Debug

Investigate a concrete failure: form a theory about what is wrong, then run code that confirms or refutes it. Debugging is hypothesis testing on your own program.

Phase 4 - Reflect

Retrospect

Look back after solving. Which cue should have triggered the right approach sooner? What generalizes to the next problem? This step turns one solved problem into a reusable pattern.

The honesty rule: trust the execution, not the narration

Every node in a replay wears a badge that says how much you should trust it:

  • ✓ executed - the node’s claim was verified by running code. The implement nodes and the counterexample kills. This is the real teaching.
  • estimate - a complexity budget claim. A reasoned guess, honest about being one.
  • prose - everything else: the narration of why a strong solver made a move. Worth reading, but it is a claim about thinking, not a demonstrated fact.

When a replay shows you a wrong turn, the executed failure kills it. A sentence saying “this is wrong” does not.

The same moves, on the catalog

Two Sum was a first meeting with the vocabulary. The live replays use the same moves in different orders. Number of Islands is the one to watch for a wrong turn: the first guess is killable, and the replay kills it by running code.

Number of Islands

“Count the number of islands” in a grid of land and water cells.

  • Cue scan: a grid of 1s and 0s, where land touches land up, down, left, or right - and that connection crosses rows as well as columns. Count the separate pieces of land. The wording is the whole move. It does not yet name a known algorithm.
  • Complexity budget: a 100 by 100 grid is 10_000 cells. Visiting each cell once is 10_000 looks. Visiting each cell twice is 20_000. Is a second pass affordable, or does extra scanning waste work at this size?
  • Hypothesis: count the runs of 1s in each row and add them up. Each horizontal run is one island.
  • Counterexample hunt: connectivity across rows is invisible to a row scan. A column of two 1s ([["1"], ["1"]]) is ONE island, but the row-scan counts two runs. The replay runs that candidate and gets 2 where the answer is 1. The hypothesis is dead by execution, not by assertion.
  • Pivot: when you find an unvisited 1, flood-fill the whole island - mark every reachable 1 via its up/down/left/right neighbors - and count one island.
  • Reduce: counting touching land is counting connected components. Flood-fill is the standard tool for that known problem.
  • Invariant: visited holds every cell already claimed by an island; each unvisited 1 starts exactly one flood, so the count is exact.
  • Implement: flood-fill with a visited set, incrementing the count per unvisited land cell. The executed check mark means it ran against the test cases.
  • Retrospect: the row-scan reduced a 2D problem to a 1D one and lost the up/down edges. The flood-fill restores the connectivity the definition asked for.

The other catalog replays use the same vocabulary in a different order. Group Anagrams and Binary Search are the two to watch for Decompose and Reduce in the glossary sense: one splits the work, the other recasts the problem as one you already know.

Group Anagrams

Group strings that use the same characters with the same frequencies. Output order is part of the contract: sorted inside each group, groups sorted by their first element.

  • Hypothesis: sort the list of words so every anagram sits next to its siblings, then close each group the moment a non-anagram appears.
  • Counterexample hunt: sorting the words pulls anagrams apart. On ["ab", "ba", "abc"] the sorted list is ["ab", "abc", "ba"]. "ab" and "ba" are anagrams that are no longer adjacent, so run-grouping hands back three singleton groups. The replay runs that candidate. It fails.
  • Pivot: sort each word’s characters instead. Anagrams produce the same sorted string, and that string is the hash key that groups them.
  • Decompose: compute a canonical key per string, group by that key, then sort inside each group and sort the groups. Three smaller jobs, each checkable on its own.

Binary Search

Find a target in a sorted ascending list of distinct integers, or return -1.

  • Hypothesis: inspect the midpoint and, whenever it is not the target, keep searching only the left half.
  • Counterexample hunt: run that left-only approach on [1, 3, 5] looking for 5. The target sits to the right of the midpoint. The candidate never returns index 2.
  • Pivot: the midpoint comparison chooses the surviving half. Equality returns mid; a smaller midpoint searches mid + 1 through right; otherwise search left through mid - 1.
  • Decompose: one comparison leaves exactly one remaining half - a smaller subproblem of the same shape. Solve that half the same way. There is no second half to recombine.
  • Reduce: the sorted array recasts the problem as interval narrowing, a known problem. One comparison discards an entire half of the remaining range.

Top K Frequent Elements is the replay that hypothesizes twice. It uses Decompose first (count, pick the top k, present ascending), then states a second hypothesis: skip the final sort. The executed kill on {[4, 4, 4, 4, 3, 3, 3, 2, 2, 1], 2} returns [4, 3] in frequency order where the answer must be [3, 4]. Selection order and presentation order are two different sorts.

How to use the replays

Predict before you reveal. That is the practice. Each time you guess what move comes next, you practice cue-reading and hypothesis-naming. When you guess wrong, study the revealed move.

When you get stuck on an algorithm problem, use the moves as your escape route. Name where you are: “I have not stated a hypothesis yet” → state one. “My hypothesis passed the friendly examples” → hunt a counterexample. “A counterexample landed” → pivot, and state what the failure proved. The replays turn those words from jargon into moves you have watched a strong solver make.

The series: one article per phase

This article is the map. Each phase also has its own article, the same moves at the depth a single page cannot carry:

Where to go next

Related exercises

← Back to articles

Exercises