Before coding, why hand-trace a 3-element input with tied readings and a 1-element input?
answer
- a trace can fail the statement, not the code
- what if two readings tie?
- earliest, latest, or every match?
- size one removes every comparison
- empty input often has no defined answer
basics
~20 sTiny traces test the problem statement, not just the code. A tie exposes an output rule nobody stated — first match, last, or all of them — and a one-element or empty input exposes whether the output is defined at all.
solid answer
~50 sA trace before coding is a probe against the requirement, not a check on my implementation. Take a scan that keeps the best index so far and run it on three readings where two tie for the highest value: it returns the first of the tied pair, and the moment I say that out loud the real question surfaces — was the earliest tied reading wanted, the latest, or all of them? The statement never said. A one-element feed asks a different question: does the output format still make sense with nothing to compare against. An empty feed asks whether there is any defined answer at all, or whether the contract is an error. All three take seconds on paper and each one can change what I build, which is why they come before the code and not after it.
code
pseudocode · 9 linesbest = 0
for i in 1..length(readings)-1:
if readings[i] > readings[best]:
best = i
return best
// [7, 7, 3] -> strict compare never fires -> returns 0, the earliest tie
// [7] -> loop body never runs -> returns 0
// [] -> loop body never runs -> returns 0, an index into nothinggo deeper
Practise walking a three-element input aloud, stating the state after every step. The habit of narrating rather than eyeballing is what makes a tie or an empty case visible before you write anything.
Explain that a pre-coding trace probes the requirement while a post-coding trace checks the implementation. Show that you know which tiny inputs are productive: empty, single element, and one carrying a deliberate tie.
Demonstrate that you treat an undefined case as a contract decision to be raised, not a branch to be invented. Interviewers are watching whether you notice the ambiguity yourself or only when asked about it.
Own the broader point that undefined behaviour at empty and tied inputs is where specifications quietly disagree between teams, and that the cheapest place to settle it is in the statement, not in each caller's defensive handling.
## Two different jobs share the name "trace" After you have written code, tracing an input verifies that the code does what you meant. Before you have written code, tracing verifies that what you *mean* is fully determined. These are not the same activity, and the second is where the expensive mistakes live. A correctness bug found in a trace costs a line; an ambiguity discovered after twenty minutes of implementation costs the design. The pre-coding trace works by executing your intended approach on an input small enough to hold in your head, then asking a specific question: *did I have to make a decision the problem statement did not make for me?* If yes, that decision is an ambiguity, and you should raise it. ## Ties are the most productive tiny input Consider the stated task "report the index of the largest reading" and the obvious scan that remembers the best index seen so far. On readings `[7, 7, 3]`, the strict comparison never fires for the second seven, so the scan returns index 0 — the *earliest* of the tied pair. Flipping the comparison to non-strict would return index 1, the latest. Both are defensible implementations of the sentence you were given, which means the sentence does not determine the answer. That is the finding. Note what it is not: it is not a bug. There is nothing to fix, because there is no specification saying which is right. The correct response is to name it — "with a tie I'll return the earliest; if you want the latest that's one comparison, and if you want all of them I collect a list instead of an index" — and let the interviewer choose or explicitly decline to. Interviewers underspecify tie behaviour deliberately, because it is a cheap, reliable separator. Candidates who trace find it in ten seconds. Candidates who do not find it when the interviewer asks, at the end, "what does your code do if two readings are equal?" ## One element and none A one-element input is not the same probe. It removes every comparison, so anything defined in terms of neighbours, differences, or pairs has nothing to work on. Sometimes the answer is obvious and the trace is a formality; sometimes it reveals that the stated output shape assumed at least two items existed. An empty input is the sharpest of the three, because it usually has no defined answer at all. In the scan above, the loop body never runs and the initial best index is returned — an index into a feed with no elements. There is no correct value to return here; the resolution is a contract decision. Is empty impossible by precondition, is it an error, or is there a designated empty result? Those are three different programs, and only the interviewer can pick. ## Doing it on paper, out loud The mechanics matter less than the discipline, but a few habits pay: - **Pick inputs that are adversarial in one dimension only.** Three elements with one tie beats a ten-element input with several complications; when a small input surprises you, the cause is unambiguous. - **Narrate the state, not the code.** "Best is index 0 with value 7. Second reading is also 7 — strict comparison, so no update. Third is 3, no update. Return 0." That narration is what makes the tie visible. - **After each trace, ask the same question.** Did I decide something the problem did not decide? That is what turns a trace into a specification probe. - **Write the traced cases down.** The same three inputs become your verification set later, so the work is not spent twice. ## The failure mode this targets The wrong belief is that tracing belongs after coding — that examples are for checking work. Under that belief, ambiguities surface at the worst possible time, and they surface as the interviewer's question rather than your observation, which is a materially worse outcome even when your answer is the same. The distinction between "I noticed the statement was ambiguous and picked a rule" and "I did not notice until you pointed at it" is one of the clearer signals available in a forty-five minute conversation. The second wrong belief is that trivially small inputs are beneath attention. In practice, size zero, size one, and "two things are equal" are where output contracts turn out to be undefined, precisely because they are the cases nobody thought about while writing the sentence you were handed.
- The interviewer says either tie rule is fine. What now?Pick one, say it aloud as the rule I am implementing, and name what the alternative would cost — usually one comparison for earliest versus latest, or collecting a list instead of a single index if they want all matches. That converts the ambiguity into a stated decision, which is defensible, and it takes about five seconds.
- Why trace before coding rather than mentally running the finished code?Because the two traces answer different questions. Afterwards, a trace confirms the code matches my intent. Beforehand, it interrogates whether my intent is even determined by the problem statement. Ambiguities found afterwards cost the implementation built on top of them, and they usually surface as the interviewer's question instead of my observation.
- How do you choose which tiny inputs to trace?One dimension of difficulty each: an empty input, a single element, and one small input carrying the specific complication I suspect — a tie, a repeat, a negative value. Small and adversarial in one way means that when the trace surprises me, the cause is unambiguous. I keep the same cases as my verification set afterwards.
saying these in an interview costs you the question
- Tracing is for after the code is written
- Ties cannot happen, the example had none
- Empty input is the caller's problem, not mine
- A one-element case is too trivial to be worth checking
- A tie returning the first match is simply the correct behaviour