5 exercises — clarifying requirements, back-of-envelope estimation, trade-off vocabulary, CAP theorem language, and scaling discussions.
0 / 10 completed
1 / 10
You're asked: "Design a URL shortener like bit.ly." What is the most professional opening move?
Clarifying requirements first is the single most important move in a system design interview. It demonstrates seniority, structured thinking, and communication ability. The formula: "Before I start, let me clarify a few things." Then ask about: scale (QPS, DAU), availability requirements, latency constraints, geographic distribution, and any known edge cases. Option B jumps to a solution without understanding the problem — a common mistake. Option A shows you're moving without direction.
2 / 10
You are estimating scale. Complete the statement: "Let's _____ we have around 10 million daily active users. If each user makes _____ 3 requests per day on average, we're looking at _____ 30 million requests per day, or _____ 350 requests per second."
The hedging vocabulary for system design estimation: assume (basis for calculation), approximately / roughly (imprecise number), and about / around (order-of-magnitude estimate). These signal that you're making reasonable back-of-envelope calculations, not exact predictions. The interviewer knows you're estimating — using these words shows honesty and precision about your uncertainty. Avoid "guess" (too casual) or exact numbers without a qualifier.
3 / 10
The interviewer asks: "Would you use SQL or NoSQL for this system?" Which response demonstrates the strongest thinking?
System design answers must be trade-off driven. The phrase "It depends on…" followed by explicit criteria is a strong signal of senior engineering thinking. Structure: "If [condition A], I'd use X because [reason]. If [condition B], Y is better because [reason]. Given our requirements, I'd lean towards X." Option A reveals personal bias, not engineering judgment. Option B states an incorrect universal rule. Option D avoids the question — interviewers are probing your decision-making process.
4 / 10
You're explaining a trade-off between consistency and availability. Which vocabulary choice is most precise and professional?
A strong system design explanation: (1) names the framework (CAP theorem), (2) defines terms ("availability — meaning the system stays up"), (3) presents the trade-off symmetrically ("if we prioritise X… if we prioritise Y…"), and (4) states the outcome of each choice (stale data vs. rejected reads). Key phrases: "we accept that…", "meaning that…", "the trade-off is…". Option A is too vague for an interview. Option C is too informal.
5 / 10
You've finished your design and the interviewer asks: "What would you do differently if the read traffic increased by 100x?" Complete the best response: "Good question. I _____ add a read replica layer in front of the primary database. _____, I'd also consider introducing a caching layer — Redis, for example — _____ frequently read data. _____ would handle most read traffic and take pressure off the database."
"Would" (conditional) is the correct form when answering hypothetical scaling questions — it signals you're reasoning about a scenario, not making a firm commitment. Structure: state the primary change → use "Additionally" to layer a second improvement → explain the why → summarise the combined effect with "This combination". Good sequencing language: "First… Additionally / On top of that… This combination / Together, these changes…" signals that you have a complete plan, not individual ad hoc fixes.
6 / 10
Alice: 'Okay, so for the API endpoint, should we use REST or GraphQL?'
Choosing GraphQL over REST in this scenario demonstrates an understanding of efficient data retrieval. While REST is common, GraphQL allows developers to request specific fields, reducing network overhead and improving API performance. Simply stating 'REST is simpler' doesn't show you've considered the trade-offs.
7 / 10
You are drafting a PR description for a new feature: implementing rate limiting on an API endpoint. Which of the following best describes the core justification?
The primary purpose of rate limiting is to mitigate denial-of-service attacks and prevent resource exhaustion. While performance can be a *result* of rate limiting, framing it solely as 'performance improvement' is incomplete and potentially misleading. Focusing on protection against abuse demonstrates a deeper understanding of API design.
8 / 10
During a standup meeting, your team lead asks: 'What's the biggest challenge you're facing with scaling this system?' Which response is most effective?
Identifying data consistency as the primary challenge demonstrates a strategic understanding of system architecture and potential bottlenecks. While query optimization and caching are important, acknowledging the complexity of distributed systems and ensuring data integrity reflects a more mature technical perspective and highlights the focus on architectural concerns rather than superficial issues.
9 / 10
You're reviewing a colleague's Slack message: 'Just updating the status to indicate that we've deployed the new version.' What additional information would you request to ensure proper understanding and follow-up?
While acknowledging the update is polite, simply stating 'That's good' lacks crucial details and doesn't initiate a verification process. Requesting access to deployment logs is paramount to confirm successful execution and identify potential issues proactively, demonstrating responsibility and thoroughness.
10 / 10
The interviewer asks: 'If we experience a sudden surge in traffic to our image processing service, how would you approach scaling the architecture?' What's your initial thought?
While monitoring is important, a reactive approach isn't sufficient for handling sudden surges. Horizontal scaling with load balancers provides the necessary elasticity to handle increased demand automatically – this demonstrates a proactive understanding of distributed systems and capacity planning, crucial for robust system design.
What does "System Design Language — Interview Exercise" cover?
Practice English for system design interviews: clarifying requirements, estimating scale, explaining trade-offs, and using CAP theorem vocabulary.
How many questions are in this interview set?
This set has 10 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.