"It depends" is technically correct and practically useless as an opening line. The interviewer already knows it depends. What they are waiting for is the sentence that shows how you decide.
Say the constraint first
Almost every design question hides one unstated constraint: read-heavy or write-heavy, one region or many, latency budget, team size, budget. Name the constraint you are assuming before you name your solution.
Compare:
- "It depends. There are several options..." — the room waits.
- "Assuming read-heavy and a few milliseconds of allowed staleness, I would start with a read replica and a short cache." — now we are discussing engineering.
The second version can be argued with, and arguing with it is exactly the point. A wrong assumption out loud gets corrected in two seconds. A vague answer gets marked as vague and never recovers.
Commit, then qualify
Give a primary answer, then at most two caveats. Candidates who open with a menu of alternatives lose the thread of their own answer, and the interviewer stops following it. Candidates who commit and then name the one condition that would change their mind sound like someone who has shipped before.
The caveat is the interesting part. "I would do X unless the write path is the bottleneck, in which case I would do Y" tells the interviewer you know where the bodies are buried. It also gives them an easy follow-up, which is what they were going to ask anyway.
Where the third beat goes
Structure works the same way outside system design. For behavioural questions, context, action, result beats a chronological retelling every time — most stories collapse because the result arrives last, after the listener has already stopped caring.
The skill is the same in both cases: land the point early, then add detail only if asked.
That is the loop worth practising out loud. Speaking an answer exposes filler and buried conclusions that look fine on paper. MakeInterview runs that drill as a scored mock — you talk, it marks where the structure broke.
Related reading on this blog: practicing answers out loud, and why follow-up questions derail otherwise good answers.
Top comments (0)