Interview Communication and Common Mistakes

A system design interview is scored largely on what the candidate says, not only on the final diagram. This article covers techniques for structuring the discussion, presenting assumptions and trade-offs clearly, and the typical failure modes that lower scores. The technical steps are described in the system design interview framework.

Structure the discussion

• State the plan first. Give the interviewer the outline: requirements, estimation, high-level design, deep dive. This allows them to redirect early.
• Announce transitions. Say which step is finished and which starts next.
• Keep one visible artifact. Maintain a diagram, a requirements list, and a numbers list where both people can see them.
• Work top-down. Draw the end-to-end path at low detail first, then refine specific components.
• Summarize decisions. After each significant choice, state it in one sentence: what was chosen, and why.

flowchart TD
    A["Ask and confirm requirements"] --> B["State assumptions"]
    B --> C["Propose design"]
    C --> D["Check with interviewer"]
    D -->|"redirect"| C
    D -->|"go deeper"| E["Deep dive with alternatives"]
    E --> F["State trade-off and decision"]
    F --> D

State assumptions explicitly

Every missing number or requirement is an assumption. Stating it converts a guess into a shared premise.

• Say the assumption in a form that can be corrected: "Assuming 100 million daily active users and a 10 to 1 read/write ratio, unless you want different numbers."
• Record it in writing next to the estimation.
• When the interviewer changes an assumption, update dependent numbers and say what changes in the design.

Drive trade-off discussions

A trade-off statement has four parts: the option, the benefit, the cost, and the condition under which the other option wins.

Example: "A relational database gives transactions and joins, which the order flow needs. It limits write scaling to what one primary can handle, so at higher write volume the data must be partitioned. At the estimated 1,000 writes per second, one primary is sufficient."

Practices:

• Present at least two options for every major decision (storage, fan-out strategy, consistency level, sync versus async).
• Tie the choice to a requirement or an estimate, not to preference or familiarity.
• Name the failure mode of the chosen option and the mitigation.
• Avoid absolute statements such as "NoSQL scales, SQL does not". Specify the access pattern and the limit.

Handle interviewer input

• Hints and questions are signals. A question such as "what happens if this node fails?" points to a gap. Address it directly, then continue.
• Redirects. If the interviewer moves to another area, follow. The requested area is the one being evaluated.
• Unknown topic. State what is known, reason from first principles about the requirements, and say what would need to be verified. Guessing product internals with false confidence is worse than reasoning openly.
• Disagreement. Explain the reasoning once, concisely. If the interviewer's constraint differs, adopt it and show how the design changes.

Common mistakes

Language that helps

Precise statements are preferable to vague ones:

• Instead of "we will use a cache", say which data is cached, the key, the eviction policy, the TTL, and how staleness is handled.
• Instead of "the database will scale", say how: read replicas, partitioning by which key, and the expected limit.
• Instead of "it is highly available", say which components are replicated, how failure is detected, and what the failover time is.

Example: answering a failure question

Interviewer: "What happens if the cache cluster goes down?"

Structured answer:

1. Effect: all reads fall through to the database. At the estimated 11,600 reads per second, the database (sized for about 1,200 writes per second plus cache misses) is overloaded.
2. Mitigation: replicate the cache so one node failure removes only a fraction of capacity; add read replicas; shed low-priority load, and limit concurrent database queries per key so a cold cache does not cause a stampede.
3. Trade-off: extra cache replicas cost memory, and load shedding returns errors to some users to keep the database available for the rest.
4. Detection: alert on cache hit ratio and database CPU, since both change before users report errors.

The answer states the effect with a number, gives a mitigation, names its cost, and returns to the design without leaving the interviewer's question unanswered.

Interview questions

• How should uncertainty about a component be handled? State the requirement the component must meet, describe candidate mechanisms and their trade-offs, and say which detail would be confirmed in practice. Reasoning from requirements is evaluated more than recall of product details.
• When is it correct to change the design during the interview? When a new requirement or a corrected estimate invalidates a decision. State what changed and which components are affected.
• Why is over-engineering penalized? Extra components add cost, latency, and failure modes. A design should be as simple as the estimated scale and requirements allow, with a stated path to scale further.
• What should be done if time is running short? Skip remaining detail in lower-priority areas, finish the end-to-end path, and use the remaining minutes to state bottlenecks and risks.