Skip to main content

Problem-Solving Begins with Understanding, Not Computing

What This Concept Is​

Problem solving does not begin with formulas. It begins with a precise, written statement of what the problem actually asks.

Polya's first phase asks three questions, in this order:

  • what is the unknown? -- the quantity, object, set, property, or procedure you must produce
  • what is given? -- the data, hypotheses, parameter ranges, background facts
  • what is the condition connecting the two? -- the relation the unknown must satisfy with respect to the data

If you cannot answer all three in plain language, you are not yet ready to plan a solution. Most "I'm stuck" feelings trace back to a half-understood problem, not a missing technique.

The output of the understanding phase is an artifact, not a feeling: a restatement in your own words, an input/output specification, an explicit assumption list, and a worked tiny example. This distinguishes understanding from two nearby activities that are often confused with it. "Reading" confirms that the text is in front of you; "recognising the topic" narrows to a chapter. Neither is understanding. Understanding is reconstruction: you can describe the problem without the original text and answer the three Polya questions on demand.

A fourth, implicit question hides inside the three: is the condition consistent and sufficient? A condition that is under-determined (many unknowns satisfy it) produces a family-of-solutions problem. A condition that is over-determined (no unknown can satisfy it) is secretly a proof-of-impossibility problem. Both are legitimate, but they require very different plans, and noticing which kind you have is part of understanding the problem.

Why It Matters Here​

Every later heuristic in this module -- working backwards, special cases, invariants, construction, contradiction -- operates on a precise problem. A vague problem statement silently moves through the entire solution and shows up as a wrong answer, a wrong model, or code that passes its tests but does the wrong thing.

In CS specifically, unchecked problem statements produce:

  • specifications that look right but miss edge cases (empty input, ties, duplicates, overflow)
  • interviews where "I solved it" turns into "oh, I misread the input"
  • features that ship, then get rewritten the next sprint after users reveal the intended behaviour
  • bugs that survive into production because the test suite encodes the wrong understanding

Forward pipeline: Semester 2 (algorithm design) begins every problem with a formal input/output specification. Semester 3 (software engineering) treats the understanding artifact as the user story / acceptance criteria. Semester 4 (systems) requires API contracts that are nothing more than codified Polya-phase-one artifacts. Semester 10 (capstone) lives or dies on your ability to keep a problem statement stable while the surrounding system evolves.

Concrete Examples​

Example 1 -- "longest increasing subsequence"​

Prompt: Given a list of integers, find the longest increasing subsequence.

Before solving, answer the three questions explicitly.

  • Unknown: a subsequence (not substring) of maximum length. Is "increasing" strict $a_{i+1} > a_i$ or non-strict $a_{i+1} \geq a_i$? You need to decide.
  • Given: a list of integers. Is it bounded? Can it be empty? Can it contain duplicates? What is the length range: $n \leq 10^3$, $10^6$, $10^9$?
  • Condition: output the length, the subsequence itself, or both? Is a unique answer required when several exist?

Only after answering these can you decide between an $O(n^2)$ DP and an $O(n \log n)$ patience-sorting approach. Each answer changes the algorithm: a stream of $n = 10^9$ forces $O(n \log n)$; strict vs non-strict changes a comparison operator; "return any optimal" vs "return lexicographically smallest" changes the reconstruction step.

Example 2 -- "find the most suspicious transactions"​

Prompt: Sort the transactions from the last 24 hours so the fraud team sees the suspicious ones first.

Apply the three questions.

  • Unknown: a permutation of the input with a ranking rule.
  • Given: transactions with fields ${id, timestamp, amount, risk_score}$. The "last 24 hours" window is relative to now -- resolve to UTC at call time.
  • Condition: "suspicious" is undefined by the prompt. Resolve: primary key $risk_score$ descending; tie-break by $amount$ descending; then by $id$ for determinism.

Without answering "what does suspicious mean?", two engineers produce behaviourally different functions from the same prompt. The understanding artifact prevents that.

Common Confusion / Misconceptions​

Reading-as-understanding. Learners often mistake "reading the prompt carefully" for understanding. Understanding is an act of production: a sentence, a diagram, a list of assumptions. If you did not write something down, you did not understand.

Trap words. The words sorted, unique, minimum, optimal, efficient, appropriate, reasonable carry implicit assumptions that must be surfaced in the assumption list. "Efficient" hides a cost model; "optimal" hides an objective function.

Premature formalisation. Writing types and ranges before you have restated the problem in English. The artifact is English first, schema second. Starting with schema produces a spec that encodes the first interpretation of the prompt rather than the right one.

Understanding vs. pattern-matching. Saying "this is a DP" is not understanding; it is topic recognition. A student who has not separated the unknown from the given cannot be sure which DP, which state, which base case.

How To Use It​

Run this checklist every time you meet a non-trivial problem:

  1. Restate the prompt in one sentence in your own words.
  2. List every input with type, shape, and range. Mark which ranges the prompt gives and which you are inferring.
  3. List every output with type, shape, and range, including the "no solution" case if one is possible.
  4. List every constraint (time, memory, order, uniqueness, immutability, determinism, streaming, online vs offline).
  5. Produce a concrete small example by hand. Then a second, adversarial one (empty, singleton, tie).
  6. List every assumption, and mark which must be verified with the problem owner.
  7. Decide whether the problem is over-, under-, or exactly-determined. Flag the answer.

The understanding phase is complete when you can hand the artifact to a peer and they can explain the problem back to you without the original prompt. If they need the prompt, the artifact is not yet an understanding.

Transfer / Where This Shows Up Later​

  • Semester 2 (algorithms). Every algorithm-design chapter opens with a formal input/output spec. Dynamic programming in particular will not let you write the recurrence until the unknown and the given are fixed.
  • Semester 3 (refactoring, design patterns). Before you refactor, restate the invariant the existing code was protecting -- same three Polya questions applied to legacy code.
  • Semester 4 (debugging). Most "mystery bugs" are misread specs. The reproduction step is a miniature Polya-phase-one.
  • Semester 5 (protocol design). RFCs and message contracts are formalised understanding artifacts. The understanding phase produces the MUST/SHOULD clauses.
  • Semester 7 (architecture decisions). An ADR's "Context" section is Polya phase one at system scale: the unknown (which way to go), the given (constraints and team), and the condition (non-functional requirements).
  • Semester 10 (capstone). The capstone lives or dies on a stable problem statement; stakeholders mutate prompts weekly, and the artifact is your only defence.

Check Yourself​

  1. What is the difference between reading a problem and restating it? Why is the restatement required, not optional?
  2. Why is a written assumption list a required output of understanding, not an optional extra?
  3. Give a problem where the constraint (time, memory, online) is more important to surface than the unknown itself.
  4. For Dijkstra's shortest-path algorithm, name the unknown, the given, and the condition in one line each.
  5. A prompt is under-determined when many answers satisfy it and over-determined when none do. Give one example of each.
  6. Why is "I recognise this is a graph problem" not yet an understanding? What artifact is missing?

Mini Drill or Application​

Drill A. Take this prompt: "Given a weighted undirected graph, find the minimum total cost to connect all vertices." Spend 10 minutes producing a one-sentence restatement, input/output specs with types and ranges, three explicit assumptions, and a hand-worked example on a 4-vertex graph. Do not solve it.

Drill B. Take this prompt: "Sort students by grade, then by name." Produce an understanding artifact that includes: null handling, case sensitivity, locale for name ordering, stability, and behaviour on ties. Your artifact should be at least five times longer than the prompt.

Drill C (unseen). Pick a problem from this week that you have not attempted yet. Write only the understanding artifact; stop before planning. Compare the artifact to the first attempt you make next session -- did the artifact prevent any wrong turns?

Read This Only If Stuck​