i18n: sync
This commit is contained in:
Yangshun
parent
7ccd8e31af
commit
b68cc6075f
|
|
@ -2,4 +2,4 @@
|
|||
title: Descreva a propagação de eventos
|
||||
---
|
||||
|
||||
Quando um evento é disparado em um elemento do DOM, ele tentará manipular o evento se houver um ouvinte anexado, então o evento é propagado para seu pai e a mesma coisa acontece. Essa propagação ocorre pelos ancestrais do elemento até o `document`. A propagação de eventos é o mecanismo por trás da delegação de eventos.
|
||||
Quando um evento é disparado em um elemento do DOM, ele tentará manipular o evento se houver um ouvinte anexado, então o evento é propagado para seu pai e a mesma coisa acontece. Essa propagação ocorre pelos ancestrais do elemento até o `document`. A propagação de eventos é o mecanismo por trás da delegação de eventos. To prevent event bubbling, you can use `event.stopPropagation()`.
|
||||
|
|
|
|||
|
|
@ -2,4 +2,4 @@
|
|||
title: 描述事件冒泡过程
|
||||
---
|
||||
|
||||
当事件触发 DOM 元素时，如果有监听器，它会尝试处理事件， 然后事件会向上冒泡并发生同样的事件。 这种冒泡发生在元素的祖先上，一直到`document`。 事件冒泡是活动授权背后的机制。
|
||||
当事件触发 DOM 元素时，如果有监听器，它会尝试处理事件， 然后事件会向上冒泡并发生同样的事件。 这种冒泡发生在元素的祖先上，一直到`document`。 事件冒泡是活动授权背后的机制。 To prevent event bubbling, you can use `event.stopPropagation()`.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,13 @@
|
|||
---
|
||||
title: Descreva a diferença entre um cookie, `sessionStorage` e `localStorage`.
|
||||
title: Descreva a diferença entre cookie, `sessionStorage` e `localStorage`.
|
||||
---
|
||||
|
||||
Local storage is useful for storing data that the user will need to access later, such as offline data, because it stores the data in the browser and the system. This data will persist even if the user closes and reopens the browser and is accessible by other sites.
|
||||
|
||||
Session storage is a great way to improve the performance of your web applications. It stores data locally on the browser but is specific to (and only accessible by) the respective site/browser tab and is only available while the user is on the site/tab. This is a more secure storage method due to the restrictive access and promotes better site performance due to reduced data transfer between server and client.
|
||||
|
||||
Cookies are a good choice for storing data that should not be persisted for a long time, such as session IDs. Cookies allow you to set an expiry time at which point it would be deleted. Cookies can only be smaller sized data compared to the other two storage methods.
|
||||
|
||||
## Similaridades
|
||||
|
||||
Cookies, `localStorage`, and `sessionStorage`, são todos:
|
||||
|
|
|
|||
|
|
@ -2,13 +2,19 @@
|
|||
title: 描述cookie、 `sessionStorage` 和 `localStorage` 之间的差异。
|
||||
---
|
||||
|
||||
Local storage is useful for storing data that the user will need to access later, such as offline data, because it stores the data in the browser and the system. This data will persist even if the user closes and reopens the browser and is accessible by other sites.
|
||||
|
||||
Session storage is a great way to improve the performance of your web applications. It stores data locally on the browser but is specific to (and only accessible by) the respective site/browser tab and is only available while the user is on the site/tab. This is a more secure storage method due to the restrictive access and promotes better site performance due to reduced data transfer between server and client.
|
||||
|
||||
Cookies are a good choice for storing data that should not be persisted for a long time, such as session IDs. Cookies allow you to set an expiry time at which point it would be deleted. Cookies can only be smaller sized data compared to the other two storage methods.
|
||||
|
||||
## 相似性
|
||||
|
||||
Cookies、`localStorage`和`sessionStorage`都是:
|
||||
|
||||
- 客户端的存储机制。 这意味着客户端可以阅读和修改这些值。
|
||||
- 基于键值的存储。
|
||||
- 他们只能存储作为字符串的值。 对象必须序列化为字符串 (`JSONstringify()`) 才能存储。
|
||||
- 他们只能存储作为字符串的值。 对象必须序列化为字符串 (`JSON.stringify()`) 才能存储。
|
||||
|
||||
## 差异
|
||||
|
||||
|
|
|
|||
|
|
@ -2,12 +2,12 @@
|
|||
title: Descreva o que você gosta e não gosta sobre os pré-processadores CSS que você usou.
|
||||
---
|
||||
|
||||
## Curtidas
|
||||
## Gostei
|
||||
|
||||
- A maioria das vantagens mencionadas em ["Quais são as vantagens/desvantagens de usar pré-processadores CSS?"](/questions/quiz/what-are-the-advantages-disadvantages-of-using-css-preprocessors).
|
||||
- Less é escrito em JavaScript, o que o torna compatível com o Node.
|
||||
|
||||
## Dislikes
|
||||
## Não gostei
|
||||
|
||||
- Sass depende de `node-sass`, que é um vínculo para o LibSass escrito em C++. A biblioteca tem que ser recalculada com frequência quando estiver mudando entre as versões do Node.js.
|
||||
- No Less, os nomes de variáveis são prefixados com `@`, o que pode ser confundido com palavras-chave nativas do CSS, como a regra `@media`, `@import` e `@font-face`.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: Explique como `this` funciona em JavaScript
|
||||
---
|
||||
|
||||
Não há uma explicação simples para `this`; ela é um dos conceitos mais confusos do JavaScript. Uma explicação superficial é que o valor do `this` depende de como a função é chamada. Tendo lido muitas explicações sobre `this` online, [Arnav Aggrawal](https://medium.com/@arnav_aggarwal)" a explicação foi mais clara. As seguintes regras se aplicam:
|
||||
Não há uma explicação simples para `this`; ela é um dos conceitos mais confusos do JavaScript. Uma explicação superficial é que o valor do `this` depende de como a função é chamada. Tendo lido muitas explicações sobre `this` online, [Arnav Aggrawal](https://medium.com/@arnav_aggarwal) é a explicação que foi mais clara. As seguintes regras se aplicam:
|
||||
|
||||
1. Se a palavra-chave `new` é usada ao chamar a função, `new` dentro da função é um objeto totalmente novo.
|
||||
2. Se `apply`, `call`, ou `bind` forem usados para chamar/criar uma função, `this` dentro da função é o objeto passado como o argumento.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: Como você pode compartilhar código entre arquivos?
|
||||
---
|
||||
|
||||
This depends on the JavaScript environment.
|
||||
Isto depende do ambiente JavaScript.
|
||||
|
||||
No cliente (ambiente do navegador), desde que as variáveis/funções sejam declaradas no escopo global (`window`), todos os scripts podem se referir a elas. Alternativamente, adote a Definição de Módulo Assíncrono (AMD) por meio do RequireJS para uma abordagem mais modular.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,4 +6,4 @@ Primeiramente, entenda que os navegadores combinam seletores da direita (seletor
|
|||
|
||||
A metodologia [BEM (Block Element Modifier)](https://bem.info/) recomenda que tudo tenha uma única classe e, quando você precisa de hierarquia, que isso seja incorporado ao nome da classe também, o que naturalmente torna o seletor eficiente e fácil de substituir.
|
||||
|
||||
Esteja ciente de quais propriedades CSS [trigger](https://csstriggers.com/) reflow, repaint, e compostagem. Evite escrever estilos que alteram o layout (fator reflow) quando possível.
|
||||
Esteja ciente de quais propriedades CSS [trigger](https://csstriggers.com/) reflow, repaint, e compositing. Evite escrever estilos que alteram o layout (fator reflow) quando possível.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ title: Quais são as vantagens e desvantagens de usar o Ajax?
|
|||
|
||||
- Melhor interatividade. O novo conteúdo do servidor pode ser alterado dinamicamente sem a necessidade de recarregar a página inteira.
|
||||
- Reduzir conexões para o servidor, pois scripts e folhas de estilo só precisam ser solicitados uma vez.
|
||||
- O State pode ser mantida em uma página. As variáveis do JavaScript e o estado do DOM persistirão porque a página principal do contêiner não foi recarregada.
|
||||
- O State pode ser mantido em uma página. As variáveis do JavaScript e o estado do DOM persistirão porque a página principal do contêiner não foi recarregada.
|
||||
- Basicamente, a maioria das vantagens de um SPA.
|
||||
|
||||
## Desvantagens
|
||||
|
|
|
|||
|
|
@ -76,4 +76,4 @@ baz = 'qux';
|
|||
|
||||
## Notas
|
||||
|
||||
- Como a maioria dos navegadores suportam `let` e `const` atualmente, usar `var` não é mais recomendado. Se você precisa atingir navegadores mais antigos, escreva seu código usando `let` e use um transpiler como o Babel para compilar seu código para uma sintaxe mais antiga.
|
||||
- Como a maioria dos navegadores suportam `let` e `const` atualmente, usar `var` não é mais recomendado. Se você precisa dar suporte a navegadores mais antigos, escreva seu código usando `let` e use um transpiler como o Babel para compilar seu código para uma sintaxe mais antiga.
|
||||
|
|
|
|||
|
|
@ -2,8 +2,8 @@
|
|||
title: Quais são as várias técnicas de limpeza e qual é apropriada para qual contexto?
|
||||
---
|
||||
|
||||
- Método do `div`vazio: `<div style="clear:both;"></div>`.
|
||||
- Método do `div` vazio: `<div style="clear:both;"></div>`.
|
||||
- Método de Clearfix: Consulte a classe `.clearfix` mencionada anteriormente.
|
||||
- Método`overflow: auto` ou `overflow: hidden`: O pai estabelecerá um novo contexto de formatação em bloco e se expandirá para conter seus filhos flutuantes.
|
||||
- Método `overflow: auto` ou `overflow: hidden`: O pai estabelecerá um novo contexto de formatação em bloco e se expandirá para conter seus filhos flutuantes.
|
||||
|
||||
Em projetos grandes, ter uma classe utilitária `.clearfix` será muito útil. `overflow: hidden` pode cortar os filhos se eles forem mais altos que o pai, e isso não é muito ideal.
|
||||
|
|
|
|||
|
|
@ -4,8 +4,8 @@ title: O que um `DOCTYPE` faz?
|
|||
|
||||
**DOCTYPE** é uma abreviação para **Tipo de Documento**. Um DOCTYPE sempre está associado a um **DTD** - para **Definição de Tipo de Documento**.
|
||||
|
||||
Um DTD define como documentos de um determinado tipo devem ser estruturados (por exemplo, um `button` pode conter um `span` mas não um `div`), ao passo que um DOCTYPE declara o que DTD um documento _supostamente_ respeita (ex.: este documento respeita o HTML DTD).
|
||||
Um DTD define como documentos de um determinado tipo devem ser estruturados (por exemplo, um `button` pode conter um `span` mas não uma `div`), ao passo que um DOCTYPE declara o que DTD um documento _supostamente_ respeita (ex.: este documento respeita o HTML DTD).
|
||||
|
||||
Para páginas web, a declaração DOCTYPE é necessária. É usado para dizer aos agentes do usuário qual versão das especificações HTML o seu documento respeita. Uma vez que um agente de usuário tenha reconhecido um DOCTYPE correto, ele acionará o **modo no-quirk** correspondente a este DOCTYPE para ler o documento. Se um agente de usuário não reconhecer um DOCTYPE correto, ele ativará o **modo de peculiaridade** (quirks mode).
|
||||
Para páginas web, a declaração DOCTYPE é necessária. É usado para dizer aos agentes do usuário qual versão das especificações HTML o seu documento respeita. Uma vez que um agente de usuário tenha reconhecido um DOCTYPE correto, ele acionará o **modo no-quirk** correspondente a este DOCTYPE para ler o documento. Se um agente de usuário não reconhecer um DOCTYPE correto, ele ativará o **quirks mode** (modo de peculiaridade).
|
||||
|
||||
A declaração DOCTYPE para os padrões HTML5 é `<!DOCTYPE html>`.
|
||||
|
|
|
|||
|
|
@ -24,5 +24,5 @@ Liberando partes do HTML para o navegador, à medida que a página é construíd
|
|||
## Outras técnicas modernas
|
||||
|
||||
- [Progressive hydration](https://www.patterns.dev/posts/progressive-hydration/)
|
||||
- [Renderização do servidor de streaming](https://www.patterns.dev/posts/ssr/)
|
||||
- [Streaming server-side rendering](https://www.patterns.dev/posts/server-side-rendering/)
|
||||
- [Hydratação seletiva](https://www.patterns.dev/posts/react-selective-hydration/)
|
||||
|
|
|
|||
|
|
@ -24,5 +24,5 @@ title: 什么是渐进式渲染？
|
|||
## 其他现代技术
|
||||
|
||||
- [渐进式水合](https://www.patterns.dev/posts/progressive-hydration/)
|
||||
- [流式SSR](https://www.patterns.dev/posts/ssr/)
|
||||
- [Streaming server-side rendering](https://www.patterns.dev/posts/server-side-rendering/)
|
||||
- [选择性水合](https://www.patterns.dev/posts/react-selective-hydration/)
|
||||
|
|
|
|||
|
|
@ -2,6 +2,6 @@
|
|||
title: Qual é a extensão da sua experiência com Promises e/ou seus polyfills?
|
||||
---
|
||||
|
||||
Eu tenho conhecimento prático sobre Promises e seus polyfills. Uma promise é um objeto que pode produzir um único valor em algum momento futuro: seja um valor resolvido ou uma razão pela qual não foi resolvido (por exemplo, ocorreu um erro de rede). Uma promise pode estar em um dos 3 estados possíveis: resolvida, rejeitada ou pendente. Usuários de Promise podem anexar callbacks para lidar com o valor cumprido ou o motivo da rejeição.
|
||||
Eu tenho conhecimento prático sobre Promises e seus polyfills. Uma promise é um objeto que pode produzir um único valor em algum momento futuro: seja um valor resolvido ou uma razão pela qual não foi resolvido (por exemplo, ocorreu um erro de rede). Uma promise pode estar em um dos 3 estados possíveis: resolvida, rejeitada ou pendente. Usuários de Promise podem anexar callbacks para lidar com o valor resolvido ou o motivo da rejeição.
|
||||
|
||||
Alguns polyfills comuns são `$.deferred`, Q e Bluebird, mas nem todos eles estão em conformidade com a especificação. O ES2015 suporta Promises nativamente e geralmente não são necessários polyfills nos dias de hoje.
|
||||
|
|
|
|||
|
|
@ -8,6 +8,6 @@ title: Quais ferramentas e técnicas você usa para depurar o código JavaScript
|
|||
- Depuração tradicional com `console.log()`
|
||||
- React e Redux
|
||||
- [React Devtools](https://github.com/facebook/react-devtools)
|
||||
- [React Devtools](https://github.com/gaearon/redux-devtools)
|
||||
- [Redux Devtools](https://github.com/gaearon/redux-devtools)
|
||||
- Vue
|
||||
- [React Devtools](https://github.com/vuejs/vue-devtools)
|
||||
- [Vue Devtools](https://github.com/vuejs/vue-devtools)
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Por que você usaria algo como o evento `load`?
|
||||
subtitle: Este evento tem desvantagens? Você conhece alguma alternativa, e por que usaria essas?
|
||||
subtitle: Este evento tem desvantagens? Você conhece alguma alternativa, e por que as usaria?
|
||||
---
|
||||
|
||||
O evento `load` dispara no final do processo de carregamento de documentos. Neste ponto, todos os objetos no documento estão no DOM, e todas as imagens, scripts, links e sub-frames terminaram de carregar.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
2. **Architecture/High-level Design**: Identify the key components of the product and how they are related to each other.
|
||||
3. **Data Model**: Describe the various data entities, the fields they contain and which component(s) they belong to.
|
||||
4. **Interface Definition (API)**: Define the interface (API) between components in the product, functionality of each APIs, their parameters and responses.
|
||||
5. **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.
|
||||
2. **Architecture**: Broke down the problem into smaller independent parts, defined their responsibilities and how these components can work together.
|
||||
3. **Technical Proficiency**: Demonstrated technical knowledge and proficiency of front end domain fundamentals (e.g. performance, networking, accessibility, i18n, security, etc), relevant technologies and APIs.
|
||||
4. **Exploration and Tradeoffs**: Suggested various possible approaches on how to achieve certain functionality, explained the pros and cons and made recommendations.
|
||||
5. **Product and UX Sense**: Showed consideration for user experience and decisions to make the product a great one.
|
||||
6. **Communication and Collaboration**: Conveyed thoughts and ideas clearly and concisely, receptive to feedback and collaborated with the interviewer.
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
- Responder imediatamente à pergunta sem primeiro fazer perguntas e obter requisitos.
|
||||
- Abordar a pergunta de maneira desestruturada, indo em várias direções e deixando de abordar áreas importantes.
|
||||
- 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,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.
|
||||
2. **Architecture/High-level Design**: Identify the key components of the product and how they are related to each other.
|
||||
3. **Data Model**: Describe the various data entities, the fields they contain and which component(s) they belong to.
|
||||
4. **Interface Definition (API)**: Define the interface (API) between components in the product, functionality of each APIs, their parameters and responses.
|
||||
5. **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.
|
||||
2. **Architecture**: Broke down the problem into smaller independent parts, defined their responsibilities and how these components can work together.
|
||||
3. **Technical Proficiency**: Demonstrated technical knowledge and proficiency of front end domain fundamentals (e.g. performance, networking, accessibility, i18n, security, etc), relevant technologies and APIs.
|
||||
4. **Exploration and Tradeoffs**: Suggested various possible approaches on how to achieve certain functionality, explained the pros and cons and made recommendations.
|
||||
5. **Product and UX Sense**: Showed consideration for user experience and decisions to make the product a great one.
|
||||
6. **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: Erros Comuns Cometidos Durante Entrevistas de Design de Sistemas Front End
|
||||
seo_title: Armadilhas Comuns a Evitar em Entrevistas de Design de Sistemas Front-End
|
||||
description: 6 erros comuns que você deve evitar durante entrevistas de design de sistemas front-end.
|
||||
seo_description: 6 erros comuns que você deve evitar durante entrevistas de design de sistemas front-end.
|
||||
---
|
||||
|
||||
Ao contrário das entrevistas de codificação, que são muito mais comuns e nas quais é possível praticar e simular as condições da entrevista, é muito mais difícil praticar para entrevistas de design de sistemas.
|
||||
|
||||
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,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,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.
|
||||
2. **Architecture/High-level Design**: Identify the key components of the product and how they are related to each other.
|
||||
3. **Data Model**: Describe the various data entities, the fields they contain and which component(s) they belong to.
|
||||
4. **Interface Definition (API)**: Define the interface (API) between components in the product, functionality of each API, their parameters and responses.
|
||||
5. **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).
|
||||
2. 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,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.
|
||||
2. **Architecture/High-level Design**: Identify the key components of the product and how they are related to each other.
|
||||
3. **Data Model**: Describe the various data entities, the fields they contain and which component(s) they belong to.
|
||||
4. **Interface Definition (API)**: Define the interface (API) between components in the product, functionality of each API, their parameters and responses.
|
||||
5. **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).
|
||||
2. 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 | Obrigatório | Obrigatório |
|
||||
| Architecture/High-level design | Distributed cloud services | Application/Component |
|
||||
| Back-of-the-envelope estimation | Obrigatório | Não obrigatório |
|
||||
| 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) | Cliente | Servidor |
|
||||
|
||||
_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,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.
|
||||
|
||||
## Aplicações
|
||||
|
||||
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.
|
||||
|
||||
### Exemplos
|
||||
|
||||
Here's a list of application questions commonly asked during front end system design interviews and the areas you should focus on:
|
||||
|
||||
| Aplicação | Exemplos | 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, |
|
||||
| Streaming de Vídeo | 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 | Reserva de percurso, local do motorista |
|
||||
| Streaming de Música | Spotify, Apple Music | Music player UI, Playlists UI |
|
||||
| Jogos | 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.
|
||||
2. Describe the shape of the component state.
|
||||
3. 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.
|
||||
|
|
@ -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.
|
||||
2. Describe the shape of the component state.
|
||||
3. 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