Solving an Unseen Problem in Six Steps

Clarify, work examples, state the slow answer, find what makes it slow, write, trace: each step catches a mistake the next one would hide.

Solving a coding problem you have not seen before is a fixed sequence of six steps, taken in the same order whatever the problem: clarify it, work two examples by hand, state the slow answer and its cost, find what makes it slow, write the code, and trace an example through it. This card names each step, what it leaves on the page, and the mistake it stops. You use the sequence at the start of every interview problem and every unfamiliar task at work, so the first thing you face is a question rather than a blank editor.

Three words recur. A brute-force solution tries every candidate answer directly, such as checking every pair of items, with no cleverness at all. The bottleneck is the part of a solution that dominates its cost, usually a loop running inside another loop. An edge case is an input at the boundary of what is allowed: an empty list, a single item, every item equal. The six steps are these.

The six steps for an unseen problem

1. Clarify

Ask about the input, the output and the limits until nothing is assumed: how large the input can be, the range and sign of its values, whether duplicates appear, what an empty input should return, and the exact form of the answer.

Produces: a short list of facts, including the largest input size. Prevents: solving a problem slightly different from the one asked.

2. Work examples

Work two small inputs by hand, one ordinary and one an edge case, and write down the answer each should give.

Produces: test cases with known answers. Prevents: finding out halfway through the code that the problem was misread.

3. State the brute force

Describe the most direct correct solution and its cost in Big O.

Produces: a correct fallback and a cost to beat. Prevents: chasing a clever idea that turns out to be wrong, with nothing correct to show for the time.

4. Find the bottleneck

Name the part that dominates the brute force's cost, then choose a structure or pattern that removes it, within the budget the limits set.

Produces: the approach and its cost. Prevents: speeding up a part of the solution that was never slow.

5. Write

Write the code for the chosen approach, with names that say what each variable holds.

Produces: the listing. The other five steps prepare for it.

6. Trace

Follow the code line by line on the examples from step 2, edge case included, and compare its answers with the ones worked by hand.

Produces: evidence that the code does what was planned. Prevents: handing over code that fails on the first input anyone tries. A disagreement sends you back to step 4 or 5.

The questions in step 1 are the ones nearly every problem shares. The limits decide how fast the solution must be. The range and sign of the values decide which starting values are safe. Duplicates decide whether a set is enough or a count is needed. The empty input decides what the function returns when there is nothing to return. In an interview the interviewer answers them; in a written problem the statement does, and anything it leaves open becomes a decision you state aloud.

The brute force comes before any faster idea for three reasons. Stating it proves the problem is understood, because nobody can write a correct slow answer to a problem they have misread. It gives a second solution whose answers a faster one must match. And its cost, set against the limits, says whether anything needs to improve at all: sometimes it already fits, and then it is the answer.

A pilot works through the same checklist before every take-off, whatever the aircraft, because the item that gets skipped is the one that matters on the day. The likeness breaks in one place. A checklist item is ticked once and left behind, while this sequence loops: a trace in step 6 that disagrees with a hand-worked answer sends you back to step 4 or 5, and the steps after it run again.

← → move through sections and cards