Why restate the problem and probe edge cases before writing any code in an interview?
answer
- when is being wrong cheapest?
- the statement is underspecified on purpose
- empty, one element, duplicates, negatives
- a misread costs more the later you catch it
- state assumptions aloud before coding
basics
~20 sClarifying is the cheapest place to be wrong. A couple of minutes spent restating the task and asking about empty input, single elements, duplicates and negative values beats thirty minutes spent solving the wrong problem.
solid answer
~40 sI restate the problem in my own words first, so the interviewer can correct my reading while correcting it still costs nothing. Then I probe the input: can the feed be empty, can it hold exactly one reading, can two readings share a timestamp, can a reading be negative after a hardware glitch. Each answer either removes a branch I would otherwise have guessed at, or names a case my solution has to handle. It is also signal: interview statements are underspecified on purpose, and diving straight into code reads as someone who will build the wrong thing quickly. I timebox it — a few targeted questions, not an interrogation — and then say out loud the assumptions I am proceeding on, so the interviewer can stop me if one is wrong.
go deeper
Be ready to say what you would ask before coding and why. Naming three concrete probes — empty input, a single element, repeated or negative values — lands far better than a general promise to 'ask clarifying questions'.
Explain the mechanics: a restatement in your own words, a handful of input questions chosen because their answers change your plan, then assumptions spoken aloud. Show you know when to stop asking and commit to an approach.
Demonstrate that you distinguish what you were told from what you inferred, and that you convert inferences into stated preconditions. Interviewers at this level watch whether you clarify in bounded time or use it to avoid committing.
Own the framing that requirements failures cost more than implementation failures, and that the clarify habit is the same one that catches the case a specification forgot. Be able to say how you would coach a team to it without turning every task into an interrogation.
## The claim Every minute of an interview makes being wrong more expensive. In the first two minutes, a misread requirement costs a sentence: "actually, ties should return every matching index." Twenty minutes in, the same misread costs the code you have written, the reasoning you built on top of it, and the composure you need for the rest of the session. Clarification is not politeness and it is not stalling — it is buying your mistakes at the lowest price they will ever be offered at. ## Restating is not repeating A restatement is a *compressed* version of the problem in your own words, with the parts you consider load-bearing made explicit. "So: I get a stream of temperature readings, each with a timestamp and a signed integer value, and I have to report the reading where the temperature was highest. Correct?" That sentence does three things. It exposes your reading of the task while it is still cheap to correct. It converts the interviewer from an examiner into a collaborator for a moment. And it forces you to notice the words you *cannot* restate confidently, which are exactly the ones to ask about. Echo-repeating the statement verbatim does none of this. If your restatement is the same length as the problem, you have not understood it yet. ## The standing edge-case checklist Most inputs are worth interrogating along the same few axes. For a sensor feed of timestamped readings: | Axis | The question | Why it changes things | |---|---|---| | Emptiness | Can the feed be empty? | Decides whether the output is even defined, and whether you need a guard before the first access | | Size one | Can it hold exactly one reading? | Anything comparing neighbours has no pair to compare | | Duplicates | Can two readings share a timestamp or a value? | Decides whether a tie rule is needed and whether keys are unique | | Sign | Can a reading be negative after a hardware glitch? | Rules out shortcuts that assume values only grow, and changes what a sensible initial "best so far" is | | Magnitude | How large can values and their totals get? | Decides the arithmetic you can trust | | Structure | Is the feed ordered? Deduplicated? | Decides whether you may exploit order or must establish it | You will not ask all six on every problem. Two or three, chosen because they plausibly change your approach, is the right dose. A question whose answer would not change anything you do is a question you can skip. ## The failure this prevents, and the one it does not The failure it prevents is solving a neighbouring problem beautifully. Candidates rarely fail because their loop was wrong; they fail because the interviewer wanted every index of the maximum and they returned one, or wanted the earliest timestamp on a tie and they returned the latest. That is a requirements failure, and no amount of coding skill recovers it after the fact. The failure it does *not* prevent is a wrong algorithm. Clarification tells you what "correct" means; it does not tell you how to get there. Do not let a clarification habit turn into a way of avoiding the moment when you have to commit to an approach. If you have asked three questions and the answers are no longer changing your plan, you are done clarifying. ## When the interviewer refuses to answer "That's up to you" is a common and deliberate response, and it is not a dead end. The correct move is to decide, say the decision out loud as an assumption, and note the alternative: "I'll return the earliest timestamp on a tie — if you'd rather have all of them, that's a change to what I collect, not to the scan." You have now converted an ambiguity into a stated precondition, which is defensible, instead of a hidden guess, which is not. The same phrasing works for anything you assumed without asking: naming it late is far better than being caught relying on it. ## What the interviewer is actually scoring Two things. First, whether you distinguish what you were *told* from what you *inferred* — that distinction is the entire skill, and it is the same one that separates engineers who read a ticket from engineers who read a ticket and find the case product forgot. Second, whether you can do it in bounded time. A candidate who asks twenty questions is as worrying as one who asks none: both signal someone who cannot start. Ask the few that move your plan, state your assumptions, and get to a baseline approach.
- How do you keep clarification from eating the interview clock?I only ask questions whose answer would change what I do next. Two or three usually cover it: can the input be empty or single-valued, can values repeat, can they be negative. Once the answers stop changing my plan, I state my remaining assumptions in one sentence and move to a baseline approach. Twenty questions signals someone who cannot start.
- The interviewer answers 'that's up to you'. What do you do?Decide, say the decision out loud as an assumption, and name the alternative and what it would cost to switch. That turns an ambiguity into a stated precondition I can defend, rather than a hidden guess I would be caught on later. Underspecification is often deliberate, and the scoring is on whether I notice and commit, not on which branch I pick.
- Which edge cases are worth asking about on almost any input?Emptiness, exactly one element, repeated values or keys, and negative or zero values. Those four change the shape of a solution more often than anything else: they decide whether the output is defined, whether a comparison has a partner, whether a tie rule is needed, and whether a shortcut that assumes growth is legal.
Restating a problem is the same move as reading an order back to a customer before it goes to the kitchen. It takes five seconds, it feels redundant, and it is the only cheap moment to catch that they said no onions.
saying these in an interview costs you the question
- Asking questions makes me look like I don't know the problem
- The examples I was given cover every case
- Edge cases can wait until the end if there is time
- Restating is just repeating what the interviewer already said
- Clarifying is stalling; strong candidates start coding immediately