Senior system design interviews are exercises in navigating ambiguity. You're given a vague prompt, like "Design a photo-sharing service," and 45 minutes to create a coherent architecture. Success isn't about having a single right answer. It's about demonstrating a structured thought process that can turn a fuzzy problem into a concrete plan. The RESHADED framework provides a roadmap for this conversation, starting with the most critical phase: Requirements.

The first step, Requirements gathering, is your foundation. Getting this right transforms the interview from a test into a collaborative design session with your interviewer. This is where you establish the constraints, scope, and goals that will justify every subsequent architectural decision you make. Don't rush it; a solid 10-15 minutes spent here will save you from designing the wrong system.

The goal of the requirements phase is to get a clear, shared understanding of what you're building. This involves asking clarifying questions to define two categories of requirements: functional and non-functional. For senior engineering roles, often designated L4-L6 at large tech companies, demonstrating a deep understanding of non-functional requirements is what separates a good answer from a great one.

Functional requirements define the features. Non-functional requirements define the quality attributes and constraints. Think of them as the "-ilities": scalability, reliability, availability, and maintainability. These are what shape your architecture.

You can't build everything in 45 minutes. A key skill is to define a reasonable scope. Start by stating what core features you'll focus on and, just as importantly, what you will leave out for now. For our photo-sharing app, you might say:

This shows you can prioritize and manage complexity. Now, dig into the non-functional requirements by asking targeted questions. Don't just ask, "What's the required latency?" Frame your questions around the user experience and business goals.

• Scale: "How many daily active users should we plan for? And what's the expected read-to-write ratio? Are we talking an Instagram-scale system where users browse far more than they post?"
• Performance: "What's an acceptable load time for the feed? Should it feel instantaneous? Are we optimizing for users in a specific region, or is this a global service?"
• Availability: "How critical is it that the service is always online? Is it okay if photo uploads occasionally fail during peak load, as long as viewing photos is always fast?"

Your clarifying questions should lead you to define specific targets, often expressed as SLAs or SLOs (Service Level Agreements or Objectives). These make the requirements concrete. For example, "The system will have 99.99% availability" or "P99 latency for image loads will be under 200ms."

This is also where you must address the fundamental trade-offs in distributed systems. The most famous is the tension between consistency and availability. You should explicitly ask the interviewer which is more important for a given feature.

This question demonstrates your awareness of the CAP theorem without needing to lecture on it. For a social media feed, eventual consistency is almost always the right choice. No one's life is at risk if a photo appears a few seconds later. However, for a feature like updating a username, you'd want strong consistency to prevent conflicts.

By the end of this phase, you shouldn't have a fuzzy problem anymore. You should have a clear set of documented requirements and constraints, agreed upon with your interviewer. Now you're no longer solving a puzzle alone; you're an architect leading a design discussion.