Technical Interview English: How to Think Out Loud in System Design
How to talk through a system design interview in English: structures, phrases, trade-off language, and worked examples. For non-native speakers who know the tech but struggle to express it clearly.
System design interviews are talking interviews. The hiring manager is not just evaluating your architecture knowledge — they are evaluating how you communicate under uncertainty, how you structure your thinking, and how you handle ambiguity. For non-native speakers, this is a double challenge: you need to speak fluent English and think through complex distributed systems at the same time.
This guide gives you the language scaffolding — the reusable phrases and structures — so you can focus your mental energy on the architecture, not on finding the right words.
Why thinking out loud is so hard
In a coding interview, silence is acceptable while you think. In a system design interview, silence is a red flag. The interviewer cannot see inside your head — if you stop talking, they assume you are stuck.
The trap for non-native speakers: you know what to think, but you slow down searching for the precise English phrase. By the time you find the phrase, you have lost the thread of your reasoning.
The solution: learn a small vocabulary of reusable connecting phrases that require zero search time. They become automatic — you can deploy them while your brain is working on the technical problem.
The structure of a system design answer
Most strong system design answers follow this structure:
1. Clarify requirements → 2. Estimate scale → 3. Define the API → 4. High-level design → 5. Deep dive into components → 6. Identify bottlenecks and trade-offs → 7. Wrap up
Each stage has its own vocabulary. Let’s build the phrase bank for each.
Stage 1: Clarifying requirements
Never start designing without clarifying what you are building. This signals senior-level thinking.
Functional requirements (what the system does):
“Before I start, I want to make sure I understand the scope. Are we designing the write path, the read path, or both?”
“Should the system support real-time updates, or is eventual consistency acceptable?”
“Are we handling file uploads, or just text data?”
“What are the most important user-facing features for this first version?”
Non-functional requirements (how well it must work):
“What are the latency requirements? Is this a latency-sensitive user-facing API, or can we tolerate a few seconds of processing time?”
“How many daily active users are we designing for? Roughly 1 million? 100 million?”
“What’s the expected read-to-write ratio — mostly reads, like a news feed, or balanced, like a messaging app?”
“Do we care about strong consistency, or can we accept eventual consistency for better availability and performance?”
Assumptions (state them explicitly):
“I’ll assume we’re designing for 10 million daily active users — let me know if that’s too high or too low.”
“I’ll assume the primary use case is read-heavy — about 90% reads, 10% writes.”
“I’m going to focus on the core happy path first and we can discuss edge cases after.”
Stage 2: Estimating scale (back-of-envelope calculations)
Interviewers respect candidates who do rough maths before designing. It shows you understand that scale shapes architecture.
Transition phrases:
“Let me do a rough back-of-envelope calculation before I start designing.”
“I’ll estimate the scale to understand what we’re dealing with.”
Calculation patterns:
“If we have 100 million daily active users, and each user sends roughly 10 messages per day, that’s 1 billion messages per day, or about 10,000 messages per second on average.”
“Assuming peak traffic is 5× the average, we need to handle around 50,000 writes per second at peak.”
“Each message is roughly 100 bytes. 1 billion messages per day × 100 bytes = 100 GB of new data per day. Over a year, that’s about 36 TB — we’ll need a scalable storage solution.”
“With a 10:1 read-to-write ratio, we’re looking at 500,000 reads per second at peak. That suggests we’ll need significant caching.”
Useful numbers to memorise for interviews:
- 1 million seconds ≈ 11.5 days
- 10 million DAU × 10 actions/day = 100 million events/day ÷ 86,400 = ~1,160 events/second
- 1 KB = 10³ bytes, 1 MB = 10⁶, 1 GB = 10⁹, 1 TB = 10¹²
Stage 3: Defining the API
Designing the API before the internals anchors the conversation and demonstrates product thinking.
Transition phrases:
“Before I draw the components, let me sketch the API surface — it helps clarify what the system needs to do.”
“I’ll start from the client’s perspective and define what API calls the system exposes.”
API description phrases:
“The client will call POST /messages with a JSON payload containing sender_id, recipient_id, and content.”
“The response will return a 201 Created with the assigned message_id and a server-side timestamp.”
“For reading the feed, we’ll use GET /feed?user_id=X&cursor=Y — I’m using cursor-based pagination to handle the high volume of items efficiently.”
“We’ll need a WebSocket connection for real-time delivery, but fall back to polling for clients that don’t support WebSockets.”
Stage 4: High-level design
Now you draw the architecture. Keep the first pass simple — don’t over-engineer at this stage.
Transition phrases:
“Let me start with a simple, naive design and then we’ll identify its limitations.”
“I’ll sketch the high-level components — the building blocks — before we dive into any one of them.”
“Here’s the simplest design that could work. We’ll refine it as we identify bottlenecks.”
Describing components:
“The client sends requests to an API gateway, which handles authentication and routes the request to the appropriate microservice.”
“The write service processes incoming messages and persists them to the primary database.”
“The notification service is responsible for delivering real-time updates to connected clients via WebSocket.”
“We have a message queue here — Kafka or SQS — that decouples the write path from the downstream processors. If the notification service is slow, the queue absorbs the backlog.”
Describing data flow:
“The request flows from the client → API gateway → write service → message broker → notification service.”
“On the read path, the client requests the feed → the feed service checks the cache first → on cache miss, it queries the database and populates the cache for subsequent reads.”
Stage 5: Deep diving into components
This is where you go deeper on one component. Pick the most interesting or challenging one, and explain your design choices.
Transition phrases:
“Let me zoom in on the storage layer — that’s where the most interesting trade-offs are.”
“I want to talk through the database choice in more detail.”
“Let me go deeper on the fan-out problem — this is the core scalability challenge for this design.”
Explaining choices:
“I’m choosing a NoSQL store here because the data is write-heavy and the access pattern is always by user_id — a relational schema doesn’t add value, and NoSQL gives us better horizontal scalability.”
“We’ll shard the database by user_id, so all of a user’s data lives on the same shard. This makes user-scoped queries efficient and avoids cross-shard joins.”
“I’m using a cache with a write-through strategy rather than write-back, because consistency is important here — we can’t serve stale data on the profile page.”
Stage 6: Trade-offs and bottlenecks
This is the most language-intensive part and the one where non-native speakers often struggle most. Strong candidates show they understand that every design choice has costs.
Identifying bottlenecks:
“The first bottleneck I see is the database write throughput — at 50K writes per second, a single primary node will be overwhelmed.”
“The fan-out problem: for a popular user with 10 million followers, writing to each follower’s feed on post would require 10 million database writes synchronously. That won’t scale.”
“The single API gateway is a potential single point of failure — we should deploy it in multiple availability zones.”
Trade-off language — the most important vocabulary:
| Phrase | When to use |
|---|---|
| ”The trade-off here is…” | Introduce a choice with two-sided consequences |
| ”The advantage of X is… however, the downside is…” | Compare options fairly |
| ”This approach sacrifices X in favour of Y” | Acknowledge what you give up |
| ”This is a classic consistency vs availability trade-off” | Reference CAP theorem |
| ”I’m optimising for the read path here at the cost of some write complexity” | Show you understand the imbalance |
| ”This works well at low scale, but will become a bottleneck at…” | Frame limitations honestly |
| ”If we needed stronger guarantees, we could…” | Show you know alternatives |
Full trade-off sentences:
“The trade-off with denormalising the feed is write amplification — every post triggers N writes (one per follower). The benefit is that reads are a single database lookup instead of an expensive join.”
“I’m choosing eventual consistency here because strong consistency would require distributed locks, which would significantly increase latency and reduce availability. For a social feed, users can tolerate seeing a post a few seconds late.”
“Using a relational database here gives us ACID guarantees, which simplifies the application logic. The trade-off is that horizontal scaling is harder than with a NoSQL store.”
“This design uses synchronous processing, which is simpler to reason about and debug. The downside is that a slow downstream service will block the entire request chain — we’d want to switch to async if latency becomes a problem.”
Stage 7: Wrapping up
Close the session confidently. Summarise what you built and propose next steps.
Wrap-up phrases:
“To summarise: I’ve designed a system that handles [core use case] with [key architectural decisions]. The main trade-offs we made were [X] for [Y] reasons.”
“The areas I’d want to explore further if we had more time are: the cache invalidation strategy, the cross-datacenter replication setup, and the monitoring and alerting design.”
“I didn’t cover security in detail — for a production system I’d add rate limiting per user, request authentication via JWT, and audit logging for compliance.”
“Does this architecture make sense? Is there a particular component you’d like me to go deeper on?”
Handling uncertainty
You will not always know the answer. The right response is not silence — it is structured thinking out loud.
When you are unsure:
“I’m not 100% certain about the exact capacity limits of Cassandra at this scale — I would verify this before committing to the choice. But architecturally, it makes sense because…”
“I know that Kafka is commonly used here, but I’d want to compare it against Kinesis given our AWS infrastructure. My assumption is that the cost and operational overhead would be lower with a managed service.”
“I see two approaches here and I’m not sure which is better — can I think through both?”
“I’ll make an assumption here: I’ll assume the read-to-write ratio is 10:1. If it were different, the design would change in [specific way].”
Fluency boosters for non-native speakers
These are hedge and connector phrases that make your reasoning sound structured even when you are still working out the details:
| Phrase | Purpose |
|---|---|
| ”Let me think through this step by step…” | Buys thinking time, signals organised mind |
| ”That’s a good question. My first instinct is…” | Acknowledges the question before answering |
| ”I want to come back to that after we cover…” | Manages the flow without losing threads |
| ”If I understand correctly, the requirement is…” | Confirms before committing |
| ”One thing I want to flag is…” | Introduces an important concern |
| ”Let’s zoom out for a second…” | Returns to the big picture |
| ”One alternative here would be…” | Shows you know multiple solutions |
| ”The reason I prefer X over Y is…” | Justifies your choices |
| ”I’ll simplify for now and we can add complexity later” | Sets expectations for an iterative approach |
| ”Does that make sense so far?” | Checks alignment and invites questions |
Common mistakes to avoid
1. Starting to design without clarifying Jumping straight to drawing a system without asking about scale or requirements looks junior. Always spend 2–3 minutes on clarification first.
2. Going too deep too fast Describing the B-tree structure of your database indexes in minute one — before establishing the high-level design — loses the interviewer. Breadth first, then depth.
3. Ignoring non-functional requirements Designing a system without mentioning latency, availability, or consistency requirements looks incomplete. Bring up the CAP theorem, SLAs, and failure scenarios proactively.
4. Not acknowledging trade-offs Saying “I’ll use X because it’s the best option” without discussing the costs of X is a red flag. Every choice has trade-offs — naming them demonstrates senior-level thinking.
5. Silence instead of thinking out loud A 30-second pause is worse than “I’m thinking about whether to use a relational or non-relational store here — let me work through the access patterns.” Keep the interviewer with you.
Quick vocabulary reference
| Term | Meaning in system design context |
|---|---|
| scalability | Ability to handle more load by adding resources |
| latency | Time for a single request to get a response |
| throughput | Requests/data processed per unit time |
| availability | Uptime; fraction of time the system is functional |
| consistency | All clients see the same data at the same time |
| partition tolerance | System works despite network splits (CAP theorem) |
| trade-off | A design choice where gaining X costs Y |
| bottleneck | The component that limits overall system performance |
| fan-out | One write triggering many downstream writes (e.g., push to followers’ feeds) |
| idempotent | Repeating an operation has the same effect as doing it once |
| eventual consistency | Data converges to the same state eventually, not immediately |
| sharding | Splitting data horizontally across multiple database nodes |
| replication | Copying data to multiple nodes for fault tolerance and read scaling |
| cache hit/miss | Whether requested data was found in cache (hit) or not (miss) |
| single point of failure | A component whose failure brings down the whole system |
The language patterns above are reusable across any system design question — URL shortener, Twitter feed, distributed key-value store, or payment system. Practice saying them out loud until they are automatic. When the words are automatic, your brain is free to focus on the architecture.