Reading the problem before solving it

LLM-authored, human-reviewed

Learning how to learn

Every algorithm problem hands you its solution before you write a line of code — in the constraints, the input description, and the size limits. Most solvers skip straight to picking an approach. Strong solvers read first, because the cues in the statement eliminate whole families of algorithms before you have to choose one.

The reasoning replays on this site formalize this as the first moves of every trace: a cue scan, a decomposition, and a complexity budget. This article explains what each move is for and how to run it on a real example — the Binary Search reasoning replay, which opens with all three.

The cue scan: every adjective is an instruction

Read the input description the way a detective reads a scene — every detail is either a cue or noise. “The input is a sorted ascending list of distinct integers. Return the target index, or -1 if absent. The list may be empty, and the required time complexity is O(log n).”

Four cues, four consequences:

  • Sorted ascending — order information you did not create and cannot afford to ignore. Sorting is the entry fee for binary search, two-pointer sweeps, and every “discard half” move.
  • Distinct — no duplicates, so “find the target” has exactly one answer and you never have to worry about which match to return.
  • May be empty — the empty case is in scope, so your solution needs a base case for it. Problems that promise non-empty inputs are quietly telling you that you may skip that check.
  • O(log n) required — linear scan is rejected in advance. The statement is not asking nicely; it is telling you which family of solutions is allowed.

A statement that says “the array is not sorted” is making the opposite argument: binary search is off the table, and a scan is not a naive choice — it is the only honest one.

The decomposition: one ask becomes smaller asks

“Return the target index or -1” decomposes into three smaller questions: find the middle, compare it to the target, decide which half survives. None of those subproblems mentions sorting or logarithms — they are mechanical. The decomposition is where you discover that a scary problem is three mechanical ones in a trench coat.

The complexity budget: the statement’s permission slip

The O(log n) requirement works as a permission slip in reverse. A linear scan is O(n) — rejected. A hash map of values-to-indices would answer in O(n) to build and O(1) to query — also more than the budget allows, and it does not need the sorted order anyway. Only approaches that discard half the input per step survive the budget check. When you state the budget before designing, you cannot fall in love with an approach the grader will reject.

Teach yourself the move

Take any problem statement and mark every adjective and every number that is not the example: sorted, distinct, non-empty, O(something), at most K. For each one, write one sentence: “this rules out “ or “this requires .” If you cannot fill in the blanks, you have not finished reading the problem — and the replays will keep asking until you have.

The rest of the series

Reading is only the first phase. The series overview maps all four; the next stop is Conjecture, kill it, pivot — what strong solvers do once the statement has been read.

Related exercises

  • reasoning How a strong solver approaches Binary Search
← Back to articles