What to Say in a System Design Interview: Twelve Sentences for Asking About Scale, Setting Scope, Stating Trade-offs, and Committing to a Decision

🌏 中文版

This is the third piece of interview speaking. After coding interviews and handling follow-up questions, what remains is the system design interview.

The examples use selected passages from mock-interview transcripts, not complete records of actual hiring interviews. Speech-to-text errors are possible and the wording has not been checked line by line against audio. Use the examples to practise requirements, trade-offs and follow-ups, not to establish register, regional differences or how to pronounce capacity figures.

What I was trying to say

There is no coding in a system design interview. Google's official guidance video says two things at the start:

You will not be coding in this interview. There will also be significant time constraints. We'll expect you to gather requirements and to develop an initial solution in the first 20 minutes.

So the whole session is talking, and the question is vague on purpose. The same video says:

The problem you will solve during your interview will be deliberately underspecified. … You will need to ask clarifying questions.

What I need to practice is three stretches of talk:

1. Opening by pinning down scale and scope
2. Talking while drawing, and saying my assumptions and what I am skipping for now
3. Stating trade-offs, committing to a decision, and pointing out weaknesses

The sources this time:

• An employer's official guidance: Google's Prepare for Your Google Interview: Systems Design video. It states expectations only and has no example dialogue
• Community teaching material: the System Design Primer on GitHub, whose section on how to approach a question lists questions you can ask as written
• A guide from a mock interview platform: interviewing.io's System Design Interview Guide
• Transcripts of mock interviews: three system design mock interviews published by interviewing.io. These are actual conversations, converted from speech to text, and the speakers are anonymous

Each transcript runs to between forty and sixty thousand characters. I did not read them from start to finish. I searched for what candidates say for each function and then read the passages around each sentence.

What you can say in this situation

1. Opening: ask about scale, set the scope

The middle three are quoted from the System Design Primer. It calls its first step Outline use cases, constraints, and assumptions and lists eight questions; some of the others are Who is going to use it?, How are they going to use it?, and How much data do we expect to handle?.

Google's guidance asks for numbers as well: We want to see numeric estimates for these properties, such as how many requests per second the system can handle.

The first and last sentences come from the mock interviews. The candidate in the inventory and orders session opens with the first thing I want to lay out is the functional requirements. The candidate in the photo sharing session asks do you want to go through the delete case in the scope of this design or should we just… handle the creation and the visibility case?; I kept only the first half and replaced go through with handle. In the feedback afterwards, this candidate is praised for asking clear questions about the functional requirements.

2. Talking while drawing: state the assumption, park the detail

Both come from the photo sharing session. The original of the first is I'm going to go ahead and make the assumption that all our clients are going to come from a variety of different types, and the content of the assumption is mine.

The original of the second is I'm going to put a pin in that. We will come back to that if we dive into it a little bit more. For the time being, though, I want to jump into the design. The interviewer singles this out in the feedback afterwards: saying that you will come back shows you have not forgotten the point.

3. State the trade-off, commit to a decision

at the cost of appears in two sources. In the session on designing a chat service, the interviewer asks whether there is a better option and the candidate answers we can definitely suggest, but it will come at the cost of consistency, and latency. Google's guidance uses the same wording in its example:

Do you store data on a rotating disk and pay less money for the storage at the cost of increased latency?

Cambridge defines trade-off as a situation in which you balance two opposing situations or qualities, with the example There is a trade-off between doing the job accurately and doing it quickly.

The second sentence was said by the interviewer, not the candidate. After the inventory and orders session, the interviewer points out that the candidate kept saying "we could do this or this" without saying why, and then shows how to say it: okay, so I'm going to go with an event queue because I'd rather the user … always get the right information eventually.

interviewing.io's guide makes the same point. It says many candidates list a few options with their pros and cons and then move on to another component; its fix is to add one last sentence:

We could use this type of DB, or this other, or that other, and these are some pros and cons… And based on all these tradeoffs, I'll use THAT type of DB.

Google's guidance asks for the same thing: We're looking for systems designers that can consider multiple solutions, commit to one, and then iterate on it.

4. Point out the bottleneck, change your mind on the spot, check they are with you

The bottleneck sentence comes from the chat service session. The interviewer asks which component would give out first under heavier traffic, and the candidate says I would say synchronisation service, I think is the bottleneck. Google's guidance lists Is there a bottleneck in the design? among the questions to ask yourself while designing.

The sentence for changing your mind comes from the photo sharing session. The candidate had said the data would be relational and reconsiders on reaching the follower service: So it may actually make more sense now that I'm thinking about this, to throw a higher availability, higher write throughput database…. I replaced the second half with use a NoSQL database. This explanation of the database choice is exactly what the feedback afterwards praises.

The last sentence comes from the inventory and orders session, asked after the candidate has said which items to discuss first.

Can I also say it this way?

Say it again with different content

Read the Chinese, say it yourself, and then look at the reference version.

1. 預期要處理多少資料？
   • How much data do we expect to handle?
2. 留言要包含在這次的設計範圍裡嗎？
   • Do you want to handle comments in the scope of this design?
3. 我先假設有網頁和手機兩種用戶端。
   • I'm going to make the assumption that we have a web client and a mobile client.
4. 我們可以加快取，但代價是一致性。
   • We can add a cache, but it will come at the cost of consistency.
5. 我選 API 呼叫，因為系統比較簡單。
   • I'm going to go with an API call because it's a simpler system.
6. 我會說資料庫是瓶頸。
   • I would say the database is the bottleneck.

The first is quoted from the System Design Primer; the rest are source sentences with the content changed by me.

A short dialogue

This is a practice example I wrote myself. It is not a real interview and not a conversation from the source transcripts.

A: I'd like you to design a photo sharing service.

B: The first thing I want to lay out is the functional requirements. How many users are there?

A: About 500 million.

B: What is the expected read to write ratio?

A: People view far more photos than they upload.

B: I'm going to make the assumption that users are already logged in.

A: That's fine. How would you keep the feed fast?

B: We can add a cache, but it will come at the cost of consistency.

A: Would you still add it?

B: I'm going to go with the cache because I'd rather the feed load quickly.

A: Where do you expect problems as traffic grows?

B: I would say the database is the bottleneck. Do you think that makes sense?

Without looking at the English, how would you say it?

The standard for rating yourself is whether you can get the meaning across, not whether the words match exactly.

Overall

Of the twelve sentences, six are quoted from a source and six are adapted. The ones to practice first are the three opening questions about scale, and I'm going to go with … because I'd rather…. The first group is needed for every question; the second is the step all three sources stress and the one most easily skipped: after comparing, commit to a decision.

What sets this batch apart from the two earlier posts is that the evidence includes actual conversations, followed by the interviewer's feedback, so I can see which ways of speaking were counted as strengths. The limitation is in the same place: these are mock interviews, not language teaching materials, and nobody guarantees the grammar of those sentences. I only picked sentences that hold up grammatically and that are matched by the same wording or the same expectation in another source.

Updates

• 2026-10-25: Joined the unified speaking series; moved research to-dos into working notes and retained the lesson’s source and use limitations.

References

• Life at Google: Prepare for Your Google Interview: Systems Design: the expectations for a systems design interview; the question is deliberately underspecified, numeric estimates are wanted, and trade-offs must be stated and a decision made
• System Design Primer: How to approach a system design interview question: eight questions to ask at the start
• interviewing.io: System Design Interview Guide for Senior Engineers: the example sentence for committing to a decision after comparing
• interviewing.io mock interview: Photo Sharing Service: setting scope, stating an assumption, parking a detail, changing your mind on the spot
• interviewing.io mock interview: Inventory and Orders: the opening, the interviewer's demonstration of how to commit to a decision, checking agreement
• interviewing.io mock interview: Designing WhatsApp: stating a cost, pointing out the bottleneck
• Cambridge Dictionary: trade-off and bottleneck: definitions and examples of the two words