guides(sd): add system design guide
This commit is contained in:
Yangshun
parent
ebd3862d1b
commit
41e4d2e799
|
|
@ -0,0 +1,31 @@
|
|||
---
|
||||
title: Front End System Design Cheatsheet
|
||||
description: Summary of the important things you need to take note of during front end system design interviews.
|
||||
seo_title: Cheatsheet for Front End System Design Interviews
|
||||
---
|
||||
|
||||
## RADIO Framework
|
||||
|
||||
1. **Requirements Exploration**: Understand the problem thoroughly and determine the scope by asking a number of clarifying questions.
|
||||
1. **Architecture/High-level Design**: Identify the key components of the product and how they are related to each other.
|
||||
1. **Data Model**: Describe the various data entities, the fields they contain and which component(s) they belong to.
|
||||
1. **Interface Definition (API)**: Define the interface (API) between components in the product, functionality of each APIs, their parameters and responses.
|
||||
1. **Optimizations and Deep Dive**: Discuss about possible optimization opportunities and specific areas of interest when building the product.
|
||||
|
||||
## Evaluation Axes
|
||||
|
||||
1. **Problem Exploration**: Demonstrated understanding of the problem, asked clarifying questions to reduce ambiguities and gathered sufficient requirements.
|
||||
1. **Architecture**: Broke down the problem into smaller independent parts, defined their responsibilities and how these components can work together.
|
||||
1. **Technical Proficiency**: Demonstrated technical knowledge and proficiency of front end domain fundamentals (e.g. performance, networking, accessibility, i18n, security, etc), relevant technologies and APIs.
|
||||
1. **Exploration and Tradeoffs**: Suggested various possible approaches on how to achieve certain functionality, explained the pros and cons and made recommendations.
|
||||
1. **Product and UX Sense**: Showed consideration for user experience and decisions to make the product a great one.
|
||||
1. **Communication and Collaboration**: Conveyed thoughts and ideas clearly and concisely, receptive to feedback and collaborated with the interviewer.
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
- Jumping into answering the question immediately without first asking questions and gathering requirements.
|
||||
- Approaching the question in an unstructured manner, going all over the place and missing out on important areas.
|
||||
- Insisting on only one solution or the best solution without realizing that each solution has tradeoffs.
|
||||
- Remaining silent the entire time and only thinking in their head.
|
||||
- Going down a rabbit hole and spending too much time on unimportant areas.
|
||||
- Using buzzwords without being able to explain them.
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
---
|
||||
title: Common Mistakes Made During Front End System Design Interviews
|
||||
seo_title: Common Pitfalls To Avoid in Front End System Design Interviews
|
||||
description: 6 common mistakes you should avoid during front end system design interviews.
|
||||
seo_description: Avoid this list of common mistakes made by candidates when they are answering system design interview questions.
|
||||
---
|
||||
|
||||
Unlike coding interviews which are much more common and you can somewhat practice/simulate interview conditions, it is much harder to practice for system design interviews.
|
||||
|
||||
Here's a list of common mistakes made by candidates when they are answering system design interview questions and many of them are not specific to front end system design interviews. Hopefully you will remember these points and avoid them for your own interviews.
|
||||
|
||||
## Jumping into answering the question immediately
|
||||
|
||||
Don't jump into answering the question immediately! Take the time to gather requirements and clarify assumptions by asking questions. Answering the wrong question well is worse than answering the right question poorly.
|
||||
|
||||
## Approaching the question in an unstructured manner
|
||||
|
||||
Because system design interviews are very open-ended with no explicit completion milestone (unlike coding interviews where you have to produce working code), some candidates might just talk about whatever that comes to their mind and the answer might end up appearing messy to the interviewer. Use the RADIO framework to help you.
|
||||
|
||||
Write down each step of the RADIO framework on the whiteboard at the start of the interview and ensure that by the end of the interview you have covered each section sufficiently. Note that you don't necessarily have to complete each section in order and you can always revisit previous sections if you've missed out on certain things.
|
||||
|
||||
## Insisting on only one solution or the best solution
|
||||
|
||||
Don't insist there's only one solution, especially if the interviewer prompts you for alternative approaches. More often than not, there are multiple ways to solve a problem, each with its own tradeoffs.
|
||||
|
||||
The interviewer wants to see you identify a solution with the right tradeoffs for the issue at hand, not you saying that there's only one right or best solution. The other solutions might be clearly bad and is very obvious to you, but the interviewer needs to hear you explain why they are bad.
|
||||
|
||||
## Remaining silent the entire time
|
||||
|
||||
On the opposite of the spectrum of answering too quickly, we have people who remain silent. Don't remain silent the entire time and thinking only in your head. Think out loud! System design interviews are meant to be collaborative exercises between you and the interviewer. Treat your interviewer as a coworker, bring up issues you've identified, bounce ideas, and discuss possible solutions with them.
|
||||
|
||||
## Going down a rabbit hole
|
||||
|
||||
Don't go down a rabbit hole of diving too deep into a particular component. Come up with the architecture/high-level design first, then proceed to the various parts of the system. Focus on the parts which are most important to the problem.
|
||||
|
||||
If you are unsure, ask the interviewer if you should dive deeper into a specific component. It'd be bad to spend too much time discussing about an unimportant component, wasting precious time without providing useful signal to the interviewer.
|
||||
|
||||
## Using buzzwords without being able to explain them
|
||||
|
||||
Don't use buzzwords or terms you can't explain well. It might be tempting to throw out some cool terms like "Virtual DOM", "DOM Reconciliation", "Partial Hydration", "Streaming Server-side Rendering" and you can if they're relevant to the current topic!
|
||||
|
||||
However, if you do, make sure you are able to explain the term you just used as your interviewer is likely going to probe for more information to test your knowledge. It's a red flag if you are unable to explain the term you just used.
|
||||
|
|
@ -0,0 +1,104 @@
|
|||
---
|
||||
title: Front End System Design Interview Evaluation Axes
|
||||
description: Specific behaviors and signals interviewers look out for in front end system design interviews.
|
||||
seo_title: Evaluation Axes for Front End System Design from Ex-interviewers
|
||||
seo_description: Find out how interviewers at Google, Amazon, Meta, Microsoft and other tech companies evaluate you for front end system design interviews
|
||||
---
|
||||
|
||||
During interviews, interviewers look out for signals displayed by candidates before making an overall hiring and leveling recommendation. The more desired behaviors the candidate displays, the higher the likelihood the interviewer will recommend a "Hire" decision. The more detailed and mature the answers are, the higher the leveling recommendation.
|
||||
|
||||
This section lists some of the behaviors that candidates should display. Bear them in mind as you are answering the system design question and demonstrate them confidently during the interview.
|
||||
|
||||
## Problem Exploration
|
||||
|
||||
- Demonstrated thorough understanding of the problem.
|
||||
- Explored the requirements sufficiently by asking relevant clarifying questions to minimize ambiguities.
|
||||
- Gathered functional and non-functional requirements of the problem.
|
||||
- Defined the scope of the problem.
|
||||
- Identified the important aspects of the problem to focus on and address.
|
||||
|
||||
<div className="mt-6 space-x-1 space-y-1 text-xs">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Requirements Exploration
|
||||
</div>
|
||||
|
||||
## Architecture
|
||||
|
||||
- Developed an architecture that solved the entire problem sufficiently.
|
||||
- Broke down the problem into smaller independent parts of suitable granularity.
|
||||
- Identified components of the system and defined their responsibilities clearly.
|
||||
- Articulated how these components will work together and defined/described the API between these components.
|
||||
- Developed an architecture that can be put into practice.
|
||||
- Developed an architecture with scalability and reusability in mind, one that can be extended to support future requirements.
|
||||
|
||||
<div className="mt-6 space-x-1 space-y-1 text-xs">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Architecture/High-level Design, Data Model, Interface Definition
|
||||
</div>
|
||||
|
||||
## Technical Proficiency
|
||||
|
||||
- Demonstrated technical knowledge and proficiency of front end fundamentals, common technologies and APIs.
|
||||
- Able to dive into specific front end domain areas where relevant to the problem.
|
||||
- Identified areas which need to be paid special attention to and addressed them by proposing solutions and analyzing their tradeoffs.
|
||||
|
||||
_Front end domain areas include Performance, Networking, HTML/CSS, Accessibility, Internationalization, Security, Scalability, etc._
|
||||
|
||||
<div className="mt-6 space-x-1 space-y-1 text-xs">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Architecture/High-level Design, Optimizations and Deep Dive
|
||||
</div>
|
||||
|
||||
## Exploration and Tradeoffs
|
||||
|
||||
- Offered various possible solutions to the problems at hand and explained the pros and cons of each solution.
|
||||
- The "problem" here doesn't necessarily refer to the given system design question.
|
||||
- While solving the given question, there would be smaller problems to solve/questions to answer and each small problem/question can have various solutions and choices to make.
|
||||
- Explained the suitability of the solutions given the context and requirements and provided recommendations for the context of the question.
|
||||
- Do not insist there is only one possible solution. Good questions usually have a few possible solutions where the suitability of each depends on the context.
|
||||
- Even if the other solutions are clearly and obviously bad, do still mention them and briefly explain why they are bad.
|
||||
|
||||
<div className="mt-6 space-x-1 space-y-1 text-xs">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Requirements Exploration, Data Model, Interface Definition, Optimizations and Deep
|
||||
Dive
|
||||
</div>
|
||||
|
||||
## Product and UX Sense
|
||||
|
||||
Relevant framework sections: **Optimizations and Deep Dive**
|
||||
|
||||
- Proposed a robust solution that lays the foundation of a good product.
|
||||
- Considered user experience when answering: loading states, performance (perceived or actual), mobile friendliness, keyboard friendliness, etc.
|
||||
- Considered error cases and suggested ways to handle them.
|
||||
|
||||
<div className="mt-6 space-x-1 space-y-1 text-xs">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Optimizations and Deep Dive
|
||||
</div>
|
||||
|
||||
## Communication and Collaboration
|
||||
|
||||
- Conveyed their thoughts and ideas clearly and concisely.
|
||||
- Explained complex concepts with ease.
|
||||
- Engaged the interviewer during the session, asks good questions and seeks opinions where relevant.
|
||||
- Open to feedback from the interviewer and incorporates the feedback to refine their solutions.
|
||||
|
||||
<div className="mt-6 space-x-1 space-y-1 text-xs">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Architecture/High-level Design, Data Model, Interface Definition, Optimizations
|
||||
and Deep Dive
|
||||
</div>
|
||||
|
||||
## Summary
|
||||
|
||||
Here's a table summarizing how the evaluation axes can be mapped to the various sections of the **RADIO framework**: Requirements Exploration, Architecture/High-level Design, Data Model, Interface Definition, Optimizations and Deep Dive.
|
||||
|
||||
| Axis | R | A | D | I | O |
|
||||
| ------------------------------- | :-: | :-: | :-: | :-: | :-: |
|
||||
| Problem Exploration | ✅ | - | - | - | - |
|
||||
| Architecture | - | ✅ | ✅ | ✅ | - |
|
||||
| Technical Proficiency | - | ✅ | - | - | ✅ |
|
||||
| Exploration and Tradeoffs | - | ✅ | ✅ | ✅ | ✅ |
|
||||
| Product and UX Sense | - | - | - | - | ✅ |
|
||||
| Communication and Collaboration | ✅ | ✅ | ✅ | ✅ | ✅ |
|
||||
|
|
@ -0,0 +1,264 @@
|
|||
---
|
||||
title: The RADIO Framework
|
||||
description: Approach your front end system design interviews in a structured fashion. A good structure is half the battle won.
|
||||
seo_title: RADIO Framework for System Design | Apply to Any Front End System Design Interview
|
||||
seo_description: Apply the RADIO Framework to Front End System Design Interviews to guide yourself in a structured manner. A good structure is half the battle won.
|
||||
---
|
||||
|
||||
A good beginning is half the battle won. By using the **RADIO framework** to answer front end system design questions, you will already be much closer to acing your interview.
|
||||
|
||||
In the context of front end system design interviews, the systems you are asked to design tend to be products, so we'll refer to the system as "product" from here on. Start by understanding the **R**equirements, defining the high level **A**rchitecture and the **D**ata Model. Then define the **I**nterfaces between the components in the product and talk about any **O**ptimizations or dive deep into specific areas which require special attention.
|
||||
|
||||
## What is RADIO about?
|
||||
|
||||
1. **Requirements Exploration**: Understand the problem thoroughly and determine the scope by asking a number of clarifying questions.
|
||||
1. **Architecture/High-level Design**: Identify the key components of the product and how they are related to each other.
|
||||
1. **Data Model**: Describe the various data entities, the fields they contain and which component(s) they belong to.
|
||||
1. **Interface Definition (API)**: Define the interface (API) between components in the product, functionality of each API, their parameters and responses.
|
||||
1. **Optimizations and Deep Dive**: Discuss about possible optimization opportunities and specific areas of interest when building the product.
|
||||
|
||||
## Requirements Exploration
|
||||
|
||||
**Objective**: Understand the problem thoroughly and determine the scope by asking a number of clarifying questions.
|
||||
|
||||
**Recommended Duration**: Not more than 15% of the session.
|
||||
|
||||
System design interview questions are open-ended in nature and are usually vague and under-specified on purpose. **You are required to dig deeper and clarify ambiguities in the problem by asking useful questions.** Treat your interviewer as a product manager you are working with on a new project, ask enough questions so that you know what problems you are trying to solve and what you need to build. In reality, some problems can be solved without any engineering at all!
|
||||
|
||||
No two system design interview experiences are the same even though you can be asked the same question. Interviewers have different backgrounds and might prioritize different aspects of the system. Take this chance to find out what they are most interested in and plan your answers accordingly.
|
||||
|
||||
Some general questions you should get answers to before moving on to the next part of the interview:
|
||||
|
||||
### What are the main use cases we should be focusing on?
|
||||
|
||||
Imagine you were asked to "Design Facebook". Facebook is a huge platform, there's news feed, profiles, friends, groups, stories, and more. Which parts of Facebook should you focus on? The interviewer has the answer in mind but wants you to find out by asking questions. Typically you should focus on the most unique aspects of the product, the features which define it. For Facebook, it would be the news feed, pagination of the feed, and creating new posts. For YouTube, it would be the video-watching experience. The important areas for other type of products be found in the [types of questions](/system-design/types-of-questions).
|
||||
|
||||
For the rest of this page, we'll be using "Design Facebook" as the problem and apply the framework to it.
|
||||
|
||||
Let's assume you didn't clarify which parts of the product to focus on, assumed you should talk about the befriending flow and started talking about it. In the best case, good interviewers will steer you back in the direction the question was meant to proceed, but they will make a mental note that you didn't clarify the question. In the worst case, inexperienced interviewers will let you keep talking and politely try to find an opportunity to correct you, but you would have already wasted some precious minutes discussing an unimportant topic.
|
||||
|
||||
### What are the functional requirements and non-functional requirements?
|
||||
|
||||
Firstly, what are functional and non-functional requirements?
|
||||
|
||||
- **Functional requirements**: Basic requirements of the product such that the product cannot function without them. This is usually whether a user can complete the core flows correctly.
|
||||
- **Non-functional requirements**: Requirements that are viewed as improvements to the product, but not strictly required for the product to be usable, i.e. the product can still be used without these. These include performance (how fast the page loads, how fast the interaction takes), scalability (how many items can be present on the page), good user experience, etc.
|
||||
|
||||
There are two ways you can get the answer to this question:
|
||||
|
||||
1. Take the initiative to list out what you think are the requirements and get feedback and alignment from the interviewer (Preferred).
|
||||
1. Ask the interviewer directly. However, most of the time they'd want you to define them. Even if they give you an answer, it won't be too detailed.
|
||||
|
||||
At the very minimum, your design has to meet the functional requirements. After meeting all the function requirements, move on to talk about how to fulfill the non-functional requirements.
|
||||
|
||||
### What are the core features to focus on and which are good-to-have?
|
||||
|
||||
Even after you know the functional requirements, there can still be a ton of small features that make up the large feature. For example, when creating new Facebook posts, what kind of post formats should be supported? Besides the usual text-based posts, should the user be able to upload photos, upload videos, create polls, check in to a location, etc.
|
||||
|
||||
You should clarify the core features beforehand and design for them before moving on to the extra features.
|
||||
|
||||
### Other questions:
|
||||
|
||||
- What devices/platforms (desktop/tablet/mobile) need to be supported?
|
||||
- Is offline support necessary?
|
||||
- Who are the main users of the product?
|
||||
- What are the performance requirements, if any? (Performance requirements typically fall under non-functional requirements.)
|
||||
|
||||
The list above should give you a good starting list of questions but it is not an exhaustive list! Different problems will require you to ask domain-specific questions, which we will talk about in the case studies.
|
||||
|
||||
You are recommended to write down the agreed requirements somewhere so that you can refer to them throughout the interview and ensure that you've covered them.
|
||||
|
||||
---
|
||||
|
||||
## Architecture/High-level Design
|
||||
|
||||
**Objective**: Identify the key components of the product and how they are related to each other.
|
||||
|
||||
**Recommended Duration**: Roughly 20% of the session.
|
||||
|
||||
With the requirements in mind, we can move on to the architecture design proper. Your next task is to come up with a product/system architecture by identifying the key components of the product, how the components interact with each other, and how they are related. Remember to focus on the **client-side architecture**, not the back end.
|
||||
|
||||
Diagrams are your friends here. Each component can be represented using a rectangle and your high-level design usually ends up looking like a few rectangular boxes with arrows between them to demonstrate the flow of data. It is also possible to have components within components, in that case, draw the parent using bigger rectangles since they need to fit multiple subcomponents.
|
||||
|
||||
Examples of components/modules which are commonly found in a high-level front end design:
|
||||
|
||||
- **Server**: In front end system design interviews, we can treat the server as a black box and assume it exposes some APIs you can call via HTTP/WebSockets.
|
||||
- **View**: This represents what the user sees, and it usually contains smaller subviews within it. Can contain client-side only state.
|
||||
- **Controller**: The module which responds to user interactions and processes the data from the store/model in a format the view expects. This module is not always needed if the application is small and there's not much passing of data between modules.
|
||||
- **Model/Client Store**: Where the data lives. Stores contain data which will be presented to the user via views and stores tend to be app-wide for an interview context. In reality, you can have multiple stores within an application and stores can contain other stores.
|
||||
|
||||
Other things to consider when defining the responsibilities of components:
|
||||
|
||||
- **Separation of concerns**: Components are meant to be modular and serve to encapsulate a set of functionality and data. Consider the purpose/functionality of each component, what data it should contain and how it can service the rest of the system (what it can do for the other components).
|
||||
- **Where computation should occur**: If some amount of computation is needed (e.g. filtering of results given a search term, calculating the total amount for a cart), should the work be done on the server or the client? There are tradeoffs to each approach and the decision is both question-dependent and context-dependent.
|
||||
|
||||
It is important to realize that not every common component mentioned above will be relevant and needed for every question, it depends on the product.
|
||||
|
||||
After drawing out the architecture diagram, verbally describe the responsibilities of each component (box in the diagram).
|
||||
|
||||
### Architecture Example
|
||||
|
||||
Here's an example architecture diagram for the [News Feed](/questions/system-design/news-feed-facebook) question drawn using Excalidraw.
|
||||
|
||||
|
||||
|
||||
#### Component Responsibilities
|
||||
|
||||
- **Server**: Serves feed data and provides a HTTP API for new feed posts to be created.
|
||||
- **Controller**: Controls the flow of data within the application and makes network requests to the server.
|
||||
- **Client Store**: Stores data needed across the whole application. In the context of a news feed, most of the data in the store will be server-originated data needed by the feed UI.
|
||||
- **Feed UI**: Contains a list of feed posts and the UI for composing new posts.
|
||||
- **Feed Post**: Presents the data for a feed post and contains buttons to interact with the post (like/react/share/comment).
|
||||
- **Post Composer**: UI for users to create new feed posts.
|
||||
|
||||
Common free drawing tools that you might be asked to use include [diagrams.net](https://app.diagrams.net/) and [Excalidraw](https://excalidraw.com/). It'd be a good idea to familiarize yourself with these tools beforehand.
|
||||
|
||||
---
|
||||
|
||||
## Data Model
|
||||
|
||||
**Objective**: Describe the various data entities, the fields they contain and which component(s) they belong to.
|
||||
|
||||
**Recommended Duration**: Roughly 10% of the session.
|
||||
|
||||
We now have to think about what data fields are present in the client. There are two kinds of data on client applications:
|
||||
|
||||
### Server-originated Data
|
||||
|
||||
Data that originates from the server, usually from a database and meant to be seen by multiple people or accessed from multiple different devices. Common examples include user data (name, profile picture) and user-generated data (feed posts, comments).
|
||||
|
||||
### Client-only Data
|
||||
|
||||
Client-only data, also commonly known as state, is data that only needs to live on the client and does not have to be sent to the server for writing into the database. Client data can be further broken down into two:
|
||||
|
||||
- **Data to be persisted**: Usually user input such as data entered into form fields. These data usually has to be sent to the server and saved into a database for it to be useful.
|
||||
- **Ephemeral data**: Temporary state that lasts for a short time. Common examples include form validation state, the current tab, whether a section is expanded, etc. It's usually acceptable to lose these data when the browser tab is closed.
|
||||
|
||||
When listing the data fields, it'd be useful to identify what kind of data that field is, whether it's server-originated data or client-only data.
|
||||
|
||||
### Data Model Example
|
||||
|
||||
Here's a basic example of data model for the various entities using the [News Feed](/questions/system-design/news-feed-facebook) question.
|
||||
|
||||
| Source | Entity | Belongs To | Fields |
|
||||
| --- | --- | --- | --- |
|
||||
| Server | `Post` | Feed Post | `id`, `created_time`, `content`, `image`, `author` (a `User`), `reactions` |
|
||||
| Server | `Feed` | Feed UI | `posts` (list of `Post`s), `pagination` (pagination metadata) |
|
||||
| Server | `User` | Client Store | `id`, `name`, `profile_photo_url` |
|
||||
| User input (client) | `NewPost` | Feed Composer UI | `message`, `image` |
|
||||
|
||||
Depending on how far you progress along in the question and how the requirements have evolved and grown during the interview, you might need to add more fields. It's a dynamic and iterative process.
|
||||
|
||||
You might want to write these fields near the components which owns them in your architecture diagram.
|
||||
|
||||
---
|
||||
|
||||
## Interface Definition (API)
|
||||
|
||||
**Objective**: Define the interface between components in the product, functionality of the various APIs, their parameters and responses.
|
||||
|
||||
**Recommended Duration**: Roughly 15% of the session.
|
||||
|
||||
With the components and data within each components, we can move on to discuss the interface (APIs) between the components. API is an overloaded term and generally refer to the protocol which software components communicate and request/send data between components. Client and server communicate via network layer APIs (HTTP/WebSockets). Client components generally communicate via functions in the browser runtime. All APIs have three things in common whether they are between the server and the client or between client components:
|
||||
|
||||
| Parts of an API | Server-Client | Client-Client |
|
||||
| --- | --- | --- |
|
||||
| Name and functionality | HTTP path | JavaScript function |
|
||||
| Parameters | HTTP GET query and POST parameters | Function parameters |
|
||||
| Return Value | HTTP response, typically JSON format | Function return value |
|
||||
|
||||
### Server-Client API Example
|
||||
|
||||
Using the [News Feed](/questions/system-design/news-feed-facebook) example yet again, we have a server API that allows the client to fetch the latest feed posts.
|
||||
|
||||
| Field | Value |
|
||||
| ----------- | ------------------------------------ |
|
||||
| HTTP Method | `GET` |
|
||||
| Path | `/feed` |
|
||||
| Description | Fetches the feed results for a user. |
|
||||
|
||||
#### Parameters
|
||||
|
||||
A feed response is a paginated list so the API expects pagination parameters.
|
||||
|
||||
```json
|
||||
{
|
||||
"size": 10,
|
||||
"cursor": "=dXNlcjpXMDdRQ1JQQTQ"
|
||||
}
|
||||
```
|
||||
|
||||
#### Response
|
||||
|
||||
```json
|
||||
{
|
||||
"pagination": {
|
||||
"size": 10,
|
||||
"next_cursor": "=dXNlcjpVMEc5V0ZYTlo"
|
||||
},
|
||||
"results": [
|
||||
{
|
||||
"id": "123",
|
||||
"author": {
|
||||
"id": "456",
|
||||
"name": "John Doe"
|
||||
},
|
||||
"content": "Hello world",
|
||||
"image": "https://www.example.com/feed-images.jpg",
|
||||
"reactions": {
|
||||
"likes": 20,
|
||||
"haha": 15
|
||||
},
|
||||
"created_time": 1620639583
|
||||
}
|
||||
// ... More posts.
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Client-Client API Example
|
||||
|
||||
The client-client API can be written in a similar fashion as the server-client API, main difference being they are JavaScript functions, or events that are being listened to. The most important parts to describe are the functionality of the API, the parameters and the return/response value.
|
||||
|
||||
### API for UI Component System Design
|
||||
|
||||
If you're asked to design a UI component, for the "Interface" section, discuss about the customization options for the component, similar to the props for React components.
|
||||
|
||||
---
|
||||
|
||||
## Optimizations and Deep Dive
|
||||
|
||||
**Objective**: Discuss about possible optimization opportunities and specific areas of interest when building the product.
|
||||
|
||||
**Recommended Duration**: Roughly 40% of the session.
|
||||
|
||||
There's no fixed way to go about the optimization and deep dive section and you are free to focus on different areas of the product. There will not be sufficient time to cover every area, so select how you want to spend your time carefully according to these guidelines:
|
||||
|
||||
- **Focus on the important areas of the product.** For e-commerce websites, performance is crucial and you'd want to spend the bulk of your time diving into the various performance optimizations that can be done. For collaborative editors, the complexity is in how to handle race conditions and concurrent modifications, so you'd want to focus on explaining that.
|
||||
- **Focus on your strengths.** Showcase your domain knowledge. If you are well-versed in accessibility, talk about the various accessibility pitfalls that can occur in the product and how to address them. Impress the interviewer with your knowledge. If you are a performance guru, explain the various performance optimization opportunities that can provide a buttery smooth user experience.
|
||||
|
||||
### General Optimization/Deep Dive Areas
|
||||
|
||||
Here's a list of topics you can talk about for this section. Bear in mind that the importance of a topic depends on the question and some topics are entirely irrelevant to certain questions (possible but unlikely).
|
||||
|
||||
- Performance
|
||||
- User Experience
|
||||
- Network
|
||||
- Accessibility (a11y)
|
||||
- Multilingual Support
|
||||
- Multi-device Support
|
||||
- Security
|
||||
|
||||
Refer to our [Best Practices for Building User Interfaces Guide](/front-end-interview-guidebook/user-interface-best-practices) for details on each topic.
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
| Step | Objective | Recommended Duration |
|
||||
| --- | --- | --- |
|
||||
| Requirements Exploration | Understand the problem thoroughly and determine the scope by asking a number of clarifying questions. | <15% |
|
||||
| Architecture/High-level Design | Identify the key components of the product and how they are related to each other. | ~20% |
|
||||
| Data Model | Describe the various data entities, the fields they contain and which component(s) they belong to. | ~10% |
|
||||
| Interface Definition | Define the interface (API) between components in the product, functionality of each APIs, their parameters and responses. | ~15% |
|
||||
| Optimizations and Deep Dive | Discuss about possible optimization opportunities and specific areas of interest when building the product. | ~40% |
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
---
|
||||
title: Introduction to Front End System Design
|
||||
description: Learn useful techniques and how to approach the top front end system design questions, written by ex-interviewers at FAANG.
|
||||
seo_title: Front End System Design Guide | Concepts, Techniques and Questions
|
||||
---
|
||||
|
||||
Unlike coding and quiz questions, system design interviews are open-ended style interviews where there are no right answers. You're given a vague problem or scenario and you're expected to work with the interviewer to answer the question by coming up with a suitable software design on a whiteboard, or some collaborative drawing app if it's a virtual interview. It is similar to the process at certain companies where engineers write technical design documents to outline the possible approaches to a project they are working on, explain technical decisions and discuss tradeoffs with coworkers except that you have to do it within 30-60 minutes.
|
||||
|
||||
System design interviews are usually given to candidates who have some number of years of working experience (aka non-fresh grads) and your performance in the system design interview has significant influence on the job level you will be offered. Most of the time, failing the system design interview will result in an overall rejection. It's really important to ace your system design interviews!
|
||||
|
||||
However, given the open-ended nature of system design interviews, it is much harder to practice for it as compared to coding interviews. Many candidates also don't have real life experience building various systems and it's hard to draw from experience when answering system design interview questions. Also, there are very few resources available for front end system design. Most existing system design resources are targeted at general Software Engineers and hence focus on distributed systems.
|
||||
|
||||
GreatFrontEnd's system design resources are perhaps the most comprehensive you can find and will help you handle front end system design interviews with ease!
|
||||
|
||||
## Front End vs Back End System Design
|
||||
|
||||
In traditional Software Engineer system design interviews, candidates will be asked to describe the architecture of a distributed system, usually involving web servers, load balancers, caches, databases, microservices, task queues, etc. For Front End Engineers, system design interviews are slightly different, there's more emphasis on what goes on in the client and API design between the client and the server, as opposed to what goes on in the back end.
|
||||
|
||||
| Aspect | Back End | Front End |
|
||||
| --- | --- | --- |
|
||||
| Gather requirements | Required | Required |
|
||||
| Architecture/High-level design | Distributed cloud services | Application/Component |
|
||||
| Back-of-the-envelope estimation | Required | Not required |
|
||||
| Components of the system | Cloud services (e.g. Load balancer, Application server, Database, File storage, Caches, Message queues, CDN) | Application modules (Model, View, Controller) |
|
||||
| Data Model | SQL Schema | Application state |
|
||||
| Type of APIs between components | Network (Any protocol) | Network (HTTP, WebSocket), JavaScript functions |
|
||||
| Focus areas | Scalability, Reliability, Availability | Performance, User Experience, Accessibility, Internationalization |
|
||||
| Less important (Can treat as a black box) | Client | Server |
|
||||
|
||||
_Read more on the differences between Front End and Back End System Design Interviews on [Zhenghao's blog](https://www.zhenghao.io/posts/system-design-interviews)._
|
||||
|
||||
For example, a classic question is to ask about designing a Twitter feed UI which can be asked during both back end and front end system interviews.
|
||||
|
||||
- **Back end**: Capacity estimation, designing the database schemas, how to ensure the services can scale with the traffic, how to generate a user's Twitter feed?
|
||||
- **Front end**: How do you implement the interactions with a tweet, how to implement pagination in the feed, and how users can create new tweets?
|
||||
|
||||
As you can see, the focus of front end system design interviews can be very different from back end and answering them well requires a different approach.
|
||||
|
||||
## What you will learn in this guide
|
||||
|
||||
Our Front End System Design guide is structured into two parts, you will first gain a deeper understanding system design interviews are about, then dive into some front end system design case studies using the RADIO framework.
|
||||
|
||||
- [Types of Front End System Design questions and examples](/system-design/types-of-questions)
|
||||
- [Framework for answering Front End System Design questions](/system-design/framework)
|
||||
- [How you are being evaluated and what interviewers are looking out for](/system-design/evaluation-axes)
|
||||
- [Common mistakes to avoid](/system-design/common-mistakes)
|
||||
|
|
@ -0,0 +1,84 @@
|
|||
---
|
||||
title: Types of Front End System Design Questions
|
||||
description: Question formats you can expect in a front end system design interview.
|
||||
seo_title: Types of Questions in Front End System Design Interviews
|
||||
seo_description: Learn the two types of front end system design questions and how to tackle them differently.
|
||||
---
|
||||
|
||||
There are two main kinds of front end system design questions: (1) Applications and (2) UI components.
|
||||
|
||||
## Applications
|
||||
|
||||
As mentioned above, designing applications for front end system design interviews will feel similar to general Software Engineering system design interviews, and in fact, the questions are highly similar. However, instead of talking about distributed systems, you should focus on the client side of things and talk about application architecture and client-side implementation details.
|
||||
|
||||
In this day and age, many websites are interactive and rich applications that can do virtually what many desktop applications can. If you've used Gmail, Facebook, YouTube, Google Calender on the web, you'd have used a web app. Web apps tend to be dynamic and navigations in a web app usually don't require a full page refresh and instead use JavaScript to fetch remote data for the next page and dynamically change the contents and URL. Since web apps are complex software involving multiple modules, the common application architectures we learnt in Software Engineering classes like Model-view-controller (MVC), Model-view-viewmodel (MVVM) are also applicable when building web apps. React is one of the most popular JavaScript libraries by Facebook to build interactive web applications and many React web apps adopt a unidirectional Flux/Redux-based architecture.
|
||||
|
||||
Different applications have their own unique aspects and talking points. It's imperative that you focus on the parts that are unique to the application and not spend too much time talking about general stuff that are applicable to all questions. Firstly, design the high-level architecture, identify the components in the system, and the API between the components. Then dive into a few areas that are interesting to the problem and how to implement or optimize them.
|
||||
|
||||
### Examples
|
||||
|
||||
Here's a list of application questions commonly asked during front end system design interviews and the areas you should focus on:
|
||||
|
||||
| Application | Examples | Important Areas |
|
||||
| --- | --- | --- |
|
||||
| [News Feed](/questions/system-design/news-feed-facebook) | Facebook, Twitter | Feed interactions, Feed pagination approaches, Message/post composer |
|
||||
| [Messaging/Chat](/questions/system-design/chat-application-messenger) | Messenger, Slack, Discord | Message syncing, Real-time chat, Messages list, Chat list |
|
||||
| [E-commerce Marketplaces](/questions/system-design/e-commerce-amazon) | Amazon, eBay | Product listing pages, Product detail pages, Cart, Checkout |
|
||||
| [Photo Sharing](/questions/system-design/photo-sharing-instagram) | Instagram, Flickr, Google Photos | Photos browsing, Photos editing, Photos uploading |
|
||||
| [Travel Booking](/questions/system-design/travel-booking-airbnb) | Airbnb, Skyscanner | Search UI, Search results, Booking UI |
|
||||
| [Email Client](/questions/system-design/email-client-outlook) | Outlook, Apple Mail, Gmail | Mailbox syncing, Mailbox UI, Email composer, |
|
||||
| Video Streaming | YouTube, Netflix, TikTok | Video player, Video streaming, Video detail page, Recommended videos |
|
||||
| Collaborative Apps | Google Docs, Google Sheets, Google Slides, Notion | Real-time collaboration, State syncing |
|
||||
| Drawing | Figma, Lucidchart | Rendering approach, Client state/data model |
|
||||
| Maps | Google/Apple Maps, Foursquare City Guide | Map rendering, Displaying locations |
|
||||
| File Storage | Google Drive, Dropbox | File uploading, File downloading, File explorer |
|
||||
| Video Conferencing | Zoom, Google Meet | Video streaming, Various viewing modes |
|
||||
| Ridesharing | Uber, Lyft | Trip booking, Driver location |
|
||||
| Music Streaming | Spotify, Apple Music | Music player UI, Playlists UI |
|
||||
| Games | Tetris, Snake | Game state, Game loop, Game logic |
|
||||
|
||||
## UI Components
|
||||
|
||||
In modern front end development, it is common to use component libraries to build applications. Some popular component libraries you might have used before include jQuery UI (how old school!), Bootstrap, Material UI, Chakra UI, etc.
|
||||
|
||||
It is an expectation of Front End Engineers to be able to build the various UI components needed by an application. Some UI components can be easy to build (e.g. text, button, badge, etc), while others can be much more complex (autocomplete, dropdown, modal, etc). Most of the time, if you are asked to design a UI component, it would be from the latter category.
|
||||
|
||||
Firstly determine the subcomponents of the component (e.g. for an image carousel, there's the image, the pagination buttons, thumbnails), define the external-facing API of the component (what options/props the component should accept), describe the internal component state, API between the subcomponents (if relevant), then dive into optimizations and considerations for performance, accessibility, user experience, security, etc where relevant.
|
||||
|
||||
You might have to write a small amount code for one or more of the following purposes:
|
||||
|
||||
1. Describe the component hierarchy.
|
||||
1. Describe the shape of the component state.
|
||||
1. Explain some non-trivial logic within the component.
|
||||
|
||||
```jsx
|
||||
<ImageCarousel
|
||||
images={...}
|
||||
onPrev={...}
|
||||
onNext={...}
|
||||
layout="horizontal">
|
||||
<ImageCarouselImage style={...} />
|
||||
<ImageThumbnail onClick={...} />
|
||||
</ImageCarousel>
|
||||
```
|
||||
|
||||
### Customizing Theming
|
||||
|
||||
You will most certainly be expected to design a way for users of the component (developers) to customize the component appearance. Refer to [Front End Interview Guidebook's UI Components API Design Principles Section](/front-end-interview-guidebook/user-interface-components-api-design-principles) for an overview and comparison of the different approaches.
|
||||
|
||||
### Examples
|
||||
|
||||
Examples of UI components asked during front end system design interviews:
|
||||
|
||||
- Design an [autocomplete component](/questions/system-design/autocomplete)
|
||||
- Design a [dropdown menu component](/questions/system-design/dropdown-menu)
|
||||
- Design an [embeddable poll widget](/questions/system-design/poll-widget)
|
||||
- Design an [image carousel](/questions/system-design/image-carousel)
|
||||
- Design a [modal component](/questions/system-design/modal-dialog)
|
||||
- Design a data table with sorting and pagination
|
||||
- Design a datepicker
|
||||
- Design a multiselect component
|
||||
|
||||
## What to do during interviews?
|
||||
|
||||
Now that you have an understanding of the kind of questions you can be asked during Front End System Design interviews, how do you go about answering them? We came up with the [RADIO framework](/system-design/framework), an easy-to-remember structured approach that you can use to ace system design interview questions.
|
||||
Loading…
Reference in New Issue