contents: tweak
This commit is contained in:
Yangshun
parent
9413aaf2bb
commit
10671fae96
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Front End Interview Guide
|
||||
description: Everything you need to know - from types of questions to preparation tactics
|
||||
title: Front End Interview JavaScript Questions and How to Prepare
|
||||
description: Guide to preparing for algorithmic coding questions in front end / web developer interviews — Concepts to know, interview rubrics, and important practice questions.
|
||||
seo_title: Front End Interview Guide | Everything you need to know on how to prepare
|
||||
seo_description: The definitive guide to front end interviews written by Ex-FAANG interviewers. Find out what to expect, the different types of questions and how to prepare.
|
||||
social_title: Front End Interview Guide | GreatFrontEnd
|
||||
|
|
|
|||
|
|
@ -6,24 +6,24 @@ social_title: Cheatsheet for Front End System Design Interviews | GreatFrontEnd
|
|||
seo_description: Summary of the most important things you should take note of during front end system design interviews.
|
||||
---
|
||||
|
||||
## RADIO Framework
|
||||
## 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.
|
||||
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
|
||||
## Evaluation axes
|
||||
|
||||
1. **Problem Exploration**: Demonstrated understanding of the problem, asked clarifying questions to reduce ambiguities and gathered sufficient requirements.
|
||||
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.
|
||||
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
|
||||
## 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.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ During interviews, interviewers look out for signals displayed by candidates bef
|
|||
|
||||
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
|
||||
## Problem exploration
|
||||
|
||||
- Demonstrated thorough understanding of the problem.
|
||||
- Explored the requirements sufficiently by asking relevant clarifying questions to minimize ambiguities.
|
||||
|
|
@ -18,9 +18,9 @@ This section lists some of the behaviors that candidates should display. Bear th
|
|||
- 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">
|
||||
<div className="mt-6 space-x-1 space-y-1 text-sm">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Requirements Exploration
|
||||
Requirements exploration
|
||||
</div>
|
||||
|
||||
## Architecture
|
||||
|
|
@ -32,12 +32,12 @@ This section lists some of the behaviors that candidates should display. Bear th
|
|||
- 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">
|
||||
<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
|
||||
Architecture/High-level design, Data model, Interface definition
|
||||
</div>
|
||||
|
||||
## Technical Proficiency
|
||||
## 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.
|
||||
|
|
@ -45,12 +45,12 @@ This section lists some of the behaviors that candidates should display. Bear th
|
|||
|
||||
_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">
|
||||
<div className="mt-6 space-x-1 space-y-1 text-sm">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Architecture/High-level Design, Optimizations and Deep Dive
|
||||
Architecture / High-level design, Optimizations and deep dive
|
||||
</div>
|
||||
|
||||
## Exploration and Tradeoffs
|
||||
## 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.
|
||||
|
|
@ -59,36 +59,36 @@ _Front end domain areas include Performance, Networking, HTML/CSS, Accessibility
|
|||
- 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">
|
||||
<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
|
||||
## Product and UX sense
|
||||
|
||||
Relevant framework sections: **Optimizations and Deep Dive**
|
||||
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">
|
||||
<div className="mt-6 space-x-1 space-y-1 text-sm">
|
||||
<strong className="font-medium">Relevant framework sections:</strong>
|
||||
Optimizations and Deep Dive
|
||||
Optimizations and deep dive
|
||||
</div>
|
||||
|
||||
## Communication and Collaboration
|
||||
## 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">
|
||||
<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
|
||||
|
|
@ -97,9 +97,9 @@ Here's a table summarizing how the evaluation axes can be mapped to the various
|
|||
|
||||
| Axis | R | A | D | I | O |
|
||||
| ------------------------------- | :-: | :-: | :-: | :-: | :-: |
|
||||
| Problem Exploration | ✅ | - | - | - | - |
|
||||
| Problem exploration | ✅ | - | - | - | - |
|
||||
| Architecture | - | ✅ | ✅ | ✅ | - |
|
||||
| Technical Proficiency | - | ✅ | - | - | ✅ |
|
||||
| Exploration and Tradeoffs | - | ✅ | ✅ | ✅ | ✅ |
|
||||
| Product and UX Sense | - | - | - | - | ✅ |
|
||||
| Communication and Collaboration | ✅ | ✅ | ✅ | ✅ | ✅ |
|
||||
| Technical proficiency | - | ✅ | - | - | ✅ |
|
||||
| Exploration and tradeoffs | - | ✅ | ✅ | ✅ | ✅ |
|
||||
| Product and UX sense | - | - | - | - | ✅ |
|
||||
| Communication and collaboration | ✅ | ✅ | ✅ | ✅ | ✅ |
|
||||
|
|
|
|||
|
|
@ -12,17 +12,17 @@ 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**: 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
|
||||
## 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.
|
||||
**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!
|
||||
|
||||
|
|
@ -71,11 +71,11 @@ You are recommended to write down the agreed requirements somewhere so that you
|
|||
|
||||
---
|
||||
|
||||
## Architecture/High-level Design
|
||||
## 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.
|
||||
**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.
|
||||
|
||||
|
|
@ -86,7 +86,7 @@ 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 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:
|
||||
|
||||
|
|
@ -97,38 +97,38 @@ It is important to realize that not every common component mentioned above will
|
|||
|
||||
After drawing out the architecture diagram, verbally describe the responsibilities of each component (box in the diagram).
|
||||
|
||||
### Architecture Example
|
||||
### Architecture example
|
||||
|
||||
Here's an example architecture diagram for the [News Feed](/questions/system-design/news-feed-facebook) question drawn using Excalidraw.
|
||||
|
||||
|
||||
|
||||
#### Component Responsibilities
|
||||
#### 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.
|
||||
- **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.
|
||||
- **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
|
||||
## 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.
|
||||
**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
|
||||
### 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
|
||||
|
||||
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:
|
||||
|
||||
|
|
@ -137,11 +137,11 @@ Client-only data, also commonly known as state, is data that only needs to live
|
|||
|
||||
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
|
||||
### 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 |
|
||||
| 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) |
|
||||
|
|
@ -154,23 +154,23 @@ You might want to write these fields near the components which owns them in your
|
|||
|
||||
---
|
||||
|
||||
## Interface Definition (API)
|
||||
## 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.
|
||||
**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 |
|
||||
| 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
|
||||
### 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.
|
||||
Using the [News Feed system design](/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 |
|
||||
| ----------- | ------------------------------------ |
|
||||
|
|
@ -217,28 +217,28 @@ A feed response is a paginated list so the API expects pagination parameters.
|
|||
}
|
||||
```
|
||||
|
||||
### Client-Client API Example
|
||||
### Client-elient 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
|
||||
### 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
|
||||
## 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.
|
||||
**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
|
||||
### 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).
|
||||
|
||||
|
|
@ -256,10 +256,10 @@ Refer to our [Best Practices for Building User Interfaces Guide](/front-end-inte
|
|||
|
||||
## Summary
|
||||
|
||||
| Step | Objective | Recommended Duration |
|
||||
| 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% |
|
||||
| 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 (API) | 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% |
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Introduction to Front End System Design
|
||||
title: 'Front End System Design: An Introduction'
|
||||
description: Learn useful techniques and how to approach top front end system design questions. Written by ex-interviewers at FAANG.
|
||||
seo_title: Front End System Design Guide | GreatFrontEnd
|
||||
social_title: Front End System Design Guide | GreatFrontEnd
|
||||
|
|
@ -12,37 +12,39 @@ System design interviews are usually given to candidates who have some number of
|
|||
|
||||
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!
|
||||
GreatFrontEnd's front end system design resources are perhaps the most comprehensive you can find and will help you ace your front end system design interviews with ease!
|
||||
|
||||
## Front End vs Back End System Design
|
||||
{/* TODO: Add some testimonials regarding front 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.
|
||||
## 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 |
|
||||
| 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) |
|
||||
| Data Model | SQL Schema | Application state |
|
||||
| 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 |
|
||||
| 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?
|
||||
- **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.
|
||||
|
||||
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.
|
||||
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.
|
||||
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 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)
|
||||
- [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.
|
||||
|
|
|
|||
|
|
@ -27,8 +27,6 @@ Nas entrevistas tradicionais de design de sistemas para Engenheiros de Software,
|
|||
| Áreas de foco | Escalabilidade, Confiabilidade, Disponibilidade | Desempenho, Experiência do Usuário, Acessibilidade, Internacionalização |
|
||||
| Menos importante (pode ser tratado como uma caixa-preta) | Cliente | Servidor |
|
||||
|
||||
Leia mais sobre as diferenças entre as entrevistas de Design de Sistema de Front End e Back End no blog de Zhenghao em (https://www.zhenghao.io/posts/system-design-interviews)
|
||||
|
||||
Por exemplo, uma pergunta clássica é pedir para projetar uma interface de feed do Twitter, que pode ser feita tanto em entrevistas de sistemas de back end quanto de front end.
|
||||
|
||||
- Back end: Estimativa de capacidade, projeto dos esquemas do banco de dados, como garantir que os serviços possam escalar com o tráfego, como gerar o feed do Twitter de um usuário?
|
||||
|
|
|
|||
|
|
@ -27,11 +27,11 @@ Here's a list of application questions commonly asked during front end system de
|
|||
| [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](/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 | Google Docs, Google Sheets, Google Slides, Notion | Real-time collaboration, State syncing |
|
||||
| Drawing | Figma, Lucidchart | Rendering approach, Client state/data model |
|
||||
| [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 |
|
||||
| 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 |
|
||||
|
|
@ -39,7 +39,7 @@ Here's a list of application questions commonly asked during front end system de
|
|||
| Music Streaming | Spotify, Apple Music | Music player UI, Playlists UI |
|
||||
| Games | Tetris, Snake | Game state, Game loop, Game logic |
|
||||
|
||||
## UI Components
|
||||
## 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.
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ You might have to write a small amount code for one or more of the following pur
|
|||
</ImageCarousel>
|
||||
```
|
||||
|
||||
### Customizing Theming
|
||||
### 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.
|
||||
|
||||
|
|
@ -77,10 +77,11 @@ Examples of UI components asked during front end system design interviews:
|
|||
- 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 [rich text editor](/questions/system-design/rich-text-editor)
|
||||
- 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.
|
||||
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 Front End system design interview questions.
|
||||
|
|
|
|||
Loading…
Reference in New Issue