System Design Requirements Gathering
By Stefan Mai
•
Most system design interviews begin with requirements (often "Functional" and "Non-Functional") as they set the stage for the rest of your design. This is also when you first get to dig into the details of the ambiguous question ("design Uber" or "design a rate limiter") that's been given to you. Unsurprisingly, feedback about requirements gathering and prioritization is the #1 most common feedback given to mid-level mock interview participants on Hello Interview and stays in the top 3 even for Senior+ engineers. Why? Where you choose to focus your time during the interview has a disproportionate effect on whether you're able to demonstrate mastery of the basics.
Ok, simple? Not so fast. So let's dive into some common mistakes and how to fix them.
1. Failing to explore the problem
The most common mistake for candidates is failing to explore the problem. System design interviews can be nerve wracking and often the biggest fear is being stumped or getting stuck. Just like coding interviews, many candidates intrinsically want to avoid situations where they stall out and embarrass themselves (side note: don't be embarrassed) in front of the interviewer. With this worry firmly driving the interview, candidates' minds will dart immediately to the nearest possible solution and stick there - mentally moving on to other sections of the interview.
While your instincts are an important part of the assessment of a system design interview, many companies are expecting you to ask questions and go deeper. So instead of immediately jumping to "how would I build this?"", put yourself in the shoes of the user/client of the system and ask "what do I expect the system to look like?"
If you're building a piece of an app, think through what would be displayed to the user: features on the page, auxiliary flows and options, failure modes and error cases. If you're building a backend system, consider your developer clients and what sorts of capabilities they would expect of your system.
It's completely ok to mark some of these incremental requirements as "out of scope" for your interview if you don't feel like you'll be able to cover them in the 35-40 minutes that are allocated. In fact, getting to the edge of the problem where you are explicitly marking things out of scope is a good sign you've done enough ...
2. Spending too much time
While getting solid requirements will ensure you focus your efforts on the right problems during the interview, ultimately you're not being interviewed for a project manager job. Your interviewer wants to see if you can interrogate an ambiguous problem and emerge with a good idea of what to build. Two things seem to cause this.
First, some candidates, in their earnestness, attempt to encapsulate the entire problem scope within their requirements, and if not there, then in their API design and data models. This over-ambitious approach can lead to a disproportionate amount of time being spent on planning rather than on demonstrating your design and problem-solving skills.
The second factor is the fear of missing out on important details. This fear can cause candidates to over-inquire and over-analyze, leading to a rabbit hole of questions and hypothetical scenarios. While it's important to be thorough, there is a fine balance between being detailed and being bogged down in minutiae.
The key to mitigating this is to practice a structured approach to requirement gathering. Start with broad, high-level questions to understand the scope and gradually drill down into more specific details. Once you have a satisfactory understanding of the primary requirements, move on. Remember, it's better to cover more ground in your design with a good understanding of the key requirements than to get stuck in the weeds of every possible detail. Time box yourself to 5 minutes and then keep going!
3. Not distilling requirements
Another common pitfall is not distilling the gathered requirements into a clear, concise set of goals. Candidates often collect a broad range of inputs but struggle to prioritize and condense them into actionable items. This leads to an overloaded or unfocused design. To avoid this, after gathering requirements, take a moment to reflect and identify the core features that are essential for the system. Focus on these during your design phase.
All system design questions will invariably have a "crux" or a "hard part". Your interviewer is expecting you to spend a significant amount of time on these pieces. Use your time in the requirements phase to choose which parts are worthy of going deep.
If you've done your job right, your functional requirements will map pretty closely to a checklist for your overall system design which you can work from top to bottom. While not all problems break down this way, many do.
4. Insufficiently covering non-functional requirements
The next thing candidates struggle with is non-functional requirements, which are frequently overlooked or underemphasized as candidates tend to concentrate on functional aspects. Remember, non-functional requirements often dictate the architecture and are crucial for a successful system. Ensure you discuss and incorporate these aspects into your design, demonstrating a well-rounded understanding of the system's needs.
While many candidates think to cover availability and consistency in their non-functional requirements, a common mistake is to be overbroad ("the system should be highly available!" or "the system should be highly consistent!") when the reality is that availability and consistency usually imply tradeoffs which can be made differently for different parts of the system. "Ordering needs to be consistent to avoid double orders", "Search can be eventually consistent within 30s".
Generalizations like "the system should be secure" are ok to indicate that you're thinking about these considerations, but good non-functional requirements are usually very specific to the problem. Don't be afraid to be precise, potentially with actual numbers. Knowing that the query API needs to return in 100ms eliminates an entire class of potential solutions in the high level design (good!) while "should be fast" doesn't tell you much.
5. Ignoring scale
Finally, a mistake that can derail even a well-thought-out design is not considering the scale at which the system will operate. This includes understanding the load the system will face, data volume, and user concurrency. It's crucial to ask and clarify these aspects early on. Designing without scale in mind can lead to solutions that are not viable in a real-world scenario. You'll need to always consider scalability in your design and to do this effectively you need to have some rough sense of the access patterns of the system and the scale it needs to support.
While it's great to simply propose a scale you think might be appropriate, don't be afraid to ask your interviewer for high-level numbers like "how many users does the system need to support?" On the other hand, don't expect them to readily tell you things like "how many read requests do I need to support per second?" - these type of questions depend significantly on your choice of design and can be intelligently inferred from the high-level metrics.
What to do
In system design interviews, success hinges on a well-balanced approach to requirement gathering and design execution. Here are key strategies to optimize your performance:
- Clarify the Problem First: Start by fully understanding the problem. Ask clarifying questions and consider different user perspectives. Avoid jumping to solutions too quickly. Time Management: Allocate your time wisely. Spend enough time on requirements to understand the problem, but not so much that you're left with insufficient time for the actual system design. A good rule of thumb is to spend about 5-7 minutes on requirements and the rest on designing and discussing your solution.
- Prioritize Requirements: Once you have a broad understanding, prioritize the requirements. Focus on what is critical for the system and what can be considered as enhancements or future work. This will help you in creating a focused and feasible design.
- Balance Functional and Non-Functional Requirements: Pay equal attention to both functional and non-functional requirements. While functional requirements define what the system should do, non-functional requirements like performance and scalability dictate how the system should operate.
- Think Scalability: Always design with scalability in mind. Make assumptions about scale based on the problem, but also be ready to adjust your design based on the interviewer's input. This demonstrates flexibility and a deep understanding of how systems need to evolve over time.
- Validate with the Interviewer: Throughout the interview, but especially during requirements gathering, validate your assumptions and decisions with the interviewer. This not only shows that you are collaborative but also helps in catching any misunderstandings early on.
- Practice, Practice, Practice: Finally, the best way to get better at system design interviews is through practice. Mock interviews, studying existing systems, and reading about different architectures can greatly improve your skills.
Remember, system design is as much about your thought process and decision-making as it is about the final design. Demonstrating a clear, structured approach and effective communication skills can set you apart, even if your design isn't perfect.
Mark as read
About The Author
Stefan is one of the co-founders of HelloInterview, a platform to help software engineers and other tech professionals to prepare for their dream roles. He's conducted 1,000+ interviews and hired dozens of individuals at big companies and small startups.
Recommended Reading
Hello Interview Premium
Reading Progress
On This Page
Your account is free and you can post anonymously if you choose.