After reading a problem's constraints, what must your plan state before you write any code?
answer
- the interviewer is grading this step
- constraints are more than input size
- name the target before naming the tool
- time class and space class, both
- say what you ruled out and why
basics
~20 sA usable plan names the constraints that actually bind (input size, memory ceiling, whether data can be re-read), the time and space class you are targeting, the concrete steps and the data you keep, and what you rejected and why.
solid answer
~50 sThe plan is a short written artefact with five lines. First, the binding constraints, read from the statement rather than assumed: how big the input gets, whether a memory ceiling is stated, whether the data arrives as a stream you see once, whether the same input is queried many times. Second, the target class you are aiming at — **in time and in space**, because space is a constraint in its own right, not a footnote. Third, the approach at the level of steps plus exactly what data you keep resident. Fourth, what you ruled out and which constraint killed it. Fifth, the edge cases you will check: empty input, one element, all values equal, the extreme allowed value. Naming a structure is not a plan; a plan is a target plus the route to it.
go deeper
Be ready to say your plan out loud before you type: binding constraint, target class in time and space, the steps, and the edge cases. Practise it until it takes under a minute; interviewers notice its absence more than its polish.
Explain how each constraint narrows the candidate approaches — a memory ceiling, a single-pass input and a many-queries workload each eliminate different things. Show the space line being derived, including recursion depth and retained keys, not just guessed.
Demonstrate that you plan for the constraint that actually binds, and that you write down what you rejected and why. In production terms, an approach that fits the box beats a faster one that does not, and the plan is where that call is recorded.
Own the habit at team scale: reviews and design notes should require a stated budget and a rejected-alternatives line, so that later readers can tell an intentional tradeoff from an accident. Be ready to argue what belongs in that template and what is ceremony.
## Why the step exists Between reading a problem statement and typing the first line of code there is a short artefact that separates candidates who pass from candidates who thrash: a written plan. Interviewers grade it directly — most rubrics have a line for "stated an approach before coding" — but its real value is that it converts the statement's constraints into a commitment you can be held to. Without it, the constraints are read once, forgotten, and rediscovered halfway through an implementation that cannot satisfy them. ## The five lines a plan carries **1. The constraints that bind.** Not every number in a statement matters, and the ones that matter are often not sizes. Look for: how large the input can get; whether a memory ceiling is stated; whether the input arrives as a stream that can be read once, or sits in storage you may traverse repeatedly; whether the same input is queried many times (which pays for preprocessing) or once (which does not); whether the input may be modified in place; the range and duplication of the values; and whether the data already carries useful order. **2. The target class, in time and space.** State what you are aiming at before you choose a mechanism — "linear time, constant extra space" or "linearithmic time, linear extra space". Turning a numeric input bound into a class is its own skill and has its own home; the point here is that the plan must *name* a target, because a target is what makes the rest of the plan checkable. Space gets its own words: recursion depth is space, an auxiliary table is space, and a structure that retains one entry per distinct key is space proportional to the number of distinct keys, which is not the same as the number of items. **3. The approach as steps plus retained data.** Two or three lines: what you do in each pass, and what you hold onto between steps. "Keep a running count per category and the best pair seen so far" is a plan. "Use a lookup structure" is not — it names a tool without saying what it holds, what it is keyed by, or how big it gets. **4. What you rejected, and which constraint killed it.** This is the line most candidates skip and the one that buys the most credit. It proves the constraints were read, and it stops the interviewer re-proposing the idea you already considered. Rejection is often not about asymptotics at all: an approach can be perfectly fast and still inadmissible because it needs the whole input resident, or a second pass over data you only see once. **5. How you will check it.** Empty input, a single element, all values equal, the largest permitted value, and the ordering the statement never promised. Naming these in the plan means you write the code with them in mind rather than patching afterwards. ## A worked tiebreak A log-deduplication feature must emit each distinct request line once. Two target classes are viable. Sort the lines and scan for runs of equal neighbours: linearithmic time, but it needs every line resident at once. Or stream the lines and keep a set of the keys already seen: linear expected time, but the set holds one entry per *distinct* key, and the peak resident size is unknown before you run it. If the statement gives a hard memory ceiling and no bound on distinct keys, neither is automatically right — and the plan's job is to say so out loud: "the ceiling forbids holding all lines, so sorting the whole input is out; the seen-set is admissible only if distinct keys are bounded, which the statement does not promise, so I will ask." That sentence is worth more than either implementation. ## The failure mode this aims at The weak answer is "I'd use a hash-based lookup" — a mechanism with no target, no space line and no rejected alternative. Its close cousin is a plan that budgets time only. Both come from the same habit: treating the constraints as flavour text around the interesting part. In real work the same habit produces a feature that passes review and falls over on the first oversized input, because nobody wrote down what "oversized" meant. ## What good looks like out loud Thirty to sixty seconds, spoken before any code: the constraint you consider binding, the class you are targeting in time and space, the steps, the alternative you dropped and why, and the edges you will check. Then you invite correction — "does that match what you had in mind?" — which is cheap before an implementation exists and expensive after.
- The statement gives no memory limit at all. Does the plan still need a space line?Yes. An unstated limit is an unknown, not an infinity. Write down the space your approach actually uses — auxiliary tables, retained keys, recursion depth — and say what it grows with. Then ask what the real budget is. A plan whose space is written down can be re-judged in one sentence when the budget appears; a plan with no space line has to be redesigned.
- A deduplication feature can sort and scan, or stream and keep seen keys. The box has a hard memory ceiling. What does the plan say?It names the ceiling as the binding constraint, then states what each candidate needs resident: sorting needs every line at once; the seen-set needs one entry per distinct key. It commits to the class that fits the ceiling under the stated bounds, and records the assumption the other option would have needed. The explicit "this is what the ceiling rules out" line is the deliverable.
- How is a plan different from restating the problem in your own words?Restating confirms you read the input and output; a plan commits to a route. Restatement carries no target class, no retained data, no rejected alternative and no edge list, so nothing in it can be wrong yet. Do both — restate in one sentence to check understanding, then plan — but do not let the restatement stand in for the plan.
It is the difference between a route and a vehicle. "I'll take the car" answers nothing; "two hours, one fuel stop, avoiding the toll bridge because the load is over its limit" is a plan somebody can check before you leave.
saying these in an interview costs you the question
- Names a data structure and calls that a plan
- Budgets time only, never states space
- Treats an unstated limit as unlimited
- Starts coding and works the approach out mid-typing
- Ignores that the input arrives as a stream
- Never says which alternative was rejected