fesd: tweaks
This commit is contained in:
Yangshun
parent
937cb12529
commit
d0cf854d5b
|
|
@ -19,12 +19,13 @@
|
|||
"14d3c301",
|
||||
"bd8dfa90",
|
||||
"bf8e2bdb",
|
||||
"763613a6",
|
||||
"56a1a69a",
|
||||
"430f5bbd",
|
||||
"f2986ae5",
|
||||
"6e6e30f3",
|
||||
"13999e42",
|
||||
"54bd1adf",
|
||||
"a102f2b",
|
||||
"5ae158d2",
|
||||
"8ae07331",
|
||||
"17f2899a",
|
||||
"25e5b6fc",
|
||||
"1b8c8cf4",
|
||||
"f4d4f36d"
|
||||
|
|
@ -41,12 +42,13 @@
|
|||
"14d3c301",
|
||||
"bd8dfa90",
|
||||
"bf8e2bdb",
|
||||
"763613a6",
|
||||
"56a1a69a",
|
||||
"430f5bbd",
|
||||
"f2986ae5",
|
||||
"6e6e30f3",
|
||||
"13999e42",
|
||||
"54bd1adf",
|
||||
"a102f2b",
|
||||
"5ae158d2",
|
||||
"8ae07331",
|
||||
"17f2899a",
|
||||
"25e5b6fc",
|
||||
"1b8c8cf4",
|
||||
"f4d4f36d"
|
||||
|
|
|
|||
|
|
@ -24,17 +24,19 @@ Write down each step of the RADIO framework on the whiteboard at the start of th
|
|||
|
||||
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.
|
||||
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 wants 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.
|
||||
On the opposite of the spectrum of answering too quickly, there are people who remain too 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.
|
||||
Don't go down a rabbit hole of diving too deep into a particular component. Define an initial architecture/high-level design first, then proceed to elaborate on 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.
|
||||
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 signals to the interviewer.
|
||||
|
||||
## Using buzzwords without being able to explain them
|
||||
|
||||
|
|
|
|||
|
|
@ -24,17 +24,19 @@ seo_description: 了解候选人在前端系统设计面试中常犯的错误以
|
|||
|
||||
不要坚持只有一个解决方案，特别是如果面试官提示你使用替代方法。通常情况下，有多种解决问题的方法，每种方法都有其自身的权衡。
|
||||
|
||||
面试官希望看到你确定一个适合当前问题的、具有正确权衡的解决方案，而不是你说只有一个正确或最佳的解决方案。其他解决方案可能明显很糟糕，并且对你来说很明显，但面试官需要听到你解释它们为什么不好。
|
||||
面试官希望看到你针对手头的问题确定一个具有正确权衡的解决方案，而不是你说只有一个正确或最佳的解决方案。其他解决方案可能明显很糟糕，对你来说也很明显，但面试官希望听到你解释为什么它们很糟糕。
|
||||
|
||||
## 始终保持沉默
|
||||
|
||||
与回答太快相反，有些人会保持沉默。不要一直保持沉默，只在脑海中思考。大声思考！系统设计面试旨在成为你和面试官之间的协作练习。将你的面试官视为同事，提出你已确定的问题，提出想法，并与他们讨论可能的解决方案。
|
||||
与回答太快相反，有些人过于沉默。不要一直保持沉默，只在脑海中思考——大声思考！
|
||||
|
||||
系统设计面试旨在成为你和面试官之间的协作练习。将你的面试官视为同事，提出你已确定的问题，提出想法，并与他们讨论可能的解决方案。
|
||||
|
||||
## 钻牛角尖
|
||||
|
||||
不要钻牛角尖，深入研究某个特定组件。首先提出架构/高级设计，然后继续系统的各个部分。专注于对问题最重要的部分。
|
||||
不要陷入深入研究特定组件的兔子洞。首先定义一个初始架构/高级设计，然后继续详细阐述系统的各个部分。专注于对问题最重要的部分。
|
||||
|
||||
如果你不确定，请询问面试官是否应该深入研究特定组件。花太多时间讨论一个不重要的组件会很糟糕，浪费宝贵的时间，而没有向面试官提供有用的信号。
|
||||
如果你不确定，请询问面试官是否应该深入研究特定组件。花太多时间讨论一个不重要的组件是不好的，这会浪费宝贵的时间，而没有向面试官提供有用的信号。
|
||||
|
||||
## 使用无法解释的流行语
|
||||
|
||||
|
|
|
|||
|
|
@ -24,14 +24,13 @@
|
|||
"7ef2ce0c",
|
||||
"457f88e9",
|
||||
"38888fb5",
|
||||
"42fc48cf",
|
||||
"76a5c505",
|
||||
"c2b3bece",
|
||||
"b8ff4c02",
|
||||
"e9e22f0c",
|
||||
"c8f9f67a",
|
||||
"15959410",
|
||||
"189b50dd",
|
||||
"e982bdde",
|
||||
"49cc6d02",
|
||||
"67a1d4f3",
|
||||
"77ca216d",
|
||||
"23733c97"
|
||||
|
|
@ -53,14 +52,13 @@
|
|||
"7ef2ce0c",
|
||||
"457f88e9",
|
||||
"38888fb5",
|
||||
"42fc48cf",
|
||||
"76a5c505",
|
||||
"c2b3bece",
|
||||
"b8ff4c02",
|
||||
"e9e22f0c",
|
||||
"c8f9f67a",
|
||||
"15959410",
|
||||
"189b50dd",
|
||||
"e982bdde",
|
||||
"49cc6d02",
|
||||
"67a1d4f3",
|
||||
"77ca216d",
|
||||
"23733c97"
|
||||
|
|
|
|||
|
|
@ -61,14 +61,12 @@ _Front end domain areas include Performance, Networking, HTML/CSS, Accessibility
|
|||
|
||||
<div className="mt-6 space-x-1 space-y-1 text-sm">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Requirements exploration, Data model, Interface definition, Optimizations and deep
|
||||
dive
|
||||
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.
|
||||
|
|
@ -87,8 +85,8 @@ Relevant framework sections: **Optimizations and deep dive**
|
|||
|
||||
<div className="mt-6 space-x-1 space-y-1 text-sm">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Architecture / High-level design, Data model, Interface definition, Optimizations
|
||||
and deep dive
|
||||
Architecture / High-level design, Data model, Interface definition,
|
||||
Optimizations and deep dive
|
||||
</div>
|
||||
|
||||
## Summary
|
||||
|
|
|
|||
|
|
@ -66,8 +66,6 @@ seo_description: 大公司面试官通常用来评估前端系统设计面试的
|
|||
|
||||
## 产品和用户体验意识
|
||||
|
||||
相关框架部分：**优化和深入研究**
|
||||
|
||||
* 提出了一个稳健的解决方案，为优秀的产品奠定了基础。
|
||||
* 在回答问题时考虑了用户体验：加载状态、性能（感知或实际）、移动友好性、键盘友好性等。
|
||||
* 考虑了错误情况并提出了处理方法。
|
||||
|
|
|
|||
|
|
@ -13,20 +13,20 @@
|
|||
"478e0bff",
|
||||
"9746ae2a",
|
||||
"7fce111a",
|
||||
"8fcd6657",
|
||||
"f8ebfb03",
|
||||
"b5e6c41e",
|
||||
"bb871ac0",
|
||||
"2b76a235",
|
||||
"709ce433",
|
||||
"58ca038c",
|
||||
"e59efbf5",
|
||||
"bdab5a83",
|
||||
"898b7d7b",
|
||||
"b130f568",
|
||||
"c4eb45f2",
|
||||
"73d770ac",
|
||||
"c4001aa6",
|
||||
"e87661d2",
|
||||
"fb14e289",
|
||||
"ca0a950f",
|
||||
"e618f953",
|
||||
"a4e3385",
|
||||
"a63c8972",
|
||||
"98e9468",
|
||||
"1672db9c",
|
||||
|
|
@ -34,8 +34,8 @@
|
|||
"382d5d02",
|
||||
"441d74c3",
|
||||
"ec63fb73",
|
||||
"8a777655",
|
||||
"bc1a4e32",
|
||||
"91cc4f97",
|
||||
"5d960a90",
|
||||
"e5a3154d",
|
||||
"2a7816d0",
|
||||
"e047d9f0",
|
||||
|
|
@ -44,10 +44,10 @@
|
|||
"62fde6f1",
|
||||
"57018474",
|
||||
"3726d095",
|
||||
"8a3d1c9",
|
||||
"b963df66",
|
||||
"88582392",
|
||||
"c4718519",
|
||||
"71d5264c",
|
||||
"69d86bfc",
|
||||
"68a0601f",
|
||||
"596c7a77",
|
||||
"caed9d8e",
|
||||
"f44ef58b",
|
||||
|
|
@ -64,7 +64,7 @@
|
|||
"2451695f",
|
||||
"d8bd6241",
|
||||
"cde922c3",
|
||||
"e104a4bf",
|
||||
"a2eb6df4",
|
||||
"f79d8df9",
|
||||
"274db8e9",
|
||||
"d90ae5c9",
|
||||
|
|
@ -88,15 +88,15 @@
|
|||
"1139dcd1",
|
||||
"c35cf80b",
|
||||
"e7a64ca8",
|
||||
"20b6030a",
|
||||
"b426ab3d",
|
||||
"2a7816d0",
|
||||
"84fb1fa5",
|
||||
"4cf6de5a",
|
||||
"ef821638",
|
||||
"7cf98f3c",
|
||||
"853a7138",
|
||||
"8ae8c685",
|
||||
"b5347d4f",
|
||||
"25f2fdae",
|
||||
"92417292",
|
||||
"438772a9",
|
||||
"5f653c52",
|
||||
"2a7816d0",
|
||||
|
|
@ -109,20 +109,20 @@
|
|||
"478e0bff",
|
||||
"9746ae2a",
|
||||
"7fce111a",
|
||||
"8fcd6657",
|
||||
"f8ebfb03",
|
||||
"b5e6c41e",
|
||||
"bb871ac0",
|
||||
"2b76a235",
|
||||
"709ce433",
|
||||
"58ca038c",
|
||||
"e59efbf5",
|
||||
"bdab5a83",
|
||||
"898b7d7b",
|
||||
"b130f568",
|
||||
"c4eb45f2",
|
||||
"73d770ac",
|
||||
"c4001aa6",
|
||||
"e87661d2",
|
||||
"fb14e289",
|
||||
"ca0a950f",
|
||||
"e618f953",
|
||||
"a4e3385",
|
||||
"a63c8972",
|
||||
"98e9468",
|
||||
"1672db9c",
|
||||
|
|
@ -130,8 +130,8 @@
|
|||
"382d5d02",
|
||||
"441d74c3",
|
||||
"ec63fb73",
|
||||
"8a777655",
|
||||
"bc1a4e32",
|
||||
"91cc4f97",
|
||||
"5d960a90",
|
||||
"e5a3154d",
|
||||
"2a7816d0",
|
||||
"e047d9f0",
|
||||
|
|
@ -140,10 +140,10 @@
|
|||
"62fde6f1",
|
||||
"57018474",
|
||||
"3726d095",
|
||||
"8a3d1c9",
|
||||
"b963df66",
|
||||
"88582392",
|
||||
"c4718519",
|
||||
"71d5264c",
|
||||
"69d86bfc",
|
||||
"68a0601f",
|
||||
"596c7a77",
|
||||
"caed9d8e",
|
||||
"f44ef58b",
|
||||
|
|
@ -160,7 +160,7 @@
|
|||
"2451695f",
|
||||
"d8bd6241",
|
||||
"cde922c3",
|
||||
"e104a4bf",
|
||||
"a2eb6df4",
|
||||
"f79d8df9",
|
||||
"274db8e9",
|
||||
"d90ae5c9",
|
||||
|
|
@ -184,15 +184,15 @@
|
|||
"1139dcd1",
|
||||
"c35cf80b",
|
||||
"e7a64ca8",
|
||||
"20b6030a",
|
||||
"b426ab3d",
|
||||
"2a7816d0",
|
||||
"84fb1fa5",
|
||||
"4cf6de5a",
|
||||
"ef821638",
|
||||
"7cf98f3c",
|
||||
"853a7138",
|
||||
"8ae8c685",
|
||||
"b5347d4f",
|
||||
"25f2fdae",
|
||||
"92417292",
|
||||
"438772a9",
|
||||
"5f653c52",
|
||||
"2a7816d0",
|
||||
|
|
|
|||
|
|
@ -12,11 +12,11 @@ In the context of front end system design interviews, the systems you are asked
|
|||
|
||||
## 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.
|
||||
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 / Core entities**: Describe the core entities and its data – the fields each entity contains 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 possible optimization opportunities and specific areas of interest when building the product
|
||||
|
||||
## Requirements exploration
|
||||
|
||||
|
|
@ -26,24 +26,24 @@ In the context of front end system design interviews, the systems you are asked
|
|||
|
||||
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.
|
||||
No two system design interview experiences will be the same even if you have been asked the same question before. 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).
|
||||
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#examples).
|
||||
|
||||
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.
|
||||
Let's assume you didn't clarify which parts of the product to focus on and you 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.
|
||||
- **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 an interaction takes), scalability (how many items can be present on the page before the page slows to a crawl), good user experience, etc.
|
||||
|
||||
There are two ways you can get the answer to this question:
|
||||
|
||||
|
|
@ -63,9 +63,9 @@ You should clarify the core features beforehand and design for them before movin
|
|||
- 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.)
|
||||
- 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.
|
||||
The questions above should give you a good starting list but it is by no means 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.
|
||||
|
||||
|
|
@ -86,14 +86,14 @@ Examples of components/modules which are commonly found in a high-level front en
|
|||
- **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.
|
||||
- **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 in 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.
|
||||
- **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 product-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.
|
||||
It is important to realize that not every common component mentioned above will be relevant and necessary for every product, it depends on the unique aspects of the product.
|
||||
|
||||
After drawing out the architecture diagram, verbally describe the responsibilities of each component (box in the diagram).
|
||||
|
||||
|
|
@ -133,7 +133,7 @@ Data that originates from the server, usually from a database and meant to be se
|
|||
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.
|
||||
- **Ephemeral data**: Temporary state that lasts for a short time. Common examples include form validation state, current navigation 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.
|
||||
|
||||
|
|
@ -223,7 +223,7 @@ The client-client API can be written in a similar fashion as the server-client A
|
|||
|
||||
### 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.
|
||||
If you're asked to design a UI component, for the "Interface" section, discuss the customization options for the component, similar to the props of a React component.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -235,12 +235,12 @@ If you're asked to design a UI component, for the "Interface" section, discuss a
|
|||
|
||||
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.
|
||||
- **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).
|
||||
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 product and some topics are entirely irrelevant to certain products (possible but unlikely).
|
||||
|
||||
- Performance
|
||||
- User Experience
|
||||
|
|
|
|||
|
|
@ -12,11 +12,11 @@ seo_description: 一个强大的框架，旨在帮助您以结构化的方式回
|
|||
|
||||
## RADIO 是关于什么的？
|
||||
|
||||
1. **需求探索**：彻底了解问题，并通过提出一些澄清问题来确定范围。
|
||||
2. **架构/高级设计**：确定产品的关键组件以及它们之间的关系。
|
||||
3. **数据模型**：描述各种数据实体、它们包含的字段以及它们所属的组件。
|
||||
4. **接口定义 (API)**：定义产品中组件之间的接口 (API)、每个 API 的功能、它们的参数和响应。
|
||||
5. **优化和深入研究**：讨论构建产品时可能的优化机会和特定的感兴趣领域。
|
||||
1. **需求探索**：彻底了解问题，并通过提出一些澄清问题来确定范围
|
||||
2. **架构/高级设计**：确定产品的关键组件以及它们之间的相互关系
|
||||
3. **数据模型/核心实体**：描述核心实体及其数据——每个实体包含的字段以及它们属于哪个（些）组件
|
||||
4. **接口定义（API）**：定义产品中组件之间的接口（API）、每个 API 的功能、它们的参数和响应
|
||||
5. **优化和深入研究**：讨论构建产品时可能的优化机会和特定感兴趣的领域
|
||||
|
||||
## 需求探索
|
||||
|
||||
|
|
@ -26,24 +26,24 @@ seo_description: 一个强大的框架，旨在帮助您以结构化的方式回
|
|||
|
||||
系统设计面试问题本质上是开放式的，通常是模糊的，并且故意未充分说明。**您需要通过提出有用的问题来深入挖掘并澄清问题中的歧义。** 将您的面试官视为您正在合作进行新项目的项目经理，提出足够的问题，以便您知道您要尝试解决的问题以及您需要构建的内容。实际上，有些问题根本不需要任何工程就可以解决！
|
||||
|
||||
即使您可能会被问到相同的问题，但没有两次系统设计面试经历是相同的。面试官有不同的背景，并且可能优先考虑系统的不同方面。抓住这个机会找出他们最感兴趣的内容，并相应地计划您的答案。
|
||||
即使您之前被问过相同的问题，也不会有两次系统设计面试经历是相同的。面试官的背景各不相同，可能优先考虑系统的不同方面。借此机会找出他们最感兴趣的内容，并相应地计划您的答案。
|
||||
|
||||
在进入面试的下一部分之前，您应该获得一些一般性问题的答案：
|
||||
|
||||
### 我们应该关注哪些主要用例？
|
||||
|
||||
想象一下，您被要求“设计 Facebook”。Facebook 是一个巨大的平台，有新闻提要、个人资料、朋友、群组、故事等等。您应该关注 Facebook 的哪些部分？面试官心里有答案，但希望您通过提问来找出答案。通常您应该关注产品最独特的方面，即定义它的功能。对于 Facebook 来说，它将是新闻提要、提要的分页以及创建新帖子。对于 YouTube 来说，这将是观看视频的体验。其他类型产品的重要领域可以在 [问题类型](/system-design/types-of-questions) 中找到。
|
||||
假设您被要求“设计 Facebook”。Facebook 是一个巨大的平台，有新闻提要、个人资料、朋友、群组、故事等等。您应该关注 Facebook 的哪些部分？面试官心里有答案，但希望您通过提问来找出答案。通常，您应该关注产品最独特的方面，即定义它的功能。对于 Facebook 来说，它将是新闻提要、提要的分页以及创建新帖子。对于 YouTube 来说，这将是观看视频的体验。其他类型产品的重要领域可以在[问题类型](/system-design/types-of-questions#examples)中找到。
|
||||
|
||||
在这一页的其余部分，我们将使用“设计 Facebook”作为问题，并将其应用于该框架。
|
||||
|
||||
假设你没有明确要关注产品的哪些部分，假设你应该谈论交友流程并开始谈论它。在最好的情况下，优秀的面试官会引导你回到问题的本意，但他们会注意到你没有澄清问题。在最坏的情况下，经验不足的面试官会让你继续说下去，并礼貌地寻找机会纠正你，但你已经浪费了一些宝贵的时间来讨论一个不重要的话题。
|
||||
假设您没有澄清要关注产品的哪些部分，并且您认为您应该谈论交友流程并开始谈论它。在最好的情况下，好的面试官会引导您回到问题的本意，但他们会注意到您没有澄清问题。在最坏的情况下，经验不足的面试官会让你继续说下去，并礼貌地寻找机会纠正你，但你已经浪费了一些宝贵的时间来讨论一个不重要的话题。
|
||||
|
||||
### 什么是功能需求和非功能需求？
|
||||
|
||||
首先，什么是功能需求和非功能需求？
|
||||
|
||||
* **功能需求**：产品的基本要求，没有这些要求产品就无法运行。这通常是用户是否可以正确完成核心流程。
|
||||
* **非功能需求**：被视为对产品的改进，但对于产品是否可用并非严格要求，即没有这些产品仍然可以使用。这些包括性能（页面加载速度、交互速度）、可扩展性（页面上可以存在多少个项目）、良好的用户体验等。
|
||||
* **功能需求**：产品的基本要求，如果没有这些要求，产品就无法运行。这通常是用户是否可以正确完成核心流程。
|
||||
* **非功能需求**：被视为对产品的改进，但并非产品可用的严格要求，即没有这些产品仍然可以使用。这些包括性能（页面加载速度、交互速度）、可扩展性（页面上可以存在多少个项目，然后页面才会变慢）、良好的用户体验等。
|
||||
|
||||
你可以通过两种方式获得这个问题的答案：
|
||||
|
||||
|
|
@ -60,12 +60,12 @@ seo_description: 一个强大的框架，旨在帮助您以结构化的方式回
|
|||
|
||||
### 其他问题：
|
||||
|
||||
* 需要支持哪些设备/平台（桌面/平板电脑/手机）？
|
||||
* 需要支持哪些设备/平台（桌面/平板电脑/移动设备）？
|
||||
* 是否需要离线支持？
|
||||
* 该产品的主要用户是谁？
|
||||
* 有什么性能要求吗？（性能要求通常属于非功能需求。）
|
||||
* 有什么性能要求吗？如果有的话？性能要求通常属于非功能性需求
|
||||
|
||||
上面的列表应该给你一个很好的问题列表作为开始，但这并不是一个详尽的列表！不同的问题将需要你提出特定于领域的问题，我们将在案例研究中讨论这些问题。
|
||||
上面的问题应该为您提供一个良好的开端列表，但这绝不是一个详尽的列表！不同的问题将要求您提出特定于领域的问题，我们将在案例研究中讨论这些问题。
|
||||
|
||||
建议你将商定的要求写在某个地方，以便你可以在整个面试过程中参考它们，并确保你已经涵盖了它们。
|
||||
|
||||
|
|
@ -83,17 +83,17 @@ seo_description: 一个强大的框架，旨在帮助您以结构化的方式回
|
|||
|
||||
前端设计高级设计中常见的组件/模块示例：
|
||||
|
||||
* **服务器**：在前端系统设计面试中，我们可以将服务器视为一个黑盒，并假设它公开了一些你可以通过 HTTP/WebSockets 调用的 API。
|
||||
* **视图**：这代表用户看到的内容，它通常包含更小的子视图。可以仅包含客户端状态。
|
||||
* **控制器**：响应用户交互并处理来自存储/模型的数据的模块，其格式是视图所期望的。如果应用程序很小，并且模块之间没有太多数据传递，则不一定需要此模块。
|
||||
* **模型/客户端存储**：数据所在的位置。存储包含将通过视图呈现给用户的数据，并且存储在面试环境中往往是应用程序范围的。实际上，你可以在一个应用程序中拥有多个存储，并且存储可以包含其他存储。
|
||||
* **服务器**：在前端系统设计面试中，我们可以将服务器视为一个黑盒，并假设它公开了一些您可以通过 HTTP/WebSockets 调用的 API。
|
||||
* **视图**：这代表用户看到的内容，它通常包含其中的较小子视图。可以仅包含客户端状态。
|
||||
* **控制器**：响应用户交互并以视图期望的格式处理来自存储/模型的数据的模块。如果应用程序很小，并且模块之间没有太多数据传递，则不一定需要此模块。
|
||||
* **模型/客户端存储**：数据所在的位置。存储包含将通过视图呈现给用户的数据，并且存储在面试环境中往往是应用程序范围的。实际上，您可以在一个应用程序中拥有多个存储，并且存储可以包含其他存储。
|
||||
|
||||
定义组件的职责时要考虑的其他事项：
|
||||
|
||||
* **关注点分离**：组件旨在模块化，用于封装一组功能和数据。考虑每个组件的目的/功能、它应该包含什么数据以及它如何为系统的其余部分提供服务（它可以为其他组件做什么）。
|
||||
* **计算应该发生在哪里**：如果需要进行一些计算（例如，根据搜索词过滤结果，计算购物车的总金额），应该在服务器还是客户端完成这项工作？每种方法都有权衡，并且该决定取决于问题和上下文。
|
||||
* **关注点分离**：组件旨在模块化，并用于封装一组功能和数据。考虑每个组件的目的/功能、它应该包含什么数据以及它如何为系统的其余部分提供服务（它可以为其他组件做什么）。
|
||||
* **应该在哪里进行计算**：如果需要进行一些计算（例如，根据搜索词过滤结果，计算购物车的总金额），应该在服务器还是客户端完成这项工作？每种方法都有权衡，并且该决定既取决于产品，也取决于上下文。
|
||||
|
||||
重要的是要认识到，并非上面提到的每个常见组件都与每个问题相关且需要，这取决于产品。
|
||||
重要的是要认识到，上面提到的并非每个常见组件都与每个产品相关且必要，这取决于产品的独特方面。
|
||||
|
||||
在绘制出架构图后，用语言描述每个组件（图中的框）的职责。
|
||||
|
||||
|
|
@ -132,8 +132,8 @@ seo_description: 一个强大的框架，旨在帮助您以结构化的方式回
|
|||
|
||||
仅客户端数据，也常被称为状态，是只需要存在于客户端的数据，不需要发送到服务器写入数据库。客户端数据可以进一步细分为两类：
|
||||
|
||||
* **要持久化的数据**：通常是用户输入，例如输入到表单字段中的数据。这些数据通常必须发送到服务器并保存到数据库中才能使用。
|
||||
* **临时数据**：持续很短时间的临时状态。常见示例包括表单验证状态、当前选项卡、某个部分是否已展开等。当浏览器选项卡关闭时，丢失这些数据通常是可以接受的。
|
||||
* **要持久化的数据**：通常是用户输入，例如输入到表单字段中的数据。这些数据通常必须发送到服务器并保存到数据库中才能有用。
|
||||
* **临时数据**：持续很短时间的临时状态。常见的例子包括表单验证状态、当前导航选项卡、某个部分是否已展开等。当浏览器选项卡关闭时，丢失这些数据通常是可以接受的。
|
||||
|
||||
在列出数据字段时，确定该字段是什么类型的数据，是服务器生成的数据还是仅客户端数据会很有用。
|
||||
|
||||
|
|
@ -223,7 +223,7 @@ feed 响应是一个分页列表，因此 API 期望分页参数。
|
|||
|
||||
### UI 组件系统设计的 API
|
||||
|
||||
如果您被要求设计一个 UI 组件，对于“接口”部分，请讨论组件的自定义选项，类似于 React 组件的 props。
|
||||
如果您被要求设计一个 UI 组件，对于“接口”部分，请讨论该组件的自定义选项，类似于 React 组件的 props。
|
||||
|
||||
***
|
||||
|
||||
|
|
@ -235,12 +235,12 @@ feed 响应是一个分页列表，因此 API 期望分页参数。
|
|||
|
||||
优化和深入研究部分没有固定的方法，您可以自由地专注于产品的不同领域。没有足够的时间来涵盖每个领域，因此请根据以下指南仔细选择您想如何分配时间：
|
||||
|
||||
* **关注产品的重要领域。** 对于电子商务网站，性能至关重要，您需要花费大量时间深入研究可以完成的各种性能优化。对于协作编辑器，复杂性在于如何处理竞态条件和并发修改，因此您需要专注于解释这一点。
|
||||
* **专注于您的优势。** 展示您的领域知识。如果您精通可访问性，请谈谈产品中可能发生的各种可访问性陷阱以及如何解决它们。用您的知识给面试官留下深刻印象。如果您是性能大师，请解释可以提供流畅用户体验的各种性能优化机会。
|
||||
* **关注产品的重要领域**：对于电子商务网站，性能至关重要，您需要花费大量时间深入研究可以完成的各种性能优化。对于协作编辑器，复杂之处在于如何处理竞争条件和并发修改，因此您需要专注于解释这一点。
|
||||
* **专注于您的优势**：展示您的领域知识。如果您精通可访问性，请谈谈产品中可能发生的各种可访问性陷阱以及如何解决它们。用您的知识给面试官留下深刻印象。如果您是性能大师，请解释可以提供流畅用户体验的各种性能优化机会。
|
||||
|
||||
### 一般优化/深入研究领域
|
||||
|
||||
以下是您可以在本节中讨论的主题列表。请记住，主题的重要性取决于问题，并且某些主题与某些问题完全无关（可能但不太可能）。
|
||||
以下是您可以讨论的本节主题列表。请记住，主题的重要性取决于产品，某些主题与某些产品完全无关（可能但不太可能）。
|
||||
|
||||
* 性能
|
||||
* 用户体验
|
||||
|
|
@ -258,7 +258,7 @@ feed 响应是一个分页列表，因此 API 期望分页参数。
|
|||
|
||||
| 步骤 | 目标 | 推荐时长 |
|
||||
| --- | --- | --- |
|
||||
| 需求探索 | 彻底了解问题，并通过提出一些澄清问题来确定范围。 | <15% |
|
||||
| 需求探索 | 彻底了解问题，并通过提出一些澄清问题来确定范围。 | \<15% |
|
||||
| 架构/高级设计 | 确定产品的关键组件以及它们之间的关系。 | ~20% |
|
||||
| 数据模型 | 描述各种数据实体、它们包含的字段以及它们所属的组件。 | ~10% |
|
||||
| 接口定义 (API) | 定义产品中组件之间的接口 (API)、每个 API 的功能、它们的参数和响应。 | ~15% |
|
||||
|
|
|
|||
|
|
@ -15,16 +15,16 @@
|
|||
"e2670984",
|
||||
"fd523bd0",
|
||||
"73fcd5dc",
|
||||
"7696f10c",
|
||||
"98983189",
|
||||
"107fb4e6",
|
||||
"d0ca6bbd",
|
||||
"862ea9fa",
|
||||
"1c6901cf",
|
||||
"e79093d0",
|
||||
"99f595a",
|
||||
"2a1af6cd",
|
||||
"2772fe13",
|
||||
"622e42c9",
|
||||
"f1bcf3f4",
|
||||
"db2e5ac6",
|
||||
"d8d511cd",
|
||||
"52ca7b1b"
|
||||
"ccd38694"
|
||||
]
|
||||
},
|
||||
"targets": {
|
||||
|
|
@ -34,16 +34,16 @@
|
|||
"e2670984",
|
||||
"fd523bd0",
|
||||
"73fcd5dc",
|
||||
"7696f10c",
|
||||
"98983189",
|
||||
"107fb4e6",
|
||||
"d0ca6bbd",
|
||||
"862ea9fa",
|
||||
"1c6901cf",
|
||||
"e79093d0",
|
||||
"99f595a",
|
||||
"2a1af6cd",
|
||||
"2772fe13",
|
||||
"622e42c9",
|
||||
"f1bcf3f4",
|
||||
"db2e5ac6",
|
||||
"d8d511cd",
|
||||
"52ca7b1b"
|
||||
"ccd38694"
|
||||
]
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -16,27 +16,27 @@ GreatFrontEnd's front end system design resources are perhaps the most comprehen
|
|||
|
||||
{/* TODO: Add some testimonials regarding front end system design */}
|
||||
|
||||
## Front end vs Back end system design
|
||||
## Front end vs Back end / Full stack 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.
|
||||
In traditional Software Engineer system design interviews, candidates will be asked to describe the architecture of a distributed system, usually involving web servers, API gateways, load balancers, caches, databases, microservices, message queues, streams, 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 |
|
||||
| Area | Back end / Full stack | Front end |
|
||||
| --- | --- | --- |
|
||||
| Gather requirements | Required | Required |
|
||||
| Architecture / High-level design entities | Distributed cloud services | Application/Component |
|
||||
| Back-of-the-envelope estimation | May be 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) |
|
||||
| Components of the system | Cloud services (e.g. Load balancer, Application server, Database, File storage, Caches, Message queues, CDN, Full-text search) | Application modules (Model, View, Controller) |
|
||||
| Data model | Database 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 |
|
||||
| Deep dives / focus areas | Scalability, Reliability, Consistency, Availability | Performance, User Experience, Accessibility, Internationalization |
|
||||
| Less important (Can treat as a black box) | Client | Server |
|
||||
|
||||
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.
|
||||
For example, a classic question is to ask about designing a Facebook news feed 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**: API for the feed, how to implement feed pagination, how to implement interactions with tweets, how new tweets can be created.
|
||||
- **Back end / Full stack**: Capacity estimation, designing the database schema, APIs between microservices, how to ensure the services can scale with the traffic, how to generate a user's news feed in a scalable fashion, what happens when a post is created by a typical user (hundreds of followers) vs celebrities (millions of followers)
|
||||
- **Front end**: HTTP API for the feed, how to implement feed pagination, how to implement interactions with posts, how new posts can be created, user experience and accessibility considerations
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ As you can see, the focus of front end system design interviews can be very diff
|
|||
|
||||
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 that use the RADIO framework.
|
||||
|
||||
- [Types of questions](/system-design/types-of-questions): Types of Front End System Design interview questions and examples.
|
||||
- [RADIO framework](/system-design/framework): A framework for answering Front End System Design interview questions.
|
||||
- [Evaluation axes](/system-design/evaluation-axes): How you are being evaluated and what interviewers are looking out for.
|
||||
- [Common mistakes](/system-design/common-mistakes): Common mistakes to avoid during Front End System Design interviews.
|
||||
- [Types of questions](/system-design/types-of-questions): Types of Front End System Design interview questions and examples
|
||||
- [RADIO framework](/system-design/framework): A framework for answering Front End System Design interview questions
|
||||
- [Evaluation axes](/system-design/evaluation-axes): How you are being evaluated and what interviewers are looking out for
|
||||
- [Common mistakes](/system-design/common-mistakes): Common mistakes to avoid during Front End System Design interviews
|
||||
|
|
|
|||
|
|
@ -16,27 +16,27 @@ GreatFrontEnd 的前端系统设计资源可能是您能找到的最全面的资
|
|||
|
||||
{/* TODO: 添加一些关于前端系统设计的推荐 */}
|
||||
|
||||
## 前端与后端系统设计
|
||||
## 前端 vs 后端 / 全栈系统设计
|
||||
|
||||
在传统的软件工程师系统设计面试中，会要求候选人描述分布式系统的架构，通常涉及 Web 服务器、负载均衡器、缓存、数据库、微服务、任务队列等。
|
||||
在传统的软件工程师系统设计面试中，会要求候选人描述分布式系统的架构，通常涉及 Web 服务器、API 网关、负载均衡器、缓存、数据库、微服务、消息队列、流等。
|
||||
|
||||
对于前端工程师来说，系统设计面试略有不同——更侧重于客户端发生的事情以及客户端和服务器之间的 API 设计，而不是后端发生的事情。
|
||||
|
||||
| 方面 | 后端 | 前端 |
|
||||
| 领域 | 后端 / 全栈 | 前端 |
|
||||
| --- | --- | --- |
|
||||
| 收集需求 | 必需 | 必需 |
|
||||
| 架构/高级设计实体 | 分布式云服务 | 应用程序/组件 |
|
||||
| 简要估算 | 可能需要 | 不需要 |
|
||||
| 系统的组成部分 | 云服务（例如负载均衡器、应用程序服务器、数据库、文件存储、缓存、消息队列、CDN） | 应用程序模块（模型、视图、控制器） |
|
||||
| 架构 / 高级设计实体 | 分布式云服务 | 应用程序/组件 |
|
||||
| 粗略估算 | 可能需要 | 不需要 |
|
||||
| 系统的组件 | 云服务（例如负载均衡器、应用程序服务器、数据库、文件存储、缓存、消息队列、CDN、全文搜索） | 应用程序模块（模型、视图、控制器） |
|
||||
| 数据模型 | 数据库模式 | 应用程序状态 |
|
||||
| 组件之间的 API 类型 | 网络（任何协议） | 网络（HTTP、WebSocket）、JavaScript 函数 |
|
||||
| 重点领域 | 可扩展性、可靠性、可用性 | 性能、用户体验、可访问性、国际化 |
|
||||
| 深入研究/重点领域 | 可扩展性、可靠性、一致性、可用性 | 性能、用户体验、可访问性、国际化 |
|
||||
| 不太重要（可以视为黑盒） | 客户端 | 服务器 |
|
||||
|
||||
例如，一个经典的问题是询问设计 Twitter feed UI，这可以在后端和前端系统面试中提出。
|
||||
例如，一个经典的问题是询问如何设计 Facebook 新闻提要，这可以在后端和前端系统面试中提出。
|
||||
|
||||
* **后端**：容量估算、设计数据库模式、如何确保服务可以随着流量扩展、如何生成用户的 Twitter feed。
|
||||
* **前端**：feed 的 API、如何实现 feed 分页、如何实现与推文的交互、如何创建新推文。
|
||||
* **后端 / 全栈**：容量估算、设计数据库模式、微服务之间的 API、如何确保服务能够随着流量扩展、如何以可扩展的方式生成用户的新闻提要、当普通用户（数百个关注者）与名人（数百万个关注者）创建帖子时会发生什么
|
||||
* **前端**：Feed 的 HTTP API、如何实现 Feed 分页、如何实现与帖子的交互、如何创建新帖子、用户体验和可访问性考虑因素
|
||||
|
||||
正如您所看到的，前端系统设计面试的重点可能与后端有很大不同，并且要很好地回答它们需要不同的方法。
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ GreatFrontEnd 的前端系统设计资源可能是您能找到的最全面的资
|
|||
|
||||
我们的前端系统设计指南分为两部分，您将首先更深入地了解系统设计面试的意义，然后深入研究一些使用 RADIO 框架的前端系统设计案例研究。
|
||||
|
||||
* [问题类型](/system-design/types-of-questions)：前端系统设计面试问题的类型和示例。
|
||||
* [RADIO 框架](/system-design/framework)：用于回答前端系统设计面试问题的框架。
|
||||
* [评估轴](/system-design/evaluation-axes)：您是如何被评估的以及面试官正在寻找什么。
|
||||
* [常见错误](/system-design/common-mistakes)：在前端系统设计面试中要避免的常见错误。
|
||||
* [问题类型](/system-design/types-of-questions)：前端系统设计面试问题的类型和示例
|
||||
* [RADIO 框架](/system-design/framework)：用于回答前端系统设计面试问题的框架
|
||||
* [评估轴](/system-design/evaluation-axes)：如何被评估以及面试官正在寻找什么
|
||||
* [常见错误](/system-design/common-mistakes)：在前端系统设计面试中要避免的常见错误
|
||||
|
|
|
|||
|
|
@ -13,11 +13,12 @@
|
|||
"4473509f",
|
||||
"a35b5e44",
|
||||
"49bc41c2",
|
||||
"48868fea",
|
||||
"28eaff00",
|
||||
"8266a389",
|
||||
"7df37cbe",
|
||||
"2d65d6fb",
|
||||
"70e92007",
|
||||
"a4fff735",
|
||||
"6eb8a1ec",
|
||||
"d5942c75",
|
||||
"f5d1aae5",
|
||||
"4880c013",
|
||||
"16b97cb4",
|
||||
|
|
@ -39,11 +40,12 @@
|
|||
"4473509f",
|
||||
"a35b5e44",
|
||||
"49bc41c2",
|
||||
"48868fea",
|
||||
"28eaff00",
|
||||
"8266a389",
|
||||
"7df37cbe",
|
||||
"2d65d6fb",
|
||||
"70e92007",
|
||||
"a4fff735",
|
||||
"6eb8a1ec",
|
||||
"d5942c75",
|
||||
"f5d1aae5",
|
||||
"4880c013",
|
||||
"16b97cb4",
|
||||
|
|
|
|||
|
|
@ -12,31 +12,33 @@ There are two main kinds of front end system design questions: (1) 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.
|
||||
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, ChatGPT, or Google Calender on the web, you'd have used a web app. Web apps tend to be interactive and dynamic (contents on the page change frequently) and page navigations in a web app usually don't require a full page refresh; the app uses JavaScript to fetch remote data for the next page and dynamically change the contents and URL.
|
||||
|
||||
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.
|
||||
Since web apps are complex software involving multiple modules, common application architectures 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/unique 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 |
|
||||
| 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 |
|
||||
| [News Feed](/questions/system-design/news-feed-facebook) | Facebook, Twitter | Feed interactions, Feed pagination approaches, Post composer |
|
||||
| [Messaging/Chat](/questions/system-design/chat-application-messenger) | Messenger, Slack, Discord | Real-time chat, Message syncing, 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 |
|
||||
| [Video Streaming](/questions/system-design/video-streaming-netflix) | Netflix, YouTube | Video player, Video streaming, Recommended videos |
|
||||
| [Pinterest](/questions/system-design/pinterest) | Pinterest | Masonry layout implementation and media feed optimizations |
|
||||
| [Collaborative Apps](/questions/system-design/collaborative-editor-google-docs) | Google Docs, Google Sheets, Google Slides, Notion | Real-time collaboration protocols, Conflict resolution, State syncing |
|
||||
| [Email Client](/questions/system-design/email-client-outlook) | Outlook, Apple Mail, Gmail | Mailbox syncing, Mailbox UI, Email composer, |
|
||||
| Drawing | Figma, Excalidraw, Canva | Rendering approach, Client state/data model |
|
||||
| [Email Client](/questions/system-design/email-client-outlook) | Outlook, Apple Mail, Gmail | Mailbox syncing, Mailbox UI, Email composer |
|
||||
| Drawing | Figma, Excalidraw, Canva | Rendering approach, Client state/data model, State management |
|
||||
| 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 |
|
||||
| Ridesharing | Uber, Lyft | Trip booking, Driver location, App states |
|
||||
| Music Streaming | Spotify, Apple Music | Audio streaming, Music player UI, Playlists UI |
|
||||
| Games | Tetris, Snake | Game state, Game loop, Game logic |
|
||||
|
||||
## UI components
|
||||
|
|
|
|||
|
|
@ -12,9 +12,11 @@ seo_description: 了解可以提出的前端系统设计面试问题的主要类
|
|||
|
||||
如上所述，为前端系统设计面试设计应用程序将类似于一般的软件工程系统设计面试，事实上，这些问题非常相似。但是，您应该专注于客户端，讨论应用程序架构和客户端实现细节，而不是讨论分布式系统。
|
||||
|
||||
在当今时代，许多网站都是交互式和丰富的应用程序，几乎可以做许多桌面应用程序可以做的事情。如果您在网络上使用过 Gmail、Facebook、YouTube、Google Calender，您就会使用过一个 Web 应用程序。Web 应用程序往往是动态的，Web 应用程序中的导航通常不需要完全刷新页面，而是使用 JavaScript 获取下一页的远程数据，并动态更改内容和 URL。由于 Web 应用程序是涉及多个模块的复杂软件，我们在软件工程课程中学习的常见应用程序架构，如模型-视图-控制器 (MVC)、模型-视图-视图模型 (MVVM) 也适用于构建 Web 应用程序。React 是 Facebook 用于构建交互式 Web 应用程序的最流行的 JavaScript 库之一，许多 React Web 应用程序都采用了基于单向 Flux/Redux 的架构。
|
||||
当今时代，许多网站都是交互式和丰富的应用程序，几乎可以做许多桌面应用程序可以做的事情。 如果您在网络上使用过 Gmail、Facebook、YouTube、ChatGPT 或 Google 日历，那么您就使用过 Web 应用程序。 Web 应用程序往往具有交互性和动态性（页面上的内容经常变化），并且 Web 应用程序中的页面导航通常不需要完全刷新页面； 应用程序使用 JavaScript 获取下一页的远程数据，并动态更改内容和 URL。
|
||||
|
||||
不同的应用程序有其独特的方面和讨论要点。您必须专注于应用程序特有的部分，而不是花太多时间讨论适用于所有问题的一般内容。首先，设计高级架构，确定系统中的组件以及组件之间的 API。然后深入研究几个对问题感兴趣的领域，以及如何实现或优化它们。
|
||||
由于 Web 应用程序是涉及多个模块的复杂软件，因此在软件工程课程中学习的常见应用程序架构（如模型-视图-控制器 (MVC)、模型-视图-视图模型 (MVVM)）也适用于构建 Web 应用程序。 React 是 Facebook 用于构建交互式 Web 应用程序的最流行的 JavaScript 库之一，许多 React Web 应用程序都采用基于单向 Flux/Redux 的架构。
|
||||
|
||||
不同的应用程序有其独特的方面和讨论要点。 重要的是，您要专注于应用程序特有的部分，而不是花太多时间讨论适用于所有问题的通用内容。 首先，设计高级架构，确定系统中的组件以及组件之间的 API。 然后深入研究几个对问题有趣/独特且如何实现或优化它们的领域。
|
||||
|
||||
### 示例
|
||||
|
||||
|
|
@ -22,21 +24,21 @@ seo_description: 了解可以提出的前端系统设计面试问题的主要类
|
|||
|
||||
| 应用程序 | 示例 | 重要领域 |
|
||||
| --- | --- | --- |
|
||||
| [新闻提要](/questions/system-design/news-feed-facebook) | Facebook、Twitter | Feed 交互、Feed 分页方法、消息/帖子撰写器 |
|
||||
| [消息/聊天](/questions/system-design/chat-application-messenger) | Messenger、Slack、Discord | 消息同步、实时聊天、消息列表、聊天列表 |
|
||||
| [电子商务市场](/questions/system-design/e-commerce-amazon) | 亚马逊、eBay | 产品列表页面、产品详细信息页面、购物车、结账 |
|
||||
| [新闻提要](/questions/system-design/news-feed-facebook) | Facebook、Twitter | 提要交互、提要分页方法、帖子撰写器 |
|
||||
| [消息/聊天](/questions/system-design/chat-application-messenger) | Messenger、Slack、Discord | 实时聊天、消息同步、消息列表、聊天列表 |
|
||||
| [电子商务市场](/questions/system-design/e-commerce-amazon) | 亚马逊、eBay | 产品列表页面、产品详细信息页面、购物车、结帐 |
|
||||
| [照片共享](/questions/system-design/photo-sharing-instagram) | Instagram、Flickr、Google Photos | 照片浏览、照片编辑、照片上传 |
|
||||
| [旅行预订](/questions/system-design/travel-booking-airbnb) | Airbnb、Skyscanner | 搜索 UI、搜索结果、预订 UI |
|
||||
| [视频流](/questions/system-design/video-streaming-netflix) | Netflix、YouTube | 视频播放器、视频流、推荐视频 |
|
||||
| [Pinterest](/questions/system-design/pinterest) | Pinterest | Masonry 布局实现和媒体 feed 优化 |
|
||||
| [Pinterest](/questions/system-design/pinterest) | Pinterest | Masonry 布局实现和媒体提要优化 |
|
||||
| [协作应用程序](/questions/system-design/collaborative-editor-google-docs) | Google Docs、Google Sheets、Google Slides、Notion | 实时协作协议、冲突解决、状态同步 |
|
||||
| [电子邮件客户端](/questions/system-design/email-client-outlook) | Outlook、Apple Mail、Gmail | 邮箱同步、邮箱 UI、电子邮件撰写器 |
|
||||
| 绘图 | Figma、Excalidraw、Canva | 渲染方法、客户端状态/数据模型 |
|
||||
| 绘图 | Figma、Excalidraw、Canva | 渲染方法、客户端状态/数据模型、状态管理 |
|
||||
| 地图 | Google/Apple Maps、Foursquare City Guide | 地图渲染、显示位置 |
|
||||
| 文件存储 | Google Drive、Dropbox | 文件上传、文件下载、文件资源管理器 |
|
||||
| 视频会议 | Zoom、Google Meet | 视频流、各种观看模式 |
|
||||
| 乘车共享 | Uber、Lyft | 行程预订、司机位置 |
|
||||
| 音乐流 | Spotify、Apple Music | 音乐播放器 UI、播放列表 UI |
|
||||
| 乘车共享 | Uber、Lyft | 行程预订、司机位置、应用程序状态 |
|
||||
| 音乐流 | Spotify、Apple Music | 音频流、音乐播放器 UI、播放列表 UI |
|
||||
| 游戏 | 俄罗斯方块、贪吃蛇 | 游戏状态、游戏循环、游戏逻辑 |
|
||||
|
||||
## UI 组件
|
||||
|
|
|
|||
Loading…
Reference in New Issue