A nightly sales rollup states the totals it wants instead of spelling out the steps - what does that hand the runtime?
answer
- what, not how
- the steps are left open
- freedom handed to an optimiser
- order, chunking, placement, strategy
- cost no longer readable from the text
basics
~20 sStating the result instead of the steps hands the runtime the choice of strategy: the order of the work, chunk sizes, placement and passes. You describe what; it decides how, and can change how without you editing anything.
solid answer
~40 sDescribing intent means the code names the result - totals summed by region for the period - and not the steps that produce it. Everything the description leaves open becomes the engine's to choose: the order stages run in, how the input is chunked and split across workers, where each stage runs, whether two described stages execute as one pass, and which concrete algorithm implements a grouping. The payoff is that the same text can be executed better, or on a different substrate, without being rewritten. The price is that you can no longer read the cost off the page: two descriptions that look alike can differ by orders of magnitude, so sooner or later you have to ask the engine what it actually did.
code
pseudocode · 9 linesfunction nightlyTotals(orders, targetYear):
return orders
.keep(function(o) return o.year == targetYear)
.project(function(o) return pair(o.region, o.total))
.groupAndSum(by = region)
// the text fixes: which orders count, and what a regional total means
// the text leaves open: visit order, chunk size, worker count, placement,
// and whether keep and project run as one passgo deeper
Be able to state the distinction in one sentence: the description names the result, the runtime picks the strategy. Then name one decision that moves - the order the work happens in is the easiest to defend.
Explain the exchange in both directions. The engine gains ordering, chunking, placement and algorithm choice; you lose the ability to estimate the work by reading the text, because text length is not proportional to cost.
Show where this bit you in production: a description whose cost moved without its text moving, and what you inspected to discover which strategy the engine had chosen that night.
Frame it as portability versus predictability. Intent-first descriptions outlive engine and substrate changes, but a job with a hard external deadline may be worth more with its cost pinned down than with its strategy left open.
## Two ways to write down the same nightly job Every night a job turns a day of order records into one total per region. There are two ways to write that down. A **mechanism-first** description names the operations and the order they happen in: take this record, test this field, add into this accumulator, move to the next. Read it and you know what the machine will do, because you wrote the *how* yourself. An **intent-first** description names the result and the relationships that define it: the totals are the summed amounts of the period's orders, grouped by region. It says nothing about the order records are visited in, how many are held at once, how many passes happen, or where the addition runs. Both are executable. The difference is how much of the *how* is still open at the moment the description is handed over. ## What the runtime is now allowed to choose When the description stops naming the mechanism, an optimiser or planner inside the runtime inherits decisions that used to be yours: - **Order of work.** Independent stages may run in any order it likes, including moving a cheap narrowing stage ahead of an expensive one - when it can see through both stages well enough to know that is safe. - **Chunking.** How much input is treated as one unit: a record at a time, a block at a time, or everything at once. - **Parallel split.** Whether the input is partitioned across workers, and into how many parts. - **Placement.** Where a stage runs relative to where the data already sits. - **Fusion.** Whether two stages written separately are executed together rather than one after the other. - **Physical strategy.** Which concrete algorithm implements a described relationship. A grouping is a relationship; more than one algorithm computes it. - **Materialisation.** Whether an intermediate result is written down or streamed straight into the next stage. None of these changes the answer. Every one of them changes the cost. That is the whole bargain: because you fixed the *what*, the engine may change the *how* freely - including changing it in its next version, or choosing differently for Tuesday's data than for Monday's. | The description fixes | The engine chooses | |---|---| | Which records are in scope | The order they are visited in | | What a regional total means | How many passes produce it | | The relationships between stages | Which stages become one stage | | The answer | The time, the memory and the bill | ## What you give up in exchange What you give up is not correctness; it is **predictability of cost**. In a mechanism-first description the work is on the page: you can count the passes, see the accumulator, and estimate the allocation. In an intent-first description the work performed is a function of three things you did not write - the engine, what it knows about the shape of the data, and its version. That asymmetry is the leak this subject exists for. Three words in the middle of a description can mean one cheap field read or one remote lookup per record, and the *shape of the text is identical either way*. A stage named in four characters can dominate the run. Nothing about the description's length, indentation or stage count is proportional to the work it causes. So the honest answer has two halves: 1. **The payoff.** The same description survives being executed better, being executed elsewhere, and being executed by a smarter engine later - with no edit. 2. **The leak.** Because the mechanism is not on the page, explaining a cost means looking past the description at what the engine actually did. ## Why an interviewer asks it The question separates a candidate who *adopted* a style from one who *chose* it. Anyone can say that declarative code is cleaner. The follow-through is naming what concretely moved - ordering, chunking, placement, strategy - and then naming the price, which is that you traded a readable cost model for an optimisable one. A candidate who claims the intent-first form is simply faster has the model backwards: it is not faster, it is *free to be made faster*, and whether that freedom pays depends on whether the engine has enough visibility and enough information about the data to beat what you would have written by hand. The second thing an interviewer listens for is what *takes the freedom back*. A description built out of pieces the engine cannot see into is still a description, but the planner can neither cost those pieces nor reason about moving them, so the plan drifts back towards executing the stages exactly as written. Intent-first only buys you optimisation freedom to the extent the engine can see what you meant.
- Does describing intent make the job faster?No - it makes the job's strategy changeable. Whether it ends up faster depends on whether the engine has enough visibility and enough information about the data to beat the strategy you would have written by hand. On a small, simple job the hand-written strategy often wins; on a large one, the freedom to split, reorder and place the work usually does.
- What in a description can take that freedom away again?Anything the engine cannot see through. A stage built from an opaque callback is a black box: the engine knows neither what it costs nor whether moving work across it is safe, so it plans conservatively around it. The more of a description that is opaque, the closer the plan gets to executing the stages exactly as written, and the less the intent-first form bought you.
Naming a destination to a driver instead of reading out turn-by-turn directions: you still arrive at the same place, but the route is now the driver's call - and your one sentence gives you no way to tell whether the trip will take ten minutes or an hour.
saying these in an interview costs you the question
- Claims a description of intent is simply faster than spelled-out steps
- Assumes the runtime guarantees the order in which records are visited
- Thinks naming the result removes the cost rather than hiding it
- Cannot name a single decision that moves to the engine
- Believes the result may differ when the engine picks another strategy