Skip to main content

Cluster 5: Bridge to Computing

Earlier practice pages drill on textbook-shaped problems. This one drills on the three frictions that appear when problem-solving moves from paper to real systems: writing a spec from a vague prompt, reading code you did not write, and triaging under a clock.

How To Use This Page​

  1. Finish the three cluster-5 concept pages first (13, 14, 15).
  2. Work each drill in a single sitting. Do not skip the writeup.
  3. Keep a short note after each: what was hard, what pattern you plan to reuse.
  4. Swap specs and writeups with a peer if possible. The ambiguities that hide from you will not hide from them.

Drill 1: Spec-Writing Warm-Up​

Translate each informal prompt into a formal spec using the protocol from concept 13. Your output must contain, at minimum: input types with ranges and null behavior, output types, one primary sort or decision key, all tie-breakers, at least three failure modes, one performance constraint, and an explicit determinism statement.

Prompts:

  1. "Deduplicate the customer list before we email them."
  2. "Show the most relevant search results first."
  3. "Pick the top three candidates from the applicant pool for a phone screen."
  4. "Batch the retry queue so we do not overload the downstream service."

For one of the four, also write three positive test cases and three adversarial test cases consistent with the spec. If any adversarial case is not covered by the spec, extend the spec -- do not patch the test.

Drill 2: Code-Reading Lab​

Pick two unfamiliar 30-60 line functions -- one from a codebase you work in, one from an open-source project you do not. For each, before running the code, produce:

  1. A one-paragraph hypothesis of what it does.
  2. The invariant of the main loop or recursion, written as a full sentence.
  3. The termination measure.
  4. A simulation table: n = 0, n = 1, n = 2, n = 10, with the input, your predicted output, the observed output, and a match / mismatch column.
  5. If mismatch: a classification (model / plan / execution bug, or "no bug; hypothesis wrong") and a one-sentence note on where your reading went off.

At the end, write a comparison: was the open-source function easier or harder to read than the internal one, and why? This comparison trains your intuition for what makes code legible.

Drill 3: Invariant and Boundary Trace​

Without running it, predict the behavior of this function on the inputs below. Then run it and check.

def f(a):
    n = len(a)
    if n == 0:
        return -1
    best_sum = a[0]
    curr = a[0]
    for i in range(1, n):
        curr = max(a[i], curr + a[i])
        best_sum = max(best_sum, curr)
    return best_sum

Inputs:

  1. []
  2. [5]
  3. [-1, -2, -3]
  4. [1, -2, 3, 4, -1, 2]
  5. [0, 0, 0, 0]

For each input, predict the output, the value of the invariant curr == maximum sum of a contiguous sub-array ending at i, and whether the predicted termination measure (n - i) decreases each iteration.

Drill 4: Triage Rehearsal​

Pick one of these scenarios. Set a 30-minute timer. At the end, deliver the short writeup described in concept 15.

Scenarios:

  1. A nightly data pipeline produced totals that disagree with the reconciliation report by about 0.3%. The CFO wants an update by end of day.
  2. A flaky test is failing on roughly 1 in 20 CI runs. The release branch cuts in an hour, and the test guards a critical invariant.
  3. A customer reports they cannot log in, but other customers on the same tenant can. Support has escalated; the customer is a top-five account.

Produce, in order:

  1. At least four candidate sub-problems.
  2. For each, estimated cost in minutes, information value, and reversibility (reversible / irreversible).
  3. Your triage ordering, with a one-sentence justification.
  4. A defensible writeup at minute 30 following the template: what was asked, what was decided, evidence, what was not checked, what would change the conclusion.

If you get to a real answer before the deadline, still write the report; reporting is the skill.

Drill 5: Spec Against Code​

Hand a peer (or yourself, a day later) one of the specs you produced in Drill 1 without the prompt. They implement a function to the spec. Compare their function's behavior on five adversarial inputs to what you expected.

Outcomes to notice:

  • adversarial cases where the spec was ambiguous -> rewrite the spec to remove the ambiguity
  • adversarial cases where the spec was correct but the reader misunderstood it -> this is a legibility problem; simplify language, not rules
  • adversarial cases where both you and the reader agreed but the behavior was wrong -> the intent was under-specified, not just the spec

Each of these is a different failure mode and each has a different fix.

Evidence Check​

This page is complete only if:

  • you have produced at least three full specs from informal prompts, each one that another engineer could implement without asking a clarifying question
  • you have read and correctly classified the behavior of at least two unfamiliar functions using the invariant-and-termination protocol
  • you have run one timed triage drill and produced the final writeup under the deadline, not after

Read This Only If Stuck​