Interview English for System Design Rounds: Phrases That Show Senior Thinking

A system design interview tests two things at once: can you design the system, and can you communicate the design clearly? If English isn’t your first language, the second half can sink you even when your engineering is excellent. The good news: system design interviews are highly scripted. The same five phases come up every time, and there’s a set of phrases for each. Learn them and you’ll sound like a senior engineer who’s done this many times.

The five phases (and what to say in each)

1. Clarify requirements
2. Estimate scale
3. Propose a high-level design
4. Deep-dive and discuss trade-offs
5. Address bottlenecks and wrap up

Let’s script each one.

Phase 1: Clarifying requirements

Never start designing immediately — interviewers want to see you scope the problem. Useful openers:

• “Before I jump into the design, I’d like to clarify the requirements.”
• “Let me make sure I understand the scope. Are we designing X, or also Y?”
• “What are the functional requirements versus the non-functional requirements here?”
• “Should I assume this is read-heavy or write-heavy?”
• “Is strong consistency required, or is eventual consistency acceptable?”

“Let me clarify the scope. Are we designing the URL shortener’s write path — creating short links — the read path — redirecting — or both? And do we need analytics, or is that out of scope?”

Asking these questions shows maturity. Interviewers often say the candidate who clarified scope well had already half-passed.

Phase 2: Estimating scale (back-of-the-envelope)

You’ll be expected to do rough math out loud. The English for “rough math” is back-of-the-envelope estimation. Useful framing:

• “Let me do a quick back-of-the-envelope calculation.”
• “Let’s ballpark the numbers.”
• “Assuming roughly 100 million daily active users, and each making 10 requests, that’s on the order of a billion requests a day.”
• “So we’re looking at roughly 10,000 requests per second at peak.”

Vocabulary for magnitude:

• on the order of — approximately, in that range
• an order of magnitude — 10x
• peak vs. average load
• steady-state — normal, ongoing operation

“At steady state we’d expect around 5,000 writes per second, but I’d design for peak at maybe 3x that to be safe.”

Phase 3: Proposing a high-level design

Present the big picture before details. Narrate as you draw:

• “At a high level, I’d put a load balancer in front of a stateless application tier.”
• “The request flows from the client, through the gateway, to the service layer, and into the data store.”
• “I’ll start simple and we can iterate from there.”

Signposting phrases keep the interviewer with you:

• “There are three main components. First… Second… Third…”
• “Let me walk you through the request lifecycle.”
• “Zooming out for a second, the key idea is…”
• “Zooming in on the database, here’s how I’d shard it.”

Phase 4: Trade-offs — the most important English

This is where interviewers separate senior from mid-level candidates. Seniors don’t claim there’s one right answer; they discuss trade-offs.

• “There’s a trade-off here between consistency and availability.”
• “We could go with SQL or NoSQL. The case for SQL is strong consistency and joins; the case against is harder horizontal scaling.”
• “I’d lean towards caching here, but with the caveat that we’ll need a cache-invalidation strategy.”
• “It depends on whether we prioritise latency or cost.”
• “There’s no free lunch — buying availability here costs us consistency.”

“We could denormalise to speed up reads, at the cost of more complex writes. Given this is read-heavy, I’d make that trade-off and accept the write complexity.”

Decision phrases (commit, don’t waffle):

• “On balance, I’d go with…”
• “Given the constraints, my recommendation is…”
• “I’ll default to X unless you’d like me to optimise for Y.”

Phase 5: Bottlenecks and wrapping up

Show you can find the weak points in your own design:

• “The obvious bottleneck is the database write path.”
• “This is a single point of failure — let me add a replica.”
• “To scale this out, I’d introduce sharding by user ID.”
• “If I had more time, I’d harden the failure modes — what happens when the cache goes down?”

Closing the interview:

• “To summarise, we have a stateless tier behind a load balancer, a sharded data store, and a cache for the read path.”
• “The main risks are X and Y, and here’s how I’d mitigate each.”

Handling pushback gracefully

Interviewers will challenge you on purpose to see how you react. Don’t get defensive. Buy time and engage:

• “That’s a fair point — let me reconsider.”
• “Good catch. You’re right that wouldn’t scale. Let me adjust.”
• “I see what you mean. An alternative would be…”
• “Can I take a moment to think that through?”

If you genuinely don’t know:

• “I’m not certain, but my intuition is that… — I’d want to validate it with a load test.”

Admitting uncertainty calmly reads as senior. Bluffing reads as junior.

Common mistakes non-native engineers make

1. Silence while thinking. Interviewers can’t read your mind. Narrate: “Let me think out loud for a second.”
2. Saying “I will do” instead of “I’d do.” Use the conditional — “I’d use a queue here” — it sounds more like reasoning than a fixed plan.
3. “More better,” “more faster.” Just better, faster. And prefer higher throughput, lower latency.
4. Over-apologising. One “good catch” is enough; don’t say “sorry” repeatedly.

A 20-second opening script to memorise

“Thanks. Before I design anything, I’d like to clarify the requirements and agree on scope. Then I’ll do a quick back-of-the-envelope estimate of scale, sketch a high-level design, and we can deep-dive into whichever component you find most interesting. Along the way I’ll call out the trade-offs I’m making. Does that approach work for you?”

Say that, and you’ve already signalled structure, seniority, and fluency in the first 20 seconds.

Key takeaways

• System design interviews follow five predictable phases — script each one.
• Clarify scope first. It’s half the battle.
• The language of trade-offs is what marks a senior engineer: the case for/against, at the cost of, on balance.
• Narrate your thinking out loud and use the conditional (“I’d use…”).
• Handle pushback with “fair point” and “good catch,” and admit uncertainty calmly — it builds trust.