The framework
Step 1: Gather Requirements
- Goal? organize your thoughts and focus on a set of requirements. Then you should finalize the system’s assumptions with the interviewers, so you can focus on them for the rest of the session.
(1-a) functional requirement (Timing Timing: 2 minutes)
- The questions:
1. Who is it for, and why do we need to build it?
2. To solve the problem [in question 1] What are the features we need to solve the users’ problem?- Mindset:
- You’re suggesting features to solve customer problems rather than just coming up with random features that seem related.
- After you’ve come up with a couple of features, narrow them down to just 1 or 2 and get the interviewers’ buy-in. You should ask which features the interviewer is interested in.
- Typically, the interviewer will narrow down to a selected few. Don’t be distracted!
For now, I will focus on feature #1 and expand further if needed, are you ok with that?”(1-b) non-functional requirement (Timing Timing: 3-5 minutes)
- After you agree on the features, identify areas that make your design unique and challenging.
- You should ask questions to build preliminary tuition on what could break your system and, when it does, some areas that can be compromised to scale for those bottleneck challenges.
Scalability
- How Many Active Users Are There in the System?
- How Are the Users Distributed Across the World?
- What Are Some Scenarios That Could Lead to High QPS?
- What Are Some Scenarios That Could Lead to High Storage and Bandwidth?Performance
- What is the Availability and Consistency Requirement?
- What Is the Accuracy Requirement?
- What Is the Response Time and Latency Constraint?
- What Is the Freshness Requirement?
- What Is the Durability Requirement?Step 2: Design API (Timing: 3-5 minutes)
- What you have to define is contextual to the functional requirements.
- You should do the back-of-the-envelope math after you finalize the API and schemas.
- You will need an API signature, input parameters, and output response to define an API fully.
API Signature
- Naming is probably the most important aspect to define clearly in this step.
Input Parameter
- You need to be able to justify the reason if you introduce/ignore an input parameter.
- You should try to minimize the feature clarification questions past the requirement gathering phase. If you ask functional requirement questions during design can be distracting for the interviewer and yourself.
Output Response
- The missing output makes the contract very confusing and open for interpretation.
- You shouldn’t include extraneous details irrelevant to the functional requirement or miss important responses necessary for the functional requirement.
- It is important to clearly define the user expectation for a response code you have specified.
- When you think of the output response, try to identify inefficiencies of the data structure, especially collections.
Last updated on