mirror
/
front-end-interview-handbook
mirror of https://github.com/yangshun/front-end-interview-handbook.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

guides(feig): open source

This commit is contained in:
Yangshun 2023-05-31 14:04:23 +08:00
parent 41e4d2e799
commit a7dfb14147
11 changed files with 1281 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

118
packages/front-end-interview-guidebook/contents/algorithms/en-US.mdx Normal file
View File

@ -0,0 +1,118 @@
---
title: Front End Interview Algorithmic Coding Questions — How to Prepare
description: Guide to preparing for algorithmic coding questions in front end / web developer interviews — Concepts to know, interview rubrics, and important practice questions.
---
Algorithmic coding questions are exactly the questions you can find on LeetCode. Algorithmic questions usually have the following traits:
- They aren't specific to the front end domain; they can be solved in most mainstream programming languages.
- Usually accompanied with impractical scenarios. You would not have encountered such a problem during real world development. Who ever had to flip a binary tree or count the number of palindromic substrings in a string?
- Efficiency of the code (time and space complexity) is important and producing the most efficient solution requires solid knowledge of data structures and algorithms.
Although algorithmic coding questions aren't specific to front end, the skills needed to excel in these questions — strong analytical thinking, effective communication, a solid grasp of the common data structures and algorithms, good code hygiene, are still crucial skills good Front End Engineers should possess. Good Front End Engineers are also good Software Engineers and good Software Engineers should have mastery over basic DSA. Hence it's no surprise that many companies still ask algorithmic coding questions during the interview process. Familiarity with data structures and algorithms is also helpful for solving JavaScript coding questions and User Interface coding questions.
There are a ton of resources out there that cover algorithmic coding interviews and since they are not specific to front end, we won't go into too much detail on this page. We recommend referring to [Tech Interview Handbook](https://www.techinterviewhandbook.org) as a free resource if you would like to learn more about algorithmic coding interviews.
## Examples
- Reverse a linked list.
- Determine if a string contains balanced brackets.
- Determine how many substrings in a string are palindromes.
## How to Prepare
1. Pick a good programming language to use. If you want to save preparation time you should probably stick with JavaScript for algorithmic questions, although note that the JavaScript language doesn't contain certain common useful data structures and algorithms whereas other languages like Python, Java, and C++ do. Personally I use Python for solving algorithmic interview questions.
1. Plan your time and tackle topics and questions in order of importance.
1. Combine studying and practicing for a single topic.
1. Accompany practice with coding interview cheat sheets to internalize the must-dos and must-remembers.
Refer to [Tech Interview Handbook's step-by-step guide on how to prepare for algorithmic coding interviews](https://www.techinterviewhandbook.org/coding-interview-prep/).
## Important Concepts
Although you can still be asked any algorithmic question, companies tend to go easier on Front End Engineer candidates and probably will not ask questions involving hard topics like dynamic programming or complex graph algorithms.
Since the DOM is a tree, prioritize learning about trees and the various tree traversal algorithms.
| Category | Important Topics |
| --- | --- |
| Data Structures | Arrays, Maps, Stacks, Trees, Graphs, Matrix (2D Arrays), Sets |
| Algorithms | Binary Search, Breadth-first Search, Depth-first Search, Topological Sorting, Recursion |
## Common JavaScript Operations
### `Array`
| Operation | Time Complexity |
| --------------------------- | --------------- |
| `Array.prototype.concat()` | O(m + n) |
| `Array.prototype.every()` | O(n) |
| `Array.prototype.fill()` | O(n) |
| `Array.prototype.filter()` | O(n) |
| `Array.prototype.find()` | O(n) |
| `Array.prototype.pop()` | O(1) |
| `Array.prototype.push()` | O(1) |
| `Array.prototype.reduce()` | O(n) |
| `Array.prototype.reverse()` | O(n) |
| `Array.prototype.shift()` | O(n) |
| `Array.prototype.slice()` | O(n) |
| `Array.prototype.some()` | O(n) |
| `Array.prototype.sort()` | O(nlgn) |
| `Array.prototype.splice()` | O(n) |
| `Array.prototype.unshift()` | O(m + n) |
<sup>*</sup> `n` is the number of elements in the array and `m`` is the number of
elements to be added.
### `Map`
| Operation | Time Complexity |
| --- | --- |
| `Map.prototype.clear()` | O(n) |
| `Map.prototype.delete()` | O(1) |
| `Map.prototype.entries()` | O(1) because it returns an iterator. Getting all the entries will take O(n) time. |
| `Map.prototype.forEach()` | O(n) |
| `Map.prototype.get()` | O(1) |
| `Map.prototype.has()` | O(1) |
| `Map.prototype.keys()` | O(1) because it returns an iterator. Getting all the keys will take O(n) time. |
| `Map.prototype.set()` | O(1) |
| `Map.prototype.values()` | O(1) because it returns an iterator. Getting all the values will take O(n) time. |
<sup>*</sup> `n` is the number of keys in the map.
### `Set`
| Operation | Time Complexity |
| --- | --- |
| `Set.prototype.add()` | O(1) |
| `Set.prototype.clear()` | O(n) |
| `Set.prototype.delete()` | O(1) |
| `Set.prototype.entries()` | O(1) because it returns an iterator. Getting all the entries will take O(n) time. |
| `Set.prototype.forEach()` | O(n) |
| `Set.prototype.has()` | O(1) |
| `Set.prototype.keys()` | O(1) because it returns an iterator. Getting all the keys will take O(n) time. |
| `Set.prototype.values()` | O(1) because it returns an iterator. Getting all the values will take O(n) time. |
<sup>*</sup> `n` is the number of elements in the set.
## Algorithmic Coding Interview Rubrics
During algorithmic coding interviews, interviewers are evaluating candidates on the following skills:
- **Problem Solving**: Use a systematic and logical approach to understanding and addressing a problem. Break down the problem into smaller independent problems. Evaluate different approaches and their tradeoffs.
- **Technical Competence**: Ability to translate solutions into working code and demonstrating a strong understanding of the language being used.
- **Communication**: Ask questions to clarify details and clearly explain one's approach and considerations.
- **Verification**: Identify various scenarios to test the code against, including edge cases. Be able to diagnose and fix any issues that arise.
## Useful Tips
- **Wishful thinking**. JavaScript's standard library doesn't have some useful data structures and algorithms like queue, heap, binary search, which can make your life easier during JavaScript coding interviews. However, you can ask the interviewer if you can pretend such a data structure/algorithm exists and use it directly in your solution without implementing it.
- **Pure functions**. Aim to write pure functions which have the benefit of reusability and modularity, aka functions which don't rely on state outside of the function and doesn't cause side effects.
- **Choose data structures wisely.** Pay attention to your choice of data structures and be aware of the time complexities of the code. Be familiar with the time/space complexities of the basic JavaScript Array, Object, Set, Map operations should you want to use them in your solution. Some of these time/space complexities differ across languages. Don't write code that runs in O(n<sup>2</sup>) if it can accomplished in O(n) runtime with the use of hash maps.
- **Recursion edge cases**.
- If you have identified that solving the question requires recursion, ask about the input size and how to handle the case of recursion stack overflow. Usually you won't have to handle it but raising this issue is a good signal.
- Nested deep data structures can have recursive references to itself, which makes certain operations like serialization much trickier. Ask the interviewer if you have to handle such cases. Usually you won't have to handle it but raising this issue is a good signal.
## Practice Questions
Currently the best platform to practice algorithmic questions is undeniably LeetCode. However, GreatFrontEnd provides some [practice questions for Data Structures and Algorithms](/questions/js/coding/data-structures-algorithms) where you can practice implementing common data structures ([Stack](/questions/javascript/stack), [Queue](/questions/javascript/queue)) and algorithms ([Binary Search](/questions/javascript/binary-search), [Merge Sort](/questions/javascript/merge-sort)), etc in JavaScript.

72
packages/front-end-interview-guidebook/contents/coding/en-US.mdx Normal file
View File

@ -0,0 +1,72 @@
---
title: Front End Interview Coding Questions — How to Prepare
description: Guide to preparing for coding questions in front end / web developer interviews — What to expect, coding tips, and 100+ important practice questions.
---
Coding interviews is the primary way in which Front End Engineers are being evaluated and can span across multiple rounds and stages of the interviews, hence it is super important to practice for coding interviews. To recap, here are the three types of coding questions you can be asked:
- **Algorithmic Coding**: Solve tricky algorithmic questions that evaluates your understanding of data structures, algorithms and time complexity.
- **JavaScript Coding**: Implement functions or data structures in JavaScript that are related to front end domain and commonly used during front end development.
- **User Interface Coding**: Build user interfaces (components, widgets, apps) using HTML, CSS, and JavaScript, sometimes even using JavaScript frameworks.
## Coding Environment
You could be asked to complete a question by coding using one or more of the following environments:
### Online Basic Code Editor
You will be given a URL of an in-browser code editor. The editor either has real-time collaboration capabilities or you will be asked to share your screen. These basic code editors usually only have one pane because the question doesn't need using more than one language to complete, e.g. algorithmic/JavaScript coding questions. You may or may not be allowed to execute your code. An example of online basic code editors is [CoderPad](https://coderpad.io/).
### Integrated Development Environments (IDE)
The difference between basic code editor and IDEs is that IDEs allow toggling between multiple files. They can either be in-browser or native apps on your laptop. You will usually be asked to use IDEs when you have to build user interfaces and have to use multiple files or type in more than just a single language. This is the best environment available as it closely resembles how most engineers develop. Subject to interviewer approval, you should be able to:
- Preview the in-progress UI and see updates live.
- Use the browser console for debugging.
- Use IDE features like syntax highlighting, keyboard shortcuts, autocomplete, intellisense, extensions to boost your productivity.
- Add any necessary 3rd party dependencies.
Always choose to use an IDE if you are given a choice.
Examples of online IDEs include [JSFiddle](https://jsfiddle.net/), [CodePen](https://codepen.io/), [CodeSandbox](https://codesandbox.io/), and [StackBlitz](https://stackblitz.com/).
### Whiteboard
At certain companies, you could be asked to write all required code on the whiteboard. Imagine writing HTML and CSS on the board without being able to preview it! This is a candidate's nightmare and big tech companies like Google and Meta/Facebook are known to do this during onsite interviews. Most other companies either get you to bring your own laptop and you code on your local IDE or an online code editor/IDE within a web browser.
---
Here's a summary of the various coding environments and what you can do:
| Environment | Preview | Execute Code | Add 3rd Party Dependencies |
| ------------------ | ------- | ------------ | -------------------------- |
| Online code editor | No | Situational | Usually no |
| IDEs | Yes | Yes | Yes |
| Whiteboard | No | No | No |
## General Coding Tips
- Be familiar with the useful editor keyboard shortcuts because time is of essence during interviews and every keystroke counts. Know how to:
- Jump to start/end of line.
- Shift lines up/down.
- Duplicate a line.
- Rename a symbol easily.
- Find out beforehand if you will be coding on your own laptop, a laptop given to you, or the whiteboard.
- If you will be coding on your own laptop and can use your own IDE, ensure that the IDE is functioning properly, Node.js and npm are installed correctly, and that you can run local web servers on `localhost` and access them within your browser.
- Do not be too reliant on preview and execution of code. This suggests to your interviewer that you aren't sure of what you typed and develop via trial-and-error, which is not a positive signal.
## Type-specific Tips
Read on for tips for each coding interview type:
- [Algorithmic Coding](/front-end-interview-guidebook/algorithms)
- [JavaScript Coding](/front-end-interview-guidebook/javascript)
- [User Interface Coding](/front-end-interview-guidebook/user-interface)
## Practice Questions
GreatFrontEnd has a long list of [coding questions](/prepare/coding) you can practice and you should definitely take the time to check them out.
Note that we are intentionally vague in some of the questions and don't present the full requirements in the question. This is to train you to think ahead and consider what possible things you have to take note of when working on the solution.
However, we'll cover as much ground as possible in the solution. It may be frustrating while reading the solutions to realize that you've missed out some stuff, but it's a learning experience with the ultimate goal of helping you improve. Better to learn during preparation than during actual interviews.

119
packages/front-end-interview-guidebook/contents/javascript/en-US.mdx Normal file
View File

@ -0,0 +1,119 @@
---
title: Front End Interview JavaScript Questions — How to Prepare
description: Guide to preparing for JavaScript questions in front end / web developer interviews — Concepts to know, interview rubrics, and 70+ important practice questions.
---
The difference between coding JavaScript coding questions vs algorithmic coding questions is that the former is usually specific to the front end domain and it makes the most sense to use JavaScript (or [TypeScript](https://www.typescriptlang.org/)) to complete them. You will also probably need to make use of browser/JavaScript-specific APIs and/or utilize HTML/CSS/JavaScript knowledge.
These JavaScript coding questions tend to be practical in nature and can come in one or more of the following categories:
1. Implement standard built-in classes or methods in the JavaScript language.
1. Implement a utility function/class commonly found in popular libraries.
## Examples
### JavaScript Standard Built-in Classes/methods
It may seem redundant to implement standard classes/methods when they are already part of the language. However, browsers inconsistencies used to be a rampant problem and some language APIs are not found in older browsers. Hence developers had to resort to polyfilling, the act of providing modern functionality on older browsers that do not natively support it by implementing these APIs in downloaded JavaScript. Being able to implement these native functions also shows good understanding of front end fundamentals.
- `Array` methods: [`Array.prototype.map`](/questions/javascript/array-map), [`Array.prototype.reduce`](/questions/javascript/array-reduce), [`Array.prototype.filter`](/questions/javascript/array-filter).
- `Promise` and other `Promise`-related functions: [`Promise.all`](/questions/javascript/promise-all), [`Promise.any`](/questions/javascript/promise-any).
- DOM methods: [`document.getElementsByTagName`](/questions/javascript/get-elements-by-tag-name), [`document.getElementsByClassName`](/questions/javascript/get-elements-by-class-name).
There's more to these functions than meets the eye. Let's take the innocent `Array.prototype.map` for example. Are you aware that:
1. It passes 4 arguments to the callback, including the `index` and `this`?
1. It keeps the "holes" in sparse arrays, aka `[1, 2, , 4].map(val => val * val) === [1, 4, , 16]`.
1. The range of elements processed by `map` is set before the first call to _callbackfn_. Elements which are appended to the array after the call to `map` begins will not be visited by _callbackfn_. If existing elements of the array are changed, their value as passed to _callbackfn_ will be the value at the time `map` visits them; elements that are deleted after the call to `map` begins and before being visited are not visited. Source: [`Array.prototype.map` ECMAScript specification](https://tc39.es/ecma262/multipage/indexed-collections.html#sec-array.prototype.map)
Your implementation doesn't have to handle all of these cases, especially the array mutation one. However, it's a positive signal if you mentioned these cases. The closer your implementation is to the specification, the more senior/experienced you will appear to be.
### Utility Function/Class from Popular Libraries
These functions/classes are commonly needed when building software with JavaScript but aren't in the standard language (for now).
- Lodash/Underscore functions: [`debounce`](/questions/javascript/debounce), [`throttle`](/questions/javascript/throttle), [`flatten`](/questions/javascript/flatten), [`curry`](/questions/javascript/curry), [`cloneDeep`](/questions/javascript/deep-clone).
- jQuery methods: [`jQuery.css`](/questions/javascript/jquery-css), [`jQuery.toggleClass`](/questions/javascript/jquery-class-manipulation).
- Popular libraries:
- [`classnames`](/questions/javascript/classnames)
- `test`/`expect` functions from testing frameworks like [Jest](https://jestjs.io/)/[Mocha](https://mochajs.org/)
- [`Emitter`](/questions/javascript/event-emitter) (which exists as part of Node.js and many third party libraries)
- [Immutable.js](https://immutable-js.com/)
- [Backbone.js](https://backbonejs.org/)
If you take a look at the source code of these libraries, you might find some of the implementation to be quite complex. This is because there are lots of obscure real world use cases that the library has to support. Similar to the standard functions, you're not expected to handle all of these edge cases within an interview setting but you get points for calling them out.
## What to do during JavaScript Coding Interviews
JavaScript coding interviews share a lot of similarities with algorithmic coding interviews. In general, you should:
1. Find out what platform you are coding on and familiarize yourself with the coding environment:
- The supported editor shortcuts.
- Whether you can execute code.
- Whether you can install 3rd party dependencies.
1. Make your self introduction under a minute. Unless requested, do not take longer than this otherwise you might not have enough time to code.
1. Ask clarifying questions upon receiving the question. Clarify the following:
- Can you use newer JavaScript syntax (ES2016 and beyond)?
- Whether the code is meant to run in the browser or on the server (e.g. Node.js).
- Browser support, as this will affect the browser APIs you can use.
1. Propose a solution to your interviewer. Unlike coding interviews, the focus of JavaScript coding interviews is usually not on complex data structures and algorithms. It's possible and likely you can jump straight to the optimal solution with the best choice of data structures and algorithms.
1. Code out your solution and explain your code to your interviewer while you are coding.
1. After coding, read through your code once and try to spot basic errors like typos, using variables before initializing them, using APIs incorrectly, etc.
1. Outline some basic test cases and some edge cases. Test your code with these cases and determine if your code passes them. If it fails, debug the issue(s) and fix them.
1. Optional: Explain the time/space complexity if the code involved algorithmic optimizations and smart choice of data structures.
1. Explain any tradeoffs you made, cases you explicitly didn't handle, and how you would improve the code if you had more time.
1. The interview might not end here, the interviewer might have follow-up questions for you on this question or give you another question. Be prepared for them.
## How to Prepare for JavaScript Coding Interviews
1. Be familiar with HTML, CSS, JavaScript, and DOM concepts by referring to the "Important Concepts" below. The [Quiz section](/front-end-interview-guidebook/quiz) can also be a good start since you might be asked on these concepts in the form of quiz questions during coding.
1. Pick a [study plan](/get-started) and practice the [JavaScript coding questions](/questions/js/coding/utilities) recommended for the selected study plan. It's also alright to study for a certain topic as you are doing the questions.
## Important Concepts
| Category | Important Topics |
| --- | --- |
| Data Structures | Arrays, Maps, Stacks, Trees, Sets |
| Algorithms | Binary Search, Breadth-first Search, Depth-first Search, Recursion |
| JavaScript Language | Data types (checking for types, type coercion), Scope, Closures, Callbacks, How `this` keyword works, Object-oriented Programming in JavaScript (prototypes, classes, methods), Arrow functions vs normal functions, Invoking functions via `Function.prototype.apply()`/`Function.prototype.call()`, `Promise`, Handling variadic arguments |
| DOM | DOM traversal, DOM creation, DOM manipulation, Accessing element/node properties, Event delegation |
| Runtime APIs | Timer (`setTimeout`, `setInterval`) |
## JavaScript Coding Interview Rubrics
JavaScript coding interviews are similar to algorithmic coding interviews and the way to go about the interviews should be similar. Naturally, there will be some overlaps with algorithmic coding interviews regarding how candidates are evaluated during JavaScript coding interviews.
- **Problem Solving**: Use a systematic and logical approach to understanding and addressing a problem. Break down the problem into smaller independent problems. Evaluate different approaches and their tradeoffs.
- **Software Engineering Foundation**: Familiarity with data structures, algorithms, runtime complexity analysis, use of design patterns, design solution with clean abstractions.
- **Domain Expertise**: Understanding of the front end domain and the relevant languages: Browser (DOM and DOM APIs), HTML, CSS, JavaScript, Performance.
- **Communication**: Ask questions to clarify details and clearly explaining one's approach and considerations.
- **Verification**: Identify various scenarios to test the code against, including edge cases. Be able to diagnose and fix any issues that arise.
## Useful Tips
- **Wishful thinking**. JavaScript's standard library doesn't have some useful data structures and algorithms like queue, heap, binary search, which can make your life easier during JavaScript coding interviews. However, you can ask the interviewer if you can pretend such a data structure/algorithm exists and use it directly in your solution without implementing it.
- **Pure functions**. Aim to write pure functions which have the benefit of reusability and modularity, aka functions which don't rely on state outside of the function and doesn't cause side effects.
- **Choose data structures wisely.** Pay attention to your choice of data structures and be aware of the time complexities of the code. Be familiar with the time/space complexities of the basic JavaScript Array, Object, Set, Map operations should you want to use them in your solution. Some of these time/space complexities differ across languages. Don't write code that runs in O(n<sup>2</sup>) if it can accomplished in O(n) runtime with the use of hash maps.
- **`this` matters**. If a function accepts a callback function as a parameter, consider how the `this` variable should behave. For many built-in functions, `this` is provided as one of the arguments the callback function is invoked with.
- **Mutations within callback functions.** Beware of callback functions mutating the data structure it is operating on. You probably do not need to handle this case during interviews but you should explicitly mention such cases if it's relevant.
- **Recursion edge cases**.
- If you have identified that solving the question requires recursion, ask about the input size and how to handle the case of recursion stack overflow. Usually you won't have to handle it but raising this issue is a good signal.
- Nested deep data structures can have recursive references to itself, which makes certain operations like serialization much trickier. Ask the interviewer if you have to handle such cases. Usually you won't have to handle it but raising this issue is a good signal.
## Best Practice Questions
From experience, the best JavaScript coding interview questions to practice, as determined by frequency and important concepts covered are:
- [Debounce](/questions/javascript/debounce)
- [Throttle](/questions/javascript/throttle)
- [Array.prototype.filter](/questions/javascript/array-filter)
- [Promise.all](/questions/javascript/promise-all)
- [Curry](/questions/javascript/curry)
- [Flatten](/questions/javascript/flatten)
- [getElementsByTagName](/questions/javascript/get-elements-by-class-name)
- [Deep Clone](/questions/javascript/deep-clone)
- [Data Selection](/questions/javascript/data-selection)
GreatFrontEnd has a [comprehensive list of JavaScript coding questions](/questions/js/coding/utilities) that you can practice. There are also automated tests cases you can run your code against to verify the correctness and solutions written by ex-FAANG Senior Engineers.
Note that we are intentionally vague in some of the questions and don't present the full requirements upfront in the question description. However, we'll cover as much ground as possible in the solution. It may be frustrating while reading the solutions to see that you've missed out some things, but this trains you to think ahead and consider what are the possible areas you have to take note of when working on the solution. Better to find out during practice than during actual interviews.

143
packages/front-end-interview-guidebook/contents/overview/en-US.mdx Normal file
View File

@ -0,0 +1,143 @@
---
title: Front End Interviews — Definitive Overview and Preparation Guide
description: The definitive guide to front end / web developer interviews from ex-interviewers at FAANG. Find out everything — what to expect, types of interview questions, and how to prepare.
---
Front End Interviews are notoriously hard to prepare for. There are many possible interview formats and there isn't a standardized structure across the industry for evaluating front end engineers. Some companies use the same interview process for Front End Engineers as they do for generalist Software Engineers while some companies (e.g. Google and Amazon) do a mix where they have both general software engineering rounds and front end domain-specific rounds.
In recent years, the industry is gradually shifting away from asking front end interview candidates to solve data structures and algorithms (DSA) questions. Instead, candidates will have to implement common front end library functions and/or build practical UI components/apps which tests their understanding of practical and relevant front end concepts. This is an encouraging trend because unlike most DSA questions, front end interview questions are highly relevant to a front end engineer's day-to-day responsibilities and is a more accurate assessment.
However, many existing software engineering interview resources are geared towards general software engineering roles instead of Front End Engineers which is a much smaller and niche field; you can barely find any resources on Front End System Design. These factors combined with the breadth of possible domain topics makes preparing for front end interviews a long, tedious, and tough process.
Fear not! GreatFrontEnd aims to be the best resource for Front End Engineers to ace their front end interviews by being a one-stop platform to equip Front End Engineers with the necessary knowledge and practice. On GreatFrontEnd, readers can:
1. Learn how to create an [**awesome resume tailored for Front End Engineering job listings**](/front-end-interview-guidebook/resume).
1. Learn **important front end concepts and techniques** that apply to all question types.
1. Prepare for the most common **front end interview question types** (coding, system design, quiz, behavioral).
1. [**Practice questions**](/questions) across the most common front end interview formats along with **high quality solutions** written by ex-FAANG Senior Engineers.
1. Browse suggested [**study plans**](/get-started) and adopt a **structured preparation approach**.
## Prepare an Awesome Resume
Your resume is the first opportunity to make an impression on potential employers and is crucial for getting shortlisted at your dream companies.
If you are facing difficulties getting interviews for jobs you apply to despite having the necessary qualifications, it could be because of your resume. Even highly qualified candidates may not know how to effectively present their accomplishments in their resume and therefore may not get shortlisted. It is important to remember that being underqualified is not always the reason for not being selected; sometimes it is simply a matter of poor presentation and not including the important content. Once you have made it through the resume screening process, your past achievements are secondary and your technical skills become paramount, which can be learned and improved upon. Hence getting your foot in the door by submitting a great resume that represents you well is extremely important.
While there are existing resources on how to make a good Software Engineering resume such as the [Tech Interview Handbook](https://www.techinterviewhandbook.org/resume/) and [FAANG Tech Leads' Resume Handbook](https://www.faangtechleads.com/resume/handbook), they are general and not specific to Front End Engineers. We have written some [tips on how to tailor your resume for Front End Engineering positions](/front-end-interview-guidebook/resume).
## Prepare by Question Types
There are many different formats a front end interview loop can be conducted and each company does things differently. To be efficient in your preparation, you should find out the different interview stages of the companies you are interviewing with, the various rounds within each stage, and the question types you will be asked in each round.
Each question format has its own challenges and quirks. We'll introduce you to the various formats and you can read the dedicated pages for each type if you'd like to find out more.
### Coding Questions
Coding questions will involve writing code (duh!). However, the code you will be required to write and the platforms you will write the code on can vary wildly. You could be asked about:
1. **Algorithmic Coding**: Solve tricky algorithmic questions that evaluates your understanding of data structures, algorithms and time complexity. [Read about Algorithmic Coding Interviews](/front-end-interview-guidebook/algorithms).
1. **JavaScript Coding**: Implement functions or data structures in JavaScript that are related to front end domain and commonly used during front end development. [Read about JavaScript Coding Interviews](/front-end-interview-guidebook/javascript).
1. **User Interface Coding**: Build user interfaces (components, widgets, apps) using HTML, CSS, and JavaScript, sometimes even using JavaScript frameworks. [Read about User Interface Coding Interviews](/front-end-interview-guidebook/user-interface).
Companies are trending towards using domain-specific coding questions and less on testing about algorithms and data structures as the former is more relevant for evaluating the core skills needed for front end engineering work.
### System Design Questions
System Design interviews are highly open-ended interviews that involve coming up with a software system design to solve a vague problem or scenario. Candidates will have to break down a system into smaller components, draw architecture diagrams, design APIs, dive into certain parts of the system and discuss tradeoffs in order to succeed.
System design interviews are usually only given to senior level candidates and the required systems can be one of the following types and examples:
1. **Distributed systems**: Twitter back end, URL shortener
1. **Client applications**: Newsfeed, Photo sharing applications
1. **Complex user interface components**: Autocomplete, Dropdown menu, Modal
Most of the time, Front End Engineers will be asked to design client applications and complex user interface components as those products are more relevant to front end engineering.
[Read more about Front End System Design](/front-end-interview-guidebook/system-design)
### Quiz Questions
Quiz questions, also known as trivia questions, are short questions meant to test your understanding of the domain. Each question shouldn't take more than a minute or two to answer.
There usually wouldn't be entire interview rounds just asking you quiz questions, but they could be sprung onto you in the middle of other interview rounds.
[Read more about Quiz Questions](/front-end-interview-guidebook/quiz).
## Behavioral Questions/Interviews
In behavioral interviews, interviewer asks questions about your past behaviors and experiences in order to evaluate your suitability for the job and maturity level.
The idea behind behavioral interviews is that past behaviors and experiences are good indicators of how someone will behave in the future, so the interviewer will ask questions that are designed to get you to describe specific situations you have faced and how you have dealt with them in order to get a better understanding about you beyond your technical capabilities.
Behavioral interviews is a large topic on its own and we have [written an entire guidebook on it](/behavioral-interview-guidebook).
## Typical Hiring Process
Most companies will have a process resembling:
1. **Initial screen**
- Recruiter call (Quiz questions may be asked)
- Autograded online assessments or take home projects
2. **Phone screen**
- Coding (Implementing algorithms, JavaScript functions, or building user interfaces)
3. **Full loop**
- Coding round (Implementing algorithms, JavaScript functions, or building user interfaces)
- System design round
- Behavioral round
The surest way to know what to expect is to ask the company recruiter about their interview process for the role. Good companies will even prepare a detailed document to explain each stage of the interview process along with resources to guide the candidates to prepare for the interviews. For big companies that see a large volume of applicants, there's a good chance that some candidates who have interviewed with them will share their experience on platforms like [Glassdoor](https://www.glassdoor.com/), [Blind](https://www.teamblind.com/), and [Reddit](https://www.reddit.com/).
**You must know what question types to expect in interviews, otherwise you'll be flying blind and not be able to prepare effectively.**
### Round-Type Matrix
The following matrix shows the relevance/likelihood of each question type during each interview round. It's possible that an interview round can include questions from different question types.
| Round | Quiz | Algorithms | UI | JavaScript | System Design |
| ----------------- | ------ | ---------- | ---- | ---------- | ------------- |
| Online Assessment | Medium | High | High | High | None |
| Recruiter Call | Medium | None | None | None | None |
| Take Home Project | None | None | High | Medium | Medium |
| Coding | Low | High | High | High | Low |
| Behavioral | Low | None | None | None | None |
| System Design | Low | None | Low | None | High |
| Hiring Manager | Low | None | None | None | Low |
### Question Types Asked by Companies
Here's a summary of the question types asked by the top US companies.
| Company | Quiz | Algorithms | JavaScript | UI | System Design | Behavioral |
| :-- | :-: | :-: | :-: | :-: | :-: | :-: |
| Airbnb | No | Yes | Yes | Yes | No | Yes |
| Amazon | Yes | Yes | Yes | Yes | Yes | Yes |
| Apple | Yes | Yes | Yes | Yes | Unknown | Yes |
| ByteDance | Yes | Yes | Yes | Yes | No | Yes |
| Dropbox | No | Yes | Yes | Yes | Yes | Yes |
| Facebook/Meta | Yes | No | Yes | No | Yes | Yes |
| Google | Yes | Yes | Yes | Yes | Yes | Yes |
| LinkedIn | Yes | Yes | Yes | Yes | Unknown | Yes |
| Lyft | No | No | Yes | Yes | Yes | Yes |
| Microsoft | Yes | Yes | Yes | Yes | Yes | Yes |
| Twitter | Yes | Yes | Yes | Yes | Yes | Yes |
| Uber | Unknown | Unknown | Yes | Yes | Unknown | Yes |
**Question Type Legend**
- **Quiz**: Closed ended quiz/trivia-style question.
- **Algorithms**: Implement a function that solves an algorithmic problem. It is usually not front end domain specific.
- **JavaScript**: Implement a function/class in JavaScript that is related to the front end domain.
- **UI**: Build a user interface using HTML/CSS/JavaScript. Some companies allow you to use a framework of your choice while some only allow Vanilla JS/certain frameworks.
- **System Design**: Design a system and discuss the architecture and its components.
- **Behavioral**: Discuss specific your experience working with others and how you handled difficult scenarios.
## Study and Practice
Read on to find out how to prepare for the following front end interview formats/questions types:
- [Coding Questions](/front-end-interview-guidebook/coding)
- [Algorithmic Questions](/front-end-interview-guidebook/algorithms)
- [JavaScript Questions](/front-end-interview-guidebook/javascript)
- [User Interface Questions](/front-end-interview-guidebook/user-interface)
- [System Design Questions](/front-end-interview-guidebook/system-design)
- [Quiz Questions](/front-end-interview-guidebook/quiz)

56
packages/front-end-interview-guidebook/contents/quiz/en-US.mdx Normal file
View File

@ -0,0 +1,56 @@
---
title: Front End Interview Quiz Questions — How to Prepare
description: Guide to preparing for quiz-style front end interview questions — What to expect, concepts to learn, and 100+ important practice questions.
---
Quiz questions, also known as trivia questions, are short close-ended questions meant to test your understanding of the domain. Each question shouldn't take more than a minute or two to answer, however, further discussions can be spawned from your answers. Hence it's important to have good understanding of the concepts behind the answers you give and not blindly memorize and regurgitating.
## Examples
- [Explain what the CSS box model is.](/questions/quiz/explain-your-understanding-of-the-box-model-and-how-you-would-tell-the-browser-in-css-to-render-your-layout-in-different-box-models)
- [What is CSS selector specificity?](/questions/quiz/what-is-css-selector-specificity-and-how-does-it-work)
- [What are the differences between variables created using `let`, `var` or `const`?](/questions/quiz/what-are-the-differences-between-variables-created-using-let-var-or-const)
- [Explain how `this` works in JavaScript.](/questions/quiz/explain-how-this-works-in-javascript)
Beyond getting asked on front end fundamentals (HTML, CSS, JavaScript), you could be asked on framework-specific questions if you claim to have knowledge of them (either verbally during interviews or when interviewers go through your resume):
- What problems do X technology solve?
- What are the advantages and disadvantages of X technology?
- How does X technology work under the hood?
- What does X technology compare with Y technology?
## Relevant Rounds
There usually wouldn't be interview rounds just asking you solely quiz questions. However, interviewers could spring questions onto you while in the middle of interviews focused on other formats like coding and system design.
- **Recruiter call**: Due to the close-ended nature of quiz questions, they can even be asked by non-technical personnel such as recruiters. Thankfully, non-engineers are probably not able to evaluate the accuracy and are probably just matching the keywords in your answers with the solutions handed to them. In the worst scenarios, you can probably still pass by replying something that sounds sensible and includes the right keywords.
- **Online assessment**: While uncommon, it is possible that you are given multiple choice questions and have to pick a correct answer from them.
- **Coding round**: Interviewers might ask you a few quiz questions before any coding has started to warm you up. Or while you are coding and explaining your code, the interviewer might want to dive deeper into something you just mentioned. Hence it's best to have a good understanding of everything you say/do.
- **System design round**: Like in the coding round, the interviewer can ask further questions on the things you say.
- **Hiring manager round**: Hiring manager are rounds are usually not meant to be technical but they could be going over your resume and asking you related quiz questions on technologies/projects mentioned in your resume.
As you can see, you can be expect to be asked quiz questions in almost every possible round. Be prepared at all times.
## Important Concepts
| Area | Topics |
| --- | --- |
| HTML | Semantic HTML, Block vs inline elements, `<head>`, `<script>`, `<style>`, `<link>`, `<form>`, `<input>`, Form validation/submission |
| CSS | Box model, Selectors, Specificity, Positioning, Units, Flexbox, Grid, Media Queries |
| JavaScript | Data types, Scope, Closures, `this`, Variable declaration (`var`, `let`, `const`), Array methods, Object methods, Promises, Classes, Async/Await |
| DOM | DOM creation/manipulation/traversal, Event bubbling/capturing, Event delegation |
| Runtime APIs | `fetch`, Storage (`localStorage`, `sessionStorage`), Timers (`setTimeout`, `setInterval`) |
## Tips
There are a ton of concepts to cover which can feel really overwhelming. The good thing is that learning these concepts well will make you a better Front End Engineer regardless of whether you are actively interviewing or not.
We wouldn't recommend memorizing answers to quiz questions. It's best to truly understand the solution for each question and get some real world experience by using them in projects as it's usually easier to learn by doing.
## Practice Questions
GreatFrontEnd contains a list of over 100 common quiz questions with detailed solutions written for each of them.
- [JavaScript Quiz Questions](/questions/js/quiz)
- [HTML Quiz Questions](/questions/html/quiz)
- [CSS Quiz Questions](/questions/css/quiz)

100
packages/front-end-interview-guidebook/contents/resume/en-US.mdx Normal file
View File

@ -0,0 +1,100 @@
---
title: Front End Resume — Front End Specific Writing Tips, with Examples
description: Tips to enhance your front end developer / web developer resume to get that front end job interview.
---
To even get an interview for a Front End Engineer position, we have to submit a resume that passes the company's resume screening process. There are many existing resources out there to help you craft a good Software Engineer resume but few are tailored towards Front End Engineers. For general Software Engineer resume tips, refer to [Tech Interview Handbook](https://www.techinterviewhandbook.org/resume/).
On this page, we provide some front end-specific tips to help Front End Engineers improve their resumes and get to the interview stage.
## Basic Requirements
- Preferably kept under one page if you have less than 5 years of experience, not exceeding two pages.
- Build using Microsoft Word, Google Docs, Pages, or LaTeX so that Applicant Tracking System (ATS) can parse the resumes. Avoid using design software.
- Submit in PDF format.
## Formatting and Aesthetics
Front End Engineers deal with user interfaces frequently and are expected to have a keen sense of design. It will reflect very poorly on you as a Front End Engineer if your resume isn't aesthetically pleasing.
- Use a single column format.
- Use common fonts which are available on most operating systems like Arial, Calibri, or Garamond. Avoid fancy fonts.
- Stick to a single or at most two fonts (one font for headings and another for the body).
- Minimum font size of 11px.
Your resume doesn't need to be super pretty and fancy, it just needs to look neat and visually pleasing. If you have cash to spare, the quickest way to create an aesthetically pleasing and ATS-friendly resume is to purchase resume templates from [FAANG Tech Leads](https://www.faangtechleads.com/).
## Work Experience Section
The work experience section of your resume is the most important and should take up the majority of the space on your resume. It is important to highlight your contributions to your past or current employer's business goals in this section,
To improve ATS ranking of your resume, sprinkle "Front End" across your resume where possible. If your official title is "Software Engineer" but you have been doing a significant amount of front end development as part of your job, consider putting your title as "Front End Engineer" / "Front End Software Engineer" / "Software Engineer (Front End)" instead to improve the relevance.
It is common for people to make the mistake of not providing enough details about their experiences and achievements. To stand out, it is important to provide sufficient information about the **scale, complexity, and impact** of your experiences and achievements.
- **Bad 👎**: "Built a website with HTML, CSS, and JavaScript".
- **Better 👍**: "Built a performant e-commerce website that allowed users to browse from hundreds of items, add to their cart and checkout with PayPal. The site has 20k MAU, loads under 2 seconds and a Lighthouse score of 98. Technologies used: Next.js, React, GraphQL, CSS modules."
Here's a non-exhaustive list of front end-related technical achievements that are suitable to be mentioned:
- **Product work**: Elaborate on the features built within a product.
- **Performance**: Performance improvements made and the resulting gains in percentage. E.g. page load size, page load time, Lighthouse score improvements, etc.
- **Testing**: Number of tests written, how many critical flows they cover, % increase in test coverage.
- **SEO**: % or numerical reduction in SEO errors/warnings. This metric is easy to obtain if the company uses SEO tools like Ahrefs and Semrush.
- **Accessibility (a11y)**: Number of a11y errors fixed, number of flows that were improved to meet WCAG AA/AAA level conformance, number of components where a11y improved.
- **Tooling**: Modernizing of technologies used in a code base, e.g. migrating a jQuery code base to React, improving typesafety by introducing TypeScript. Either describe the product or mention rough number of LOCs/engineers working on the code to give a better sense of the scale and complexity.
## Skills Section
The "Skills" section is a list of languages and technologies you possess and serves as a quick checklist/summary when ATS/recruiters/hiring managers read this section. At the minimum, you should have two list items for the "Languages" and "Technologies" categories:
Due to the huge number of different technologies that are required to build front end applications, you might find that you have many technologies to add into the skills section of your resume. However, do not add every technology! This dilutes the weight of the skills that actually matter. Prioritize the languages/technologies that:
### 1. Appear in the job listing
If a skill appears in the job listing and you have experience with it, you should definitely add it in.
### 2. List only key technologies that influence the architecture
Libraries like React heavily influence the other accompanying technology choices while libraries like Underscore/Lodash are architecture-agnostic and can easily be swapped out. Prioritize the former and omit small/utility libraries that are easily replaceable.
### 3. Widely known or are rapidly gaining popularity
This shows that you keep up with the modern front end ecosystem. The company might also be considering moving towards that technology and if you are experienced in that it's a plus.
### 4. Demonstrate your breadth
Listing all of React, Angular, and Vue (all front end view frameworks) is overkill even if you are indeed familiar with all of them. Few job listings will list more than one technology that serves the same purpose (and it's a red flag if they do). Adding too many technologies (especially of the same category) makes it harder for the reader to get a sense of your skills.
Try to list **at least one and at most two** technologies that belong to the following categories. Not all categories will apply to you, so only include the relevant ones. Popular examples are shown below.
- **View**: [React](https://reactjs.org/), [Angular](https://angular.io/), [Vue](https://vuejs.org/), [Svelte](https://svelte.dev/)
- **Rendering Frameworks**: [Next.js](https://nextjs.org/), [Gatsby](https://www.gatsbyjs.com/), [Nuxt](https://nuxtjs.org/), [SvelteKit](https://kit.svelte.dev/)
- **State Management**: [Redux](https://redux.js.org/), [Flux](https://facebook.github.io/flux/), [Jotai](https://jotai.org/), [Zustand](https://github.com/pmndrs/zustand), [Relay](https://relay.dev/)
- **CSS**: [CSS Modules](https://github.com/css-modules/css-modules), [Styled Components](https://styled-components.com/), [Tailwind CSS](https://tailwindcss.com/), [Sass](https://sass-lang.com/), [Less](https://lesscss.org/)
- **CSS Frameworks**: [Bootstrap](https://getbootstrap.com/), [Material UI](https://mui.com/), [Chakra UI](https://chakra-ui.com/), [Bulma](https://bulma.io/)
- **Unit Testing**: [Jest](https://jestjs.io/), [Vitest](https://vitest.dev/), [Storybook](https://storybook.js.org/), [Mocha](https://mochajs.org/), [Jasmine](https://jasmine.github.io/), [Karma](https://karma-runner.github.io/latest/index.html)
- **Data Fetching**: [GraphQL](https://graphql.org/), [tRPC](https://trpc.io/), [TanStack Query](https://tanstack.com/query/v3/), [swr](https://swr.vercel.app/)
- **Integration Testing**: [Cypress](https://www.cypress.io/), [Selenium](https://www.selenium.dev/), [Puppeteer](https://pptr.dev/), [WebdriverIO](https://webdriver.io/), [Playwright](https://playwright.dev/)
- **Language Tooling**: [Babel](https://babeljs.io/), [TypeScript](https://www.typescriptlang.org/), [Flow](https://flow.org/), [ESLint](https://eslint.org/)
- **Build Tools (optional)**: [webpack](https://webpack.js.org/), [Vite](https://vitejs.dev/), [Parcel](https://parceljs.org/), [Gulp](https://gulpjs.com/), [Rollup](https://rollupjs.org/), [Browserify](https://browserify.org/)
- **Package Management (optional)**: [npm](https://www.npmjs.com/), [Yarn](https://yarnpkg.com/), [pnpm](https://pnpm.io/)
### Example
This would be how the "Skills" section on our resume looks like:
- **Languages**: HTML, CSS, JavaScript, TypeScript
- **Technologies**: React, Next.js, Tailwind CSS, Jest, Storybook, Cypress, React Query, Yarn, webpack
This is exactly the technology stack used to build GreatFrontEnd. You should definitely have HTML, CSS, JavaScript under your "Languages" item, otherwise there's something hugely wrong.
## Projects Section
The front end domain advances pretty fast with new JavaScript frameworks and CSS methodologies emerging every year. Having projects on your resume suggests that you are passionate about the field and put in the extra effort to up with latest front end technologies especially if they are not used at your job, which is a huge positive signal. List down the technologies used for each project especially if they are modern technologies that the company uses. It helps with ATS ranking and leaving a deeper impression on the reader. Where possible, put the code on GitHub and polish up the README with screenshots of the product. Add links to the project's code and live website into your resume.
Open source contributions, especially non-trivial changes to complex code bases are seen as a sign of technical competency. Even better if you have created or are a maintainer of open source projects.
## Summary
While [Tech Interview Handbook's general Software Engineer resume tips](https://www.techinterviewhandbook.org/resume/) are mostly sufficient for Front End Engineers, the tips above will help you to elevate your Front End Engineer resume and bring it to the next level.

21
packages/front-end-interview-guidebook/contents/system-design/en-US.mdx Normal file
View File

@ -0,0 +1,21 @@
---
title: Front End System Design Questions — How to Prepare
description: Guide to preparing for System Design questions in front end / web developer interviews — Best practices and important practice questions.
---
System Design interviews can come in many forms and covers the entire development stack. GreatFrontEnd focuses on **Front End System Design**, aka system design and architecture of client applications and UI components rather than back end distributed systems.
We have written a comprehensive [Front End System Design guide](/system-design) which you should definitely check out.
## Design Your System With Best Practices
When going about the system design interview, regardless whether you are asked to design apps, games, or UI components, there are some things to pay special attention to. Incorporate the tips from our [User Interface Questions Cheatsheet](/front-end-interview-guidebook/user-interface-questions-cheatsheet) and elevate your front end interview game.
## Practice Questions
GreatFrontEnd includes many front end system design case studies and real world examples including and more:
- [News Feed (e.g. Facebook)](/questions/system-design/news-feed-facebook)
- [Autocomplete Component](/questions/system-design/autocomplete)
- [E-commerce Website (e.g. Amazon)](/questions/system-design/e-commerce-amazon)
- [Image Carousel](/questions/system-design/image-carousel)

374
packages/front-end-interview-guidebook/contents/user-interface-components-api-design-principles/en-US.mdx Normal file
View File

@ -0,0 +1,374 @@
---
title: User Interface Components API Design Principles
description: Best practices for designing developer interface components APIs, useful for UI components coding and system design interviews
---
User Interface component libraries like [Bootstrap](https://getbootstrap.com/) and [Material UI](https://mui.com/) help developers build UI faster by providing commonly used components like buttons, tabs, modals, etc so that developers do not have to reinvent the wheel by building these components from scratch whenever they start on a new project.
Often during front end interviews, you will be asked to build UI components and design an API to initialize them. Designing good component APIs is bread and butter for Front End Engineers. This page covers some of the top tips and best practices for designing UI component APIs. Some of these tips may be framework-specific but can be generalized for other component-based UI frameworks.
## Initialization
### jQuery-style
Before modern JavaScript UI libraries/frameworks like [React](https://reactjs.org/), [Angular](https://angular.io/), and [Vue](https://vuejs.org/) came into the picture, [jQuery](https://jquery.com/) (and [jQuery UI](https://jqueryui.com/)) was the most popular way to build UI. jQuery UI popularized the idea of initializing UI components via "constructors" which involved two arguments:
1. **Root Element**: A root DOM element to render the contents.
1. **Customization Options**: Optional, additional, customization options usually in the form of a plain JavaScript object.
Using jQuery UI, one can turn a DOM element into a [slider](https://api.jqueryui.com/slider/) (among many other UI components) with a single line of code:
```html
<div id="gfe-slider"></div>
<script>
$('#gfe-slider').slider();
</script>
```
**jQuery refresher**: jQuery UI's `slider()` method (constructor) takes in a JavaScript object which serves as customization options. Doing `$('#slider')` selects the `<div id="slider">` element and returns a jQuery object that contains convenient methods to "do something" with the element such as `addClass`, `removeClass`, etc and other DOM manipulation methods. Within jQuery methods, the selected element can be accessed via the `this` keyword. jQuery APIs are built around this "select an element and do something with it" approach, hence the `slider()` method does not need an argument for the root DOM element.
The slider can be customized by passing in a plain JavaScript object of options:
```html
<div id="gfe-slider"></div>
<script>
$('#gfe-slider').slider({
animate: true,
max: 50,
min: 10,
// See other options here: https://api.jqueryui.com/slider/
});
</script>
```
### Vanilla JavaScript Style
There's no vanilla JavaScript style for initializing components since vanilla JavaScript is not a standard or framework. But if you have read enough of GreatFrontEnd's solutions for our vanilla JavaScript [UI coding questions](/questions/vanilla), you'll see that the API we recommend is similar to jQuery's, the constructor takes in a root element and options:
```js
function slider(rootEl, options) {
// Do something with rootEl and options.
}
```
### React
React forces you to write UI as components which contain its own logic and appearance. React components are JavaScript functions that return markup (a description of how to render itself). React components can take in `props`, which are essentially customization of a component's options.
```js
function Slider({ min, max }) {
// Use the props to render a customized component.
return <div>...</div>;
}
<Slider max={50} min={10} />;
```
Components do not take in a root element. To render the element into the page, a separate API is used.
```jsx
import { createRoot } from 'react-dom/client';
import Slider from './Slider';
const domNode = document.getElementById('#gfe-slider');
// React will manage the DOM within this element.
const root = createRoot(domNode);
// Display the Slider component within the element.
root.render(<Slider max={50} min={10} />);
```
You will usually not need to call `createRoot()` yourself if the entire page a React app because there will only be one `createRoot` call for the root/page-level component.
## Customizing Appearance
Even though UI components in UI libraries provide default styling, developers will usually want to customize them with their company/product's branding and theme colors. Hence all UI components will allow for customization of the appearance, via a few methods:
### Class Injection
The idea here is simple, components accept a prop/option to allow the developer to provide their own classes and these classes are added to the actual DOM elements. This approach is not very robust because if the component also adds its own styling via classes, there could be conflicting properties within the component's classes and developer-provided classes.
#### React
```jsx
import clsx from 'clsx';
function Slider({ className, value }) {
return (
<div className={clsx('gfe-slider', className)}>
<input type="range" value={value} />
</div>
);
}
<Slider className="my-custom-slider" value={50} />;
```
```css
/* UI library default stylesheet */
.gfe-slider {
height: 12px;
}
```
```css
/* Developer's custom stylesheet */
.my-custom-slider {
color: red;
}
```
Through class injection, developers can change the text `color` of the component to be `red`.
If there are many DOM elements within the component to be targeted and one single `className` prop is not sufficient, you can also have multiple differently-named props for `className`s of different elements:
```jsx
import { useId } from 'react';
import clsx from 'clsx';
function Slider({ label, value, className, classNameLabel, classNameTrack }) {
const id = useId();
return (
<div className={clsx('gfe-slider', className)}>
<label className={clsx('gfe-slider-label', classNameLabel)} for={id}>
{label}
</label>
<input
className={clsx('gfe-slider-range', classNameRange)}
id={id}
type="range"
value={value}
/>
</div>
);
}
```
#### jQuery
In jQuery, classes can also be passed as a field on the options.
```js
$('#gfe-slider').slider({
// In reality, jQuery UI takes in a `classes` field instead
// since there are multiple elements.
class: 'my-custom-slider',
});
```
In reality, all of jQuery UI's component initializers take in the `classes` field to allow adding additional classes to individual elements. The following example is taken from [jQuery UI Slider](https://api.jqueryui.com/slider/#option-classes):
```js
$('#gfe-slider').slider({
classes: {
'ui-slider': 'highlight',
'ui-slider-handle': 'ui-corner-all',
'ui-slider-range': 'ui-corner-all ui-widget-header',
},
});
```
#### Non-deterministic Styling
Class injection has an unobvious downside — the final visual result is non-deterministic and may not be what is expected. Take the following code for example:
```jsx
import clsx from 'clsx';
function Slider({ className, value }) {
return (
<div className={clsx('gfe-slider', className)}>
<input type="range" value={value} />
</div>
);
}
<Slider className="my-custom-slider" value={50} />;
```
```css
/* UI library default stylesheet */
.gfe-slider {
height: 12px;
color: black;
}
```
```css
/* Developer's custom stylesheet */
.my-custom-slider {
color: red; /* .gfe-slider also defines a value for color. */
}
```
In the example above, both `.gfe-slider` and `.my-custom-slider` classes specify the `color` and because these two selectors have the same specificity, the winning style is actually the class that appears later on the HTML page. If the loading order of the stylesheet is not guaranteed (e.g. if stylesheets are lazily loaded), the visual result will not be deterministic. This is when developers start using hacks like `!important` or `.my-custom-slider.my-custom-slider` to let their selectors win the specificity war and the CSS code starts becoming unmaintainable.
In jQuery UI, if a custom class is added, the existing default value is not used. This removes the "winning style" ambiguity but the user must now reimplement all the necessary styles present in the original class. This approach can also be applied to React components to resolve the ambiguity.
Despite its possible flaws, class injection is still a very popular option.
### CSS Selector Hooks
Technically speaking, developers can achieve customization if they read the source code of the component and define their custom styling by using the same classes. However, doing this is dangerous as relying on a component's internals and there's no guarantee that the class names won't change in future.
If UI library authors can make these classes/attributes part of their API, which comes with these guarantees:
1. The list of selectors is published for external reference.
1. Existing published selectors will not be changed. If they are changed, it will be a breaking change and a version bump is needed as per semver.
Then it's an acceptable practice and developers can "hook" onto them (target them) by using these selectors in their stylesheets.
An example of hooking into a component's selectors:
```jsx
import { useId } from 'react';
import clsx from 'clsx';
function Slider({ label, value }) {
const id = useId();
return (
<div className="gfe-slider">
<label className="gfe-slider-label" for={id}>
{label}
</label>
<input className="gfe-slider-range" id={id} type="range" value={value} />
</div>
);
}
```
```css
/* UI library default stylesheet */
.gfe-slider {
font-size: 12px;
}
/* No other classes are defined in this stylesheet,
gfe-slider-label and gfe-slider-range are added
to the component just for developers to gain access
to the underlying elements. */
```
```css
/* Developer's custom stylesheet */
.gfe-slider {
font-size: 16px; /* Conflicts with the default .gfe-slider */
padding: 10px 20px;
}
.gfe-slider-label {
color: red;
}
.gfe-slider-range {
height: 20px;
}
```
This approach saves developers the hassle of passing in classes into the component as they only have to write CSS to customize the styling. [Reach UI](https://reach.tech/styling), a headless UI component library for React, uses element selectors. Each component has a `data-reach-*` attribute on the underlying DOM element.
```css
[data-reach-menu-item] {
color: blue;
}
```
However, this approach still suffers from the non-deterministic styling issue as per "class injection" and doesn't easily allow per-instance styling. If per-instance styling is desired, this approach can be combined with the class injection approach.
### Theme Object
Instead of taking in classes, the component takes in an object of key/values for styling. This is useful if there is only a strict subset of properties to customize, or if you want to restrict styling to only a few properties.
```jsx
const defaultTheme = { color: 'black', height: 12 };
function Slider({ value, label, theme }) {
// Combine with default.
const finalTheme = { ...defaultTheme, ...theme };
return (
<div className="gfe-slider">
<label
for={id}
style={{
fontSize: finalTheme.color,
}}>
{label}
</label>
<input
id={id}
type="range"
value={value}
style={{
height: finalTheme.height,
}}
/>
</div>
);
}
<Slider themeOptions={{ color: 'red', height: 24 }} {...props} />;
```
However, since no classes with conflicting styles are used, and inline styles have higher specificity than classes, there's no specificity conflict and the inline styles will win. However, the number of options that need to be supported can grow really quickly. Inline styles are also present in the DOM per component instance, which can be bad for performance if this component is rendered hundreds/thousands of times within a page.
The theme object is just a way to restrict the styling to certain properties and optionally, an accepted set of values, the values do not need be used as inline styles and instead can be combined with other styling approaches.
### CSS Preprocessor Compilation
UI libraries are usually written with CSS preprocessors like [Sass](https://sass-lang.com/) and [Less](https://lesscss.org/). [Bootstrap](https://getbootstrap.com/) is written with Sass and they provide a way to [customize the Sass variables](https://getbootstrap.com/docs/5.3/customize/sass/) used so that developers can generate a custom UI library stylesheet.
This approach is great because it doesn't rely on overriding CSS selectors to achieve customization. There's also less amount of resulting CSS and no redundant overridden styles. The downside is that a compilation step is needed.
### CSS Variables / Custom Properties
[CSS variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties) (or more formally known as CSS custom properties) are entities defined by CSS authors that contain specific values to be reused throughout a document. The `var()` function, it accepts fallback values if the given variable is not set.
```jsx
function Slider({ value, label }) {
return (
<div className="gfe-slider">
<label for={id}>{label}</label>
<input id={id} type="range" value={value} />
</div>
);
}
```
```css
/* UI library default stylesheet */
.gfe-slider {
/* Fallback of 12px if not set. */
font-size: var(--gfe-slider-font-size, 12px);
}
```
```css
/* Developer's custom stylesheet */
:root {
--gfe-slider-font-size: 15px;
}
```
The developer can define a value for `--gfe-slider-font-size` globally via the `:root` selector and set the font size for the `.gfe-slider` class to be 15px. The benefit of this approach is that it doesn't require JavaScript, however, per-component customization will be more troublesome (but still possible).
### Render Props
In React, render props are function props that a component uses to know what to render. It is useful for separating behavior from presentation. Many behavioral/headless UI libraries like [Radix](https://www.radix-ui.com/), [Headless UI](https://headlessui.com/), and [Reach UI](https://reach.tech/menu-button) make heavy use of render props.
{/* TODO: Section on manipulation of component after initialization */}
## Internationalization (i18n)
Does your UI work for multiple languages? How easy is it to add support for more languages?
### Avoid hardcoding of labels in a certain language
Some UI components have label strings within them (e.g. image carousel has labels for prev/next buttons). It'd be good to allow customization of these label strings by making them part of component props/options.
### Right-to-left languages
Some languages (e.g. Arabic, Hebrew) are read from right-to-left and the UI has to be flipped horizontally. The component can take in a `direction` prop/option and change the order of how elements are rendered. For example, the prev and next buttons will be on the right and left respectively in an RTL language.
Use [CSS logical properties](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Logical_Properties) to futureproof your styles and let your layout work for different [writing modes](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Writing_Modes).
{/* TODO: Give examples of how to implement RTL. */}

160
packages/front-end-interview-guidebook/contents/user-interface-questions-cheatsheet/en-US.mdx Normal file
View File

@ -0,0 +1,160 @@
---
title: Front End User Interface Questions Cheatsheet
description: Top tips to improve the user interfaces you have to build during front end / web developer interviews - Code structure, managing state, accessibility and more.
---
Here are some tips you can use to improve the user interfaces you have to build/design during front end interviews. These can be applied to both [User Interface Coding Interviews](/front-end-interview-guidebook/user-interface) and [Front End System Design Interviews](/system-design/types-of-questions).
## General
- **Break down the problem**: Break down the problem into stages/milestones that build on top of each other and write your code progressively.
- **Test frequently**: Test the UI in the browser after you complete every feature so that you can catch bugs early. Bugs caught earlier are easier to fix. Make sure the current feature is working before moving on to the next feature.
- **Use JavaScript frameworks if possible**: Your life will be very hard if you choose to build complicated UI using Vanilla JavaScript as the code can get very long and messy quickly. We recommend building apps and games using a framework if possible.
- **Think ahead and plan accordingly**: Think about what features your interviewer might ask you to add next. Design your code in a way that makes it easy for new features to be added.
## Component Organization
How do you structure your code?
- **Adopt the [Container/Presentational Pattern](https://www.patterns.dev/posts/presentational-container-pattern/)**: To achieve good decoupling, rendering code should be agnostic to the source of data. Separate components into an outer one that provides the data and an inner stateless one that renders the view based on the data. This makes it easy for the view to switch from local component/app state to data loaded from the network and vice versa, you only have to change the outer component and the inner component can be used as-is.
- **Break down the app into subcomponents**: If the UI has multiple parts, break the UI into smaller components and identify the props/state needed by each component.
- **Minimal API surface area**: Don't pass excess data to inner components which don't need them.
- **Component instantiation**: When asked to build UI components, define APIs (usually functions) to allow creating multiple independent instances of the components along with configurable options and defaults. Avoid writing code (e.g. relying on global variables) that prevents separate UI component instances from being created.
- **Vanilla JavaScript**: Create a function that takes in a DOM element (the container element) and an options object. Within the function you can dynamically create DOM elements and append to the container element. Another source of inspiration for a component API is [jQuery UI](https://jqueryui.com), but that has a dependency on jQuery.
- **Other JavaScript UI frameworks**: Most modern JavaScript UI frameworks like React forces you to think in terms of components by default.
## State Design
State is data that changes over time in your UI, commonly due to user interactions or background events (network request response, passing of time, WebSocket events).
Most UI questions in interviews will require state and designing the state well is paramount.
- **Determine the minimum state needed in your UI**: The smaller the state, the easier it is to read and understand the code -> lower likelihood for bugs.
- Identify essential state vs derived state. Derived state is state that can be calculated from essential state.
- **Separate rendering code vs data management code**: Make the UI a function of your data and separate your code into two groups (rendering code and data management code) for better readability. If you use JavaScript frameworks such as React, you will more or less be forced to do so.
- **Use the state-reducer pattern for complex state interactions**: If the question requires many state fields and certain actions require changing multiple fields at once, use a [reducer to consolidate state update logic](https://beta.reactjs.org/learn/extracting-state-logic-into-a-reducer). First popularized by Redux, the state-reducer pattern encourages you to determine the state of your UI, actions that can be taken, and how to combine actions with state to derive the next state. If you are using React, you can achieve this pattern via the [`useReducer` React hook](https://reactjs.org/docs/hooks-reference.html#usereducer). Redux is usually overkill for interviews and `useReducer` should be sufficient.
[React's](https://beta.reactjs.org) docs on ["Managing State"](https://beta.reactjs.org/learn/managing-state) is an excellent resource on how to design and use component state correctly. Some of the ideas mentioned aren't specific to React and can be applied to any UI frameworks.
## JavaScript
Is your JavaScript using modern language syntax and good practices while avoiding bad practices?
- **Use a style guide**: Use a JavaScript style guide like [Airbnb's JavaScript Style Guide](https://github.com/airbnb/javascript). During development, static analysis tools like [ESLint](https://eslint.org) can help you to enforce some of these good practices. However, these tools might not be available during interviews. Try to get accustomed to writing code with good coding style without help from a tool.
- **Leave the global environment alone**: This applies to Vanilla JavaScript scenarios. Avoid polluting global scope by declaring global variables and global functions. Write an Immediately-Invoked Function Expression (IIFE) and put all custom code within it.
## HTML
Are you writing semantic HTML with the right attributes?
- **Semantic tags**: Use heading tags for titles, button tags for interactive elements, list tags for sequential elements, and so on. Don't use `<div>`s for everything!
- **Heading hierarchy**: Ensure heading tags have a hierarchy and there's not more than one `<h1>` in the DOM.
- **Interactive elements**: Use `<button>` for elements that require interaction. Resist adding click handlers to `<div>` and `<span>`s.
### Forms
Forms are complex on its own and deserves its own section.
- **Link labels and inputs**: `<input>`s should be linked to `<label>`s using `id` and `for`.
- **Wrap inputs in a form**: `<input>`s should be wrapped in a `<form>` so that clicking on buttons and hitting Enter will submit the form. Remember to add `event.preventDefault()` if the network request is meant to be made using Ajax.
- **Inputs should have appropriate types**: `<input>`s should have appropriate `type` like `email`, `password`, `number`, etc.
- **Leverage native HTML form validation**: Where possible, use the `required` attribute combined with other attributes like `pattern`, `min`, `max`, and so on.
## CSS/Styling
Is your CSS written in a scalable and easy-to-understand manner?
- **Write Vanilla CSS**: Learn to write CSS without reliance on preprocessors like [Sass](https://sass-lang.com/) and [Less](https://lesscss.org/). Not all environments will allow using processors and interview questions are likely small and do not really benefit from the features CSS preprocessors bring. The most useful feature of CSS processors is the use of variables, which is available natively via CSS custom properties (variables).
- **Adopt a CSS naming convention**: Consider adopting a CSS naming methodology like [Block Element Modifier](https://getbem.com) when writing your classes.
- **Avoid `#id` selectors in components**: When building UI components meant to be reused (e.g. buttons, tabs, menus, modals, etc), avoid using `#id` selectors in the HTML as `id`s are meant to be globally unique but you can have multiple instances of the component.
- **Organize your CSS**: Read about how to [organize your CSS in big projects](https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/Organizing) and how to have a [Scalable and Modular Architecture for CSS](http://smacss.com/).
## User Experience
Does your UI provide a great user experience?
- **Mobile-friendliness**: Check if you need to make your UI work well on mobile.
- CSS media queries can be used to render a different layout on mobile.
- Make interactive elements like buttons large enough to be pressed (recommend at least 44 x 44 px) and spaced widely enough.
- **Error states**: Reflect errors promptly and clearly — form validation errors, network request errors.
- **Handle rendering images of different dimensions**: Make your UI work for rendering images of all sizes/dimensions yet preserving the original aspect ratios.
- Use CSS `background-image` together with `background-position: contain` so that the image fits within your defined area. If it is ok for the image to be cropped off (e.g. for gradient backgrounds), use `background-position: cover`.
- `<img>` tags have a similar `object-fit` property with `contain` and `cover` values.
- **Optimistic updates**: Advanced technique where the success state is reflected even though the network request is still pending. If the request fails, revert the UI changes and show an error message.
## Network
Does your UI handle the unpredictable nature of network requests and conditions?
- **Reflect network request states**: If the UI involves making network requests, clearly show the pending/success/failure state of the requests
- **Pending**: Disable fields/buttons, show a spinner.
- **Error**: Show an error message.
- **Success**: Update the UI and/or show a success message.
- **Race conditions**: A common reason is due to parallel network requests where the response order is not guaranteed. A request made later could receive a response earlier. If your UI is susceptible to this, you can keep track of the latest requests and ignore the results from the earlier ones. Alternatively, make it such that your UI cannot fire multiple network requests at once, e.g. by disabling elements which trigger network requests after they're clicked.
- **Prevent duplicate requests**: Buttons should be disabled after submission to avoid making duplicate network requests.
- **Consolidating requests**: If the UI is making too many network requests, you can:
- **Debounce/throttle**: Rate limit the number of network requests fired.
- **Batch requests**: Group requests together and make only one single request. This requires the server side to support such a format.
- **Caching**: If a request with the same parameters has been made recently, can you reuse the previous response and save on a network round trip?
- **Request timeouts**: You might want to artificially show that the request has failed (timed out) if the request doesn't receive a response after a stipulated duration.
- **Optimistic updates**: Advanced technique where the success state is reflected even though the network request is still pending. If the request fails, revert the UI changes and show an error message.
## Accessibility (a11y)
Handling accessibility in UI is a huge plus and in some cases a requirement for senior engineers.
- Can you use the UI with the keyboard only?
- Can you use your UI component with a screen reader?
- Can your UI component work without color?
- Can your UI component work without sound?
Source: [Accessible UI Components for the web](https://medium.com/@addyosmani/accessible-ui-components-for-the-web-39e727101a67)
- **Screen readers, ARIA roles, states, and properties**:
- Add the right `aria-role`s for custom built elements not built using custom HTML tags.
- Use `aria-label`s to describe elements where text is not shown (e.g. icon-only buttons).
- Link error messages elements with the elements responsible for them via `aria-describedby`/`aria-errormessage`.
- **Image `alt` text**: Add `alt` attribute to `<img>` elements so that screen readers can describe the image.
- **Keyboard interactions**
- Add the `tabindex` attribute to elements you want to be focusable via keyboard tabbing.
- Elements can be triggered via keyboard.
- Check that the focus order makes sense.
- **Visual issues**
- **Color contrast**: Sufficient color contrast between text/images and the background.
- **Size of elements**: font size, interactive element size should be large enough for their intended medium.
web.dev by Google has a [free in-depth course on accessibility](https://web.dev/learn/accessibility/) which we highly recommend.
## Edge Cases
There's probably not enough time to handle all edge cases scenarios in your code during the interview, but it'd be good to mention them to the interviewer for brownie points.
- **Handle long strings**: Strings in UI (e.g. headings/button labels) can cause the UI to behave weirdly such as overflowing and affect the position of surrounding elements. Long strings can be a result of user input or translations.
- **Empty states**: Show an empty state message/placeholder to indicate absence of contents e.g. when the list is empty. Showing nothing might make the user think that there's a pending network request and that data is still being fetched.
- **Too many items in a list**: Showing too many items on a single page can lead to poor UX (user has to scroll a lot) and poor performance in terms of responsiveness and memory consumption.
- **Pagination**: Break up a long list of items into multiple pages.
- [**Virtual lists**](https://www.patterns.dev/posts/virtual-lists): Rendering only visible rows of content in a dynamic list instead of the entire list.
- Truncate the excess content and show an ellipsis. The `word-break` CSS property will come in handy useful.
- Limit the content to the first X characters/words and hide the excess content behind a "Show More" button.
## Performance
- **Throttle/debounce**: Throttle and debounce are rate limiting techniques to prevent unnecessary operations. This technique can be used for operations which aren't super time-sensitive like network requests and scroll/resizing event callbacks.
- **Caching**: The results of duplicate computations / network requests can be cached in browser memory/storage and not repeated.
- **On demand loading**: Lazy load data/component code only when they are needed, instead of loading all at the start.
- **Prefetch/preload data**: Reduce network latency by prefetching/preloading data right before it is needed so that updates appear instantly.
- **Too many items in a list**: Refer to the point under "Edge Cases" above.
## Security
- **Cross-site Scripting (XSS)**: Avoid assigning to [`Element.innerHTML`](https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML) or React's `dangerouslySetInnerHTML` when rendering contents into the DOM if it comes from users to prevent cross-site scripting, assign to [`Node.textContent`](https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent) or use the experimental[`Element.setHTML()`](https://developer.mozilla.org/en-US/docs/Web/API/Element/setHTML) method instead. Refer to [OWASP's XSS Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)
- **Output encoding for "URL Contexts"**: If user-supplied input can be used in URL query parameters, use `encodeURIComponent` to prevent unintended values from becoming part of the URL (e.g. extra query parameters).
- **Cross Site Request Forgery**: Refer to [OWASP's XSS Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html).
## Internationalization (i18n)
Does your UI work for multiple languages? How easy is it to add support for more languages?
- **Avoid hardcoding of labels in a certain language**: Some UI components have label strings within them (e.g. image carousel has labels for prev/next buttons). It'd be good to allow customization of these label strings by making them part of component props/options.
- **UI can render long strings**: Refer to the section above on rendering long strings.
- **Right-to-left languages**: Some languages (e.g. Arabic, Hebrew) are read from right-to-left and the UI has to be flipped horizontally. Use [CSS logical properties](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Logical_Properties) to make your layout work for different [writing modes](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Writing_Modes).

117
packages/front-end-interview-guidebook/contents/user-interface/en-US.mdx Normal file
View File

@ -0,0 +1,117 @@
---
title: Front End Interview User Interface Coding Questions — How to Prepare
description: Guide to preparing for User Interface questions in front end / web developer interviews — Concepts to know, interview rubrics, and important practice questions.
---
User interface coding interviews will involve candidates writing HTML, CSS and JavaScript to complete. In our opinion this is essential for evaluating the skills of Front End Engineers and more companies are moving towards asking candidates to code user interfaces during interviews.
The user interfaces that candidates are asked to code can range from really small UI components to more complex client-facing products like small apps and games.
## Examples
### User Interface Components/Widgets/Layouts
- Components: [Accordion](/questions/user-interface/accordion), [Tabs](/questions/user-interface/tabs), [Star Rating Widget](/questions/user-interface/star-rating), [Tweet](/questions/user-interface/tweet), Image Carousel.
- Widgets: [Digital Clock](/questions/user-interface/digital-clock), [Analog Clock](/questions/user-interface/analog-clock).
- Page Sections: [Signup Form](/questions/user-interface/signup-form), [Holy Grail](/questions/user-interface/holy-grail)
### Apps/Games
The time allowed for apps/games questions is usually longer than components/widgets. Depending on how complex the question is, you may spend up to half an hour or even an hour to complete the question, especially if you are asked to build games.
- Apps: [Todo List](/questions/user-interface/todo-list), [Stopwatch](/questions/user-interface/stopwatch), [Temperature Converter](/questions/user-interface/temperature-converter).
- Games: [Tic-tac-toe](/questions/user-interface/tic-tac-toe), [Whack-a-mole](/questions/user-interface/whack-a-mole), Snake, Tetris, Minesweeper, Connect 4.
Observe that most games will be 2D grid-based games. Make sure you know how to create grid layouts in HTML and CSS!
## What to do during User Interface Coding Interviews
User interface coding interviews share a fair bit of similarity with non-front end coding interviews. In general, you should:
1. Find out what platform you are coding on and familiarize yourself with the coding environment:
- Whether you will be using a local IDE or an online one. If local IDE, will you be using your own laptop?
- The supported editor shortcuts.
- Whether you can use JavaScript libraries/framework or have to use vanilla JavaScript.
- Whether you can execute code and preview the UI.
- What are the latest supported JavaScript syntax and language features?
- Whether you can install dependencies beforehand.
1. Make your self introduction under a minute. Unless requested, do not take longer than this otherwise you might not have enough time to code.
1. Ask clarifying questions upon receiving the question. Clarify the following:
- Can you use the newest JavaScript syntax?
- Browser support, as this will affect the browser APIs you can use.
1. Break down the problem into stages/milestones that build on top of each other. Communicate this breakdown to your interviewer. Unlike coding interviews, the focus of User Interface coding interviews is usually around the component states and APIs as opposed to complex data structures and algorithms.
1. Code out your solution and explain your code to your interviewer while you are coding.
- Where possible, test your code in the browser after every milestone/feature added, instead of only at the end.
- Refer to the [User Interface Questions Cheatsheet](/front-end-interview-guidebook/user-interface-questions-cheatsheet) for a list of things to take note of during User Interface coding interviews.
1. After coding, read through your code once and try to spot basic errors like typos, using variables before initializing them, using APIs incorrectly, etc.
1. Outline some basic test cases and some edge cases. Test your code with these cases and determine if your code passes them. If it fails, debug the issue(s) and fix them.
1. Explain any tradeoffs you made, cases you explicitly didn't handle, and how you would improve the code if you had more time.
1. The interview might not end here, the interviewer might have follow-up questions for you on this question or give you another question. Be prepared for them.
## How to Prepare for User Interface Coding Interviews
1. Be familiar with the topics under the "Important Concepts" below. The [Quiz section](/front-end-interview-guidebook/quiz) can also be a good start since you might be asked on these concepts in the form of quiz questions during coding.
1. It's best to learn how to build UIs in both Vanilla JavaScript and a UI framework of choice. Most companies will allow using JavaScript UI frameworks but some companies (e.g. Google) mandate that you can only use Vanilla JavaScript.
- **Vanilla JavaScript**: Learn the DOM manipulation APIs. At the very least you should know how to create new DOM elements, add classes/attributes to them, and add child elements. If you come from a [jQuery](https://jquery.com/) background, check out [You might not need jQuery](https://youmightnotneedjquery.com), a website showing you how to accomplish the common jQuery operations in Vanilla JavaScript. You will be pleasantly surprised to find out that with modern browser APIs there isn't really much need for jQuery anymore.
- **JavaScript UI framework**: Be familiar with a UI framework of choice. Stick with the framework that you are most familiar with. There's no need and also probably not enough time to learn a new framework. If you are new to JavaScript UI frameworks, [React](https://reactjs.org/) will be our recommendation as it is the most popular library/framework to build UI right now and it is the most popular languages companies look for when hiring front end engineers.
1. Be familiar with writing CSS under interview conditions (small questions which won't require writing that much CSS):
- **Write Vanilla CSS**: Learn to write CSS without reliance on preprocessors like Sass/Less. Not all coding environments will allow using processors and interview questions are likely small and do not really benefit from the features CSS preprocessors bring. The most useful feature of CSS processors is the use of variables, which is available natively via CSS custom properties (CSS variables).
- **Adopt a CSS naming convention**: Consider adopting a CSS naming methodology like [Block Element Modifier](https://getbem.com) when writing your classes.
1. Read our User Interface coding deep dive guides:
- [User Interface Questions Cheatsheet](/front-end-interview-guidebook/user-interface-questions-cheatsheet)
- [User Interface Components API Design Principles](/front-end-interview-guidebook/user-interface-components-api-design-principles)
1. Pick a [study plan](/get-started) and practice the [User Interface coding questions](/prepare/coding) recommended for the selected study plan.
- Spend roughly equal amount of time practicing building both UI components and building apps/games. Both are equally important.
## Important Concepts
| Category | Important Topics |
| --- | --- |
| Data Structures | Arrays, Maps, Stacks, Trees, Sets |
| Software Engineering | SOLID Principles, Design Patterns, Model-View-Controller |
| HTML | Semantic HTML, Form validation, Form submission |
| CSS | Box model, Selectors, Specificity, Positioning, Units, Flexbox, Grid, CSS custom properties (variables) |
| JavaScript | Closures, Callbacks, `Promise`, `async`/`await`, Handling variadic arguments |
| DOM | DOM traversal, DOM creation, DOM manipulation, Accessing element/node properties, Event delegation |
| Runtime APIs | Timer (`setTimeout`, `setInterval`), Network (Ajax, `fetch`) |
| Accessibility | ARIA roles, states & properties, Keyboard interactions |
## User Interface Coding Interview Rubrics
User interface coding interviews have similar rubrics as to JavaScript coding interviews as both involve coding in the front end domain. However, user interface coding questions will have even more emphasis on domain expertise and the various front end topics.
- **Problem Solving**: Use a systematic and logical approach to understanding and addressing a problem. Break down the problem into smaller independent problems. Evaluate different approaches and their tradeoffs.
- **Software Engineering Foundation**: Familiarity with data structures, algorithms, runtime complexity analysis, use of design patterns, design solution with clean abstractions.
- **Domain Expertise**: Understanding of the front end domain and the relevant languages: Browser (DOM and DOM APIs), HTML, CSS, JavaScript, User Experience, Accessibility, i18n, Networks, Performance.
- **Communication**: Ask questions to clarify details and clearly explaining one's approach and considerations.
- **Verification**: Identify various scenarios to test the code against, including edge cases. Be able to diagnose and fix any issues that arise.
## Best Practice Questions
From experience, the best UI interview questions to practice, as determined by frequency and important concepts covered are:
- [Todo List](/questions/user-interface/todo-list)
- [Signup Form](/questions/user-interface/signup-form)
- [Temperature Converter](/questions/user-interface/temperature-converter)
- [Progress Bar](/questions/user-interface/progress-bar)
- [Analog Clock](/questions/user-interface/analog-clock)
- [Job Board](/questions/user-interface/job-board)
- [Whack-a-mole](/questions/user-interface/whack-a-mole)
- [Tic-tac-toe](/questions/user-interface/tic-tac-toe)
- [Tabs](/questions/user-interface/tabs)
- Image Carousel
- Autocomplete
- Dropdown Menu
- Modal
GreatFrontEnd has a [comprehensive list of User Interface coding questions](/prepare/coding) that you can practice in your framework of choice (currently supports Vanilla JavaScript and [React](https://reactjs.org/)). We also provide manual tests cases you can test your code against to verify the correctness and solutions written in the various JavaScript UI frameworks by ex-FAANG Senior Engineers. Automated test cases are not provided for UI questions because they tend to be coupled to implementation and hard for automated tests to test accurately. Moreover, during interviews you likely have to test your UI yourself.
Many of GreatFrontEnd's coding questions are also broken down into stages, which get progressively harder. In interviews, your interviewer might only explicitly request for the basic functionality. However, after you complete the basic functionality, you can take the initiative to add on more features to improve on the basic version and handle more edge cases. An example of a question broken down into stages:
1. [Accordion](/questions/user-interface/accordion): Build a basic accordion that focuses on rendering and show/hide functionality.
1. [Accordion II](/questions/user-interface/accordion-ii): Build an accordion with improved accessibility that has the right ARIA roles, states, and properties.
1. [Accordion III](/questions/user-interface/accordion-iii): Built a fully-accessible accordion that has keyboard support according to ARIA specifications.
Building the basic accordion component might let you pass the interview, but nailing the accessibility aspects will help you score more points and possibly put you at senior level.
Note that we are intentionally vague in some of the questions and don't present the full requirements upfront in the question description. However, we'll cover as much ground as possible in the solution. It may be frustrating while reading the solutions to see that you've missed out some things, but this trains you to think ahead and consider what are the possible areas you have to take note of when working on the solution. Better to find out during practice than during actual interviews.

2
packages/system-design/contents/framework/en-US.mdx
View File

@ -249,7 +249,7 @@ Here's a list of topics you can talk about for this section. Bear in mind that t
- 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.
Refer to our [Best Practices for Building User Interfaces Guide](/front-end-interview-guidebook/user-interface-questions-cheatsheet) for details on each topic.
---