English for developers: technical interviews
System Design Interview English: The Script for Talking Through Your Design
October 21, 2026
Knowing the vocabulary is not enough. This is the actual script: the phrases to clarify requirements, state assumptions, narrate tradeoffs, and handle pushback out loud, in order.
This is not a vocabulary list
A system design interview is scored as much on how you communicate your reasoning as on the design itself. Knowing what a load balancer or a shard is does not help if you go silent while you draw, or if you freeze the moment the interviewer pushes back.
This guide is the script: the actual phrases you say, in the order you say them, from the moment you get the prompt to the moment you wrap up. If you need the underlying vocabulary, our System Design Vocabulary guide covers that. If you want the full overview of every stage of a developer interview, our Coding Interview Questions guide covers that. This page is neither of those. It is the narration.
Key Takeaways
- Always attach a 'because' to a design decision out loud. That reasoning is literally what is being scored.
- State your assumptions explicitly instead of designing silently in your head.
- Treat pushback as a request to go deeper, not a signal that you did something wrong.
- It is fine to say 'I don't know X directly, but here's how I'd reason about it' instead of freezing.
- Always close with a one-line summary of the key decisions you made.
1. Clarifying requirements before you design
The first two minutes decide whether your design is built on solid ground. Ask about scale, consistency, and scope before you draw anything.
“What scale are we talking about, roughly how many users or requests per second?”
Always ask about scale before designing anything. It changes every decision you make next.
“Are we optimizing more for read-heavy or write-heavy traffic?”
This single question shapes your entire data model and caching strategy.
“Is strong consistency required here, or is eventual consistency acceptable?”
Signals you understand the consistency tradeoff before committing to a database choice.
“Should I assume this needs to support multiple regions, or is a single region fine for now?”
Geo-distribution changes your approach to latency and data replication.
“Just so I am scoping this correctly: are we designing the whole system, or focusing on one specific part?”
Prevents you from spending the first ten minutes on the wrong layer.
2. Stating your assumptions out loud
When the interviewer does not give you a number, do not design silently in your head. Say the assumption out loud so it can be corrected early if it is wrong.
“I am going to assume we have around 10 million daily active users unless you tell me otherwise.”
Stating a number out loud, even a rough one, shows you think quantitatively.
“Let's assume reads outnumber writes roughly 100 to 1, which is typical for this kind of system.”
Justify the assumption with a reason instead of just stating a guess.
“I will design for the common case first, and call out where the edge cases would need a different approach.”
Signals prioritization skill instead of trying to solve everything at once.
“Correct me if I am wrong, but I am assuming availability matters more than strict consistency here.”
Framing it as a question invites the interviewer to redirect you early, before you build on a wrong assumption.
3. Narrating tradeoffs as you draw
Every design decision is scored on the reasoning behind it, not the decision itself. Attach a 'because' to everything, and name what you are giving up.
“I am going with a message queue here instead of a direct call, because it decouples the two services if one goes down.”
Always attach the 'because'. The reasoning is what the interviewer is actually scoring.
“The tradeoff with this approach is lower latency, but we lose strong consistency. I think that is acceptable here because...”
Naming the tradeoff explicitly, instead of hoping the interviewer notices it, builds trust.
“I am adding a cache in front of the database here to handle the read-heavy traffic we discussed earlier.”
Reference back to the requirements you gathered. It shows the design is driven by constraints, not memorized patterns.
“An alternative here would be to shard by user ID instead of by region. I am choosing region because our reads are geographically clustered.”
Mentioning the alternative you rejected, and why, is stronger than only presenting one option.
“Let me walk through what happens when a write comes in, step by step.”
A useful transition phrase when moving from the high-level diagram to a specific flow.
4. Handling pushback without getting defensive
When the interviewer finds a hole in your design, that is the interview working as intended. Treat it as an invitation to go deeper, not a verdict.
“That's a good point. If traffic grew 10x, the bottleneck would move to the database layer. Here's how I would address that.”
Never get defensive. Treat pushback as the interviewer wanting you to think one level deeper, not an attack on your design.
“You're right, I did not consider that failure mode. Let me adjust the design.”
Acknowledging a gap directly is far better than arguing or over-explaining.
“Let me think about that for a second.”
It is perfectly acceptable to pause out loud instead of panicking into a rushed answer.
“Good catch. That would actually break under concurrent writes. I would fix that by adding an optimistic lock.”
Use 'good catch'. It signals confidence rather than embarrassment.
5. What to say when you do not know something
Freezing is the only real mistake here. Being honest about a gap while still reasoning out loud is exactly what a senior engineer does.
“I have not worked directly with that technology, but based on what I know about similar systems, I would expect...”
Honest, and still shows reasoning ability instead of just stopping.
“I am not 100% sure of the exact mechanism, but conceptually I believe it works like this.”
Separates what you are sure of from what you are inferring.
“That is outside what I have hands-on experience with. Can I reason through it out loud instead?”
Turns a knowledge gap into a chance to demonstrate your thinking process, which is what is actually being evaluated.
6. Wrapping up the interview
A strong close shows the interviewer you can hold the whole design in your head, not just the last part you were talking about.
“To summarize, the key decisions were a relational database for the core data, a cache for the read-heavy path, and a queue for the write path.”
Always close with a summary. It shows you can see the whole design, not just the last thing you talked about.
“If I had more time, the next thing I would dig into is the failure handling for the queue.”
A strong way to end, showing you know what is still unresolved.
“Does this address what you were looking for, or is there a part you would like me to go deeper on?”
Hands control back to the interviewer instead of guessing you covered everything.
Related articles
This page is the narration script, not the theory. If you need the underlying vocabulary, start here. If you want the full map of every interview stage, start there.
Ready to practice your English at work?
Lingua-e has interactive exercises built around real developer conversations: standups, code reviews, retrospectives, and more. Practice until it comes naturally.
Try Lingua-e for free
Written by
Roxana LafuenteLingua-e's founder
Roxana Lafuente is a software engineer with 8+ years of experience. At the beginning of her career, even though she had already passed the First Certificate in English, she still froze every time she had to speak up in the daily standup. That was a gap nobody was fixing. After 2,000+ standups, she figured out what actually builds fluency: practice that looks like your real work. She built Lingua-e so other developers wouldn't have to take the long road to feel confident working in an international development environment.