Structured System Design Interviews

Hello! Welcome to your first lesson in our system design course.

Given your background in product design, you're already skilled in one of the most critical aspects of creating successful products: understanding user needs and defining what to build. This lesson will help you translate that expertise into the world of large-scale software systems.

Today's Goal

Today, we'll focus on the very first step of any system design problem. By the end of this 60-minute lesson, you will be able to apply a structured approach to system design interview questions, including requirements gathering and scope definition.

Think of this as the digital equivalent of the discovery and specification phase in product design. Just as you wouldn't start sketching a new chair without knowing who it's for, what materials to use, and how much weight it must support, you can't design a software system without first defining its purpose, features, and constraints.

Let's begin.

---

1. Why You Need a Framework

System design questions are intentionally broad and open-ended (e.g., "Design Twitter"). Their goal isn't to see if you can produce a perfect, ready-to-code blueprint in 45 minutes. Instead, they evaluate how you approach and analyze a complex, ambiguous problem.

To see what interviewers are looking for, please watch the first short segment of this video from Exponent.

Because these problems are so open-ended and interviews can be stressful, having a structured process—a framework—is invaluable. It helps you organize your thoughts, manage your time, and ensure you don't miss critical aspects of the design.

This next video introduces a simple, effective framework.

As you saw, the framework is:

1. Understand the problem and establish design scope.
2. Propose high-level design and get buy-in.
3. Design deep dive.
4. Wrap up.

Many such frameworks exist, and they all share the same starting point. Take a look at these two diagrams which visualize slightly different, but fundamentally similar, structured approaches.

Notice how every single one starts with understanding requirements and scope. This is the foundation of your entire design, and it's what we'll master today.

---

2. The Two Types of Requirements

The first step of the framework involves asking clarifying questions to define the system's requirements. In product design, you might think of these as features and specifications. In system design, we call them functional and non-functional requirements.

To get a clear understanding of these two categories, please read the following section from an article by Designgurus.

To summarize:

• Functional Requirements define what the system does (e.g., a user can post a message, a user can upload a photo). These are the features.
• Non-Functional Requirements (NFRs) define how the system should operate (e.g., the feed must load in under 2 seconds, the service must be available 99.99% of the time). These are the qualities, constraints, and "ilities" (scalability, reliability, availability).

NFRs are what make system design challenging. Building a chat app for 10 friends is easy; building one for 10 million users is not. The functional requirements might be the same, but the non-functional requirement of scalability changes everything.

Let's Practice

Imagine you're asked to "Design a coffee shop ordering app." Based on your experience, what would be:

1. Two or three core functional requirements?
2. Two or three important non-functional requirements?

Think about it for a moment before reading my examples below.

My examples

• Functional:
  • Users can browse the menu of drinks and food.
  • Users can add items to a cart and customize them (e.g., size, milk type).
  • Users can pay for their order via credit card.
• Non-Functional:
  • Performance/Latency: The menu should load quickly, even with many images. Let's say, under 1 second.
  • Availability: The system must be online and able to take orders, especially during the morning rush hour.
  • Security: User payment information must be handled securely.

---

3. How to Gather Requirements

Now that you know what you're looking for, how do you uncover these requirements during an interview? You drive the conversation by asking targeted, clarifying questions.

The following resources will show you how.

To bring this all together into a systematic process, we'll use a guide from interviewing.io. It provides a methodical way to think through requirements, which should feel familiar to a designer's mindset.

---

4. Putting It All Together: A Walkthrough

Let's apply this structured approach to a classic problem: "Design a photo-sharing service."

Imagine I am your interviewer. Your task is to lead the requirements gathering phase.

You: "Okay, design a photo-sharing service. First, I'd like to ask some clarifying questions to understand the scope. Let's start with the functional requirements. What are the core features we should focus on?"

Interviewer (Me): "Good question. Let's say the core features are uploading photos and viewing a feed of photos from users you follow."

You: "Great. To structure this, let's identify the main 'business objects'. I see Users and Photos. The key relationships are that a User can upload a Photo, and a User can follow another User. This leads to a key access pattern: a User needs to see a feed of Photos from the users they follow. For the scope of this 45-minute interview, should we also consider features like comments, likes, or direct messaging?"

Interviewer (Me): "Let's keep it simple. Photo uploads and the main chronological feed are the 'must-haves'. We can consider likes and comments 'should-haves' to discuss if we have time, and messaging is out of scope."

(Here, you have successfully defined the functional scope and prioritized features—a key skill!)

You: "Perfect. Now, let's discuss the non-functional requirements to understand the constraints. First, scale: how many users should we design for? Are we talking thousands, or millions?"

Interviewer (Me): "Let's design for 10 million total users, with about 1 million active daily."

You: "Okay, 10 million users. What about performance? What's the latency expectation for loading the user's feed?"

Interviewer (Me): "The feed should feel fast. Let's aim for it to load in under 2 seconds for 95% of users."

You: "Understood. And what about availability? Is it critical for the service to be up 24/7, or is some downtime acceptable?"

Interviewer (Me): "It should be highly available. Users expect to be able to access their photos anytime."

(Now you have defined the key technical constraints that will drive your architectural choices later.)

You: "Okay, to summarize and confirm:

• Functional Scope: We are designing a service for users to upload photos and view a chronological feed of photos from people they follow. Likes and comments are secondary priorities, and messaging is out of scope.
• Non-Functional Scope: The system must support 10 million users, deliver the feed in under 2 seconds, and be highly available.
  Does that sound correct?"

Interviewer (Me): "Yes, that's a perfect summary. Please proceed with your high-level design."

By following this process, you have transformed a vague problem into a well-defined set of goals. You've demonstrated a methodical, collaborative approach, which is exactly what interviewers want to see.

To reinforce these concepts and learn about common pitfalls, I recommend reading the following sections from the Designgurus article.

---

Conclusion

Congratulations on completing your first lesson! Let's recap the main points.

Key Takeaways:

• Use a Framework: Always start with a structured approach to tackle ambiguous system design problems.
• Clarify First, Design Second: The most critical step is requirements gathering. Never jump straight to a solution.
• Distinguish "What" from "How": Clearly define both functional (features) and non-functional (constraints like scale, speed, reliability) requirements.
• Drive the Conversation: Ask targeted questions about users, features, scale, performance, and availability.
• Summarize and Confirm: Before designing, state your assumptions and the agreed-upon scope to ensure you and the interviewer are aligned.

This initial step is your biggest opportunity to set yourself up for success in a system design interview.

Preview of the Next Lesson:
In our next session, we'll tackle the next learning outcome: Estimate capacity requirements using back-of-the-envelope calculations for user traffic, storage, and bandwidth. We'll take the requirements we've defined (like "10 million users") and learn how to translate them into concrete numbers that will guide our design choices for servers, databases, and more.