skip to content

On a code request where the approach is the risk, why ask for that before any code?

level: seniorimportance: nice to knowfreq 34%

answer

  1. which artefact do you end up reading?
  2. working code resists being thrown away
  3. decisions stated, not implemented
  4. a plan is not a guarantee

basics

~20 s

Asking for the approach first moves your review to the cheapest artefact: four lines read and rejected in seconds, against a working function that is expensive to read and hard to reject once it runs. Use it where the decisions carry the risk.

solid answer

~50 s

This is a question about where my attention is spent. Asked for a parser for a fixed-width statement line, the risky part is rarely the slicing — it is the decisions: which field holds the sign, whether the amount carries an implied decimal point, what happens to a line that is short. If those are wrong, four lines of stated approach show it immediately, and rejecting four lines costs nothing. The same mistake inside a finished function costs a careful read, and working code is harder to throw away than a sentence. So on requests where the approach is the risk, I ask for it first and hold the code back one turn. Where the shape is obvious it is pure overhead and I skip it. Either way the plan is not a guarantee — I still read the code against it.

code

text · 23 lines
text
THE REQUEST - the last sentence is the one doing the work
  Before any code: in four lines, one per decision, how will you parse a single
  fixed-width bank-statement line into a record? Do not write the function yet.

WHAT CAME BACK
  1. Slice the line by column position into date, description, amount, indicator.
  2. Trim the padding from each field.
  3. Read the amount field as a decimal number.
  4. Treat a line shorter than the record length as malformed and skip it.

THE DECISION THAT IS WRONG, VISIBLE BEFORE ANY CODE EXISTS
  Line 3. This format carries the amount as whole minor units with no decimal
  point: "000000123456" means 1234.56. Read as a decimal number it becomes
  123456, and stored in a record field that means major units, every imported
  amount is then a hundred times too large.

WHAT IT COST TO CATCH IT HERE
  Reading four lines, and one clause added to the request for the code.

WHAT IT WOULD HAVE COST IN A FINISHED FUNCTION
  Reading working code in which that decision is one conversion call among
  thirty lines that all look correct, and that no test you have written yet
  would fail on.

go deeper

for a junior

The idea to hold on to is that you will read something either way, and four lines of stated approach are far quicker to read and to reject than a finished function.

for a middle

Explain why working code is harder to reject than a sentence, and be able to say which requests deserve the extra turn — those where the decisions, not the syntax, carry the risk.

for a senior

Show that you bound it: skip it where the shape is obvious or a deterministic check is cheaper, and treat an approved approach as the thing you read the code against rather than as clearance.

for a principal

The tradeoff to own is where a team's review attention goes. Moving scrutiny earlier is cheap for decisions no automated check can judge, and pure overhead wherever a fast objective check already exists.

## You are choosing where the review happens Every code request produces something you have to read. The only question is what. If you ask straight out for **one function that parses a fixed-width bank-statement line into a record**, the thing you read is a finished function: thirty lines of slicing, trimming and conversion, in which the decisions that matter are implicit and have to be reverse-engineered from the code that implements them. If you ask first for the approach and hold the code back a turn, the thing you read is four sentences in which those decisions are most of the content. Two properties make the second artefact cheaper, and the second property is the one people miss: - **It is short**, so reading it costs seconds rather than minutes. - **It is not yet an investment.** Working code exerts a pull — it exists, it runs, and rejecting it feels like throwing away progress, so the honest tendency is to look for the smallest repair rather than to ask whether the approach was right. Four lines of prose exert very little of that pull. ## What makes an approach cheap to reject - The decisions are **stated rather than implemented**, so a wrong one is visible as a claim instead of being distributed across the code. - The decisions sit **side by side**, which makes an inconsistency between two of them obvious in a way it is not when they are forty lines apart. - There is **no correct-looking implementation** to distract you. A wrong decision written plainly is easy to spot; the same decision expressed as careful, well-named, working code has camouflage. - It is **cheap to change entirely**, so "do it a different way" is a reasonable thing to say, which it stops being once code exists. ## When the approach is the risk, and when it is not | The request | Where the risk sits | Worth asking first? | |---|---|---| | Parse a format whose conventions you know and it may not | The decisions: units, sign, padding, short lines | **Yes** | | Restructure something with several defensible shapes | The choice of shape | **Yes** | | Anything touching an interface others depend on | What is exposed and what it promises | **Yes** | | A routine with one obvious implementation | Nowhere interesting | No — it is a wasted turn | | Something you can check deterministically in seconds | The check, not the reading | No — run the check | That last row is worth stating plainly. **Where a cheap objective check exists, the check is a better answer than a plan**, because it does not depend on your reading being right. Asking for the approach is most valuable exactly where the wrong decision would produce something that passes the checks you have — which is what a parser with the wrong amount convention does. ## What a stated approach does not guarantee It does not guarantee the code follows it. The plan and the code are two separate answers, and the second can quietly diverge from the first — so approving a plan does not discharge reading the result, it only tells you what to read it against. Used well, that is a benefit rather than a limitation: you now hold an explicit statement to compare the code with, which is a much sharper review than asking whether the code seems reasonable. It also does not make the plan right. An approach can be internally coherent, plausibly written and still wrong about your format, because it was produced without knowledge you did not supply. You are not delegating the decision when you ask for the approach — you are surfacing it early enough to be cheap to fix. And this is not a claim that deliberating first makes the answer better in general; that question belongs to prompting theory and has its own literature. The claim here is narrower and about economics: **the plan is the cheapest artefact you can reject.** ## Keeping it to one exchange The practical form is one extra turn, not a process: 1. Ask for the approach in a fixed, small budget — four or five lines, one line per decision — and say explicitly not to write the code yet. Without that clause you usually get the code anyway, with a summary on top. 2. Read it for the decisions you already know the answers to. Those are the ones you can judge instantly, and they are where the value is. 3. Correct the wrong one **in the request for the code**, not as a separate exchange, so the whole thing stays two turns. If you find yourself in four turns of plan discussion, the unit is probably too big for one request. ## Answering this in an interview Frame it as review economics rather than as a prompting trick: you are moving your attention to the artefact that is cheapest to read and cheapest to reject, and you are doing it before working code creates a reason not to reject anything. Then bound it — where the decisions carry the risk, and not where a deterministic check is available and quick — and state the limit plainly, which is that an approved plan is something to read the code against, not a substitute for reading it.

  • How do you stop the answer writing the code anyway?
    Say it explicitly and give the plan a small budget — four or five lines, one per decision, and do not write the function yet. Without the negative you usually get the implementation with a summary on top, which puts you back in front of the expensive artefact.
  • When is asking for the approach first actively wasteful?
    When the implementation is obvious, and when a cheap deterministic check already settles the question. A check that runs in seconds beats a plan you have to read, because it does not depend on your reading being right.
  • Once you have approved the approach, what do you still read the code for?
    Whether it followed the approach, and what it decided that the approach never mentioned. The plan gives you something explicit to compare against, which is a sharper review than judging whether the code looks reasonable — but it replaces nothing.

saying these in an interview costs you the question

  • Ask for the approach on every request — it is free
  • An approved plan means the code needs only a skim
  • Asking for reasoning first makes the code correct
  • A plan is slower, so go straight to the code always
  • If the plan is coherent, it is right about your format