Mekal Z

Mekal Z

A programmer running out of the wall.
twitter
HomeArchivesAbout Me灵瓜背单词📱

Structured system design interview

#system design#interview#programming106
AI-generated summary
To conduct a perfect system design interview, there are four main steps. The first step is to understand the problem and establish the design scope by asking questions and prioritizing features. The second step is to propose a high-level design and get buy-in by starting with APIs and creating a design diagram. The third step is to do a deep dive into potential problematic areas and come up with solutions while discussing trade-offs. The final step is to review the design and ensure each feature is complete end-to-end. Non-functional requirements are important in the deep dive step.

4 Main steps to make a perfect system design interview#

  • Step 1: Understand the problem and establish design scope#

    • It is our job to ask as many questions as necessary to undstand the problem fully. It is a red flag to jump right into the solution without first understanding what we are building. The goal is to understand why we are building the system, who the users are, and what features we need to build. The gold is to understand the features we are building in priority order. We should focus on the top features to build. Make sure the interviewers agrees to the feature list.
    • It is also important to ask a series of questions to clarify the non-functional requirements. For system design interviews, we'd better focusing on scale and performance. These non-functional requirements are what make our design unique and challenging. The more senior the role is, the more important it is for us to demonstrate our ability to handle the non-functional requirements.
    • image
    • To help us get a sense of the scale of the system and the potential challenges and bottlenecks, we might do some rough back-of-the-envelope calculations here. keep in mind that we have yet to design anything, so the math we do here is a rough estimate. The goal is to get a general sense of the scale. We want to get the order of magnitude right.
    • At the end of this step, we should have a short list of features to design for, along with a few important non-functional requirements to satisfy.

  • Step 2: Propose high-level design and get buy-in#

    • In this step, we aim to develop a hight-level design and reach an agreement with the interviewer on the design.
    • For most designs, it is better to have a top-down approach and start with the APIs. The api establish a contract between the end uses and the backend systems. It should be clear after gathering the requirements what APIs we would need. Unless it is specified otherwise, we should follow the RESTful convention. Define each API's input parameters and output response carefully. Take the time to carefully review the APIs. Verify that they satisfy the functional requirements. Equally important to remember, don't introduce APIs that have noting to do with the functional requirements.
    • An additional consideration on API. Some designs might call for two-way communication between client and server. In this scenario, web-socket is a common solution here. be mindful that a socket service like web-socket is usually stateful. It's quite challenging to operate at scale. If the scale is high, be prepared to discuss how we would manage a web-socket deployment in the deep dive section.
    • Once we have established the APIs between the client and the server, the next step is to lay out the high-level design diagram. The diagram is the blueprint of the overall design that we can refer back to. We should use it to verify the design satisfy all the feature requirements end-to-end. For many designs, it starts with a load balancer or an API gateway. Behind that is the services that would satisfy the feature requirements we established earlier with the interviewer.
    • Many services require some form of persistence. This is where we would round out the design by introducing the data storage layer. It is usually not necessary to specify exact database technology to use at this stage. This should be deferred to the deep dive section if necessary and only after we have designed the data schema.
    • While developing the high-level design, maintain a list of discussion points for later. Resist the temptation to dig into too much detail too early. Do not dig ourself a hole before we have a full picture of the design.
    • The last step of the high-level design is to hash out the data model and schema. Here we should discuss the data patterns and the read/write ratio. At scale, data modeling could significantly impact the performance of the design. If it is simple, also discuss the databases to choose, and maybe discuss the index options.
    • Here we should make some judgement calls. If the data modeling is the key part of the design to satisfy the non-functional requirements, we might want to defer the discussion to the deep dive section.
    • When we are done with the hight-level design, take a step back and review the design. Make sure each feature is complete end-to-end.

  • Step 3: Design deep dive#

    • The goal of this step is to demonstrate that we could identify areas that could potentially be problematic and come up with solutions and discuss trade-offs.
    • We should work with the interviewer closely to decide what to discuss in depth. Deep dive is where non-functional requirements make the problem interesting. The higher the level, the more important this section is. The section is really open ended. There is no one-size-fits-all approach. Here is where ability to read-the-room is useful. Sometimes the interviewer's body language could give away clues that they are dissatisfied with certain aspects of the design. It is important to pick up these clues and make sure the issues are all addressed. One way we could approach is by asking questions. We could list out the reasons for choosing a particular solution, and ask if they have any questions and concerns.
    • Once we pick out a problem or two to dive deeper into, we should come up with multiple solutions and discuss the trade-offs for each option. We could use the following mini guideline when framing the discussion.
      • First, we should clearly articulate the problem.
      • Next, we come up with at least two solutions.
      • Third, we discuss the trade-offs of the solutions.
      • Finally, we pick a solution and discuss it with the interviewer.
      • image

  • Step 4: Wrap up#

    • It's worth to spend a few minutes summarizing the design. Here we should focus on the parts that are unique to the particular situation. keep it short and sweet. Leave enough time at the end of the interview to ask the interviewer questions about the company.

Time allocation of a 1 hour interview#

  • First 5 minutes: introduction
  • 45 minutes: Interview process
    • 5 minutes for Step 1: Understand the problem and establish design scope
    • 20 minutes for Step 2: Propose high-level design and get buy-in
    • 15 minutes for Step 3: Design deep dive
    • 5 minutes for Step 4: Wrap up
  • Last 5 minutes: Q&A

This article is a digest notes of the Youtube video System Design Interview: A Step-By-Step Guide

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.