diff --git a/packages/front-end-interview-guidebook/contents/algorithms/en-US.mdx b/packages/front-end-interview-guidebook/contents/algorithms/en-US.mdx new file mode 100644 index 000000000..3fc7bd9db --- /dev/null +++ b/packages/front-end-interview-guidebook/contents/algorithms/en-US.mdx @@ -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) | + +* `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. | + +* `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. | + +* `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(n2) 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. diff --git a/packages/front-end-interview-guidebook/contents/coding/en-US.mdx b/packages/front-end-interview-guidebook/contents/coding/en-US.mdx new file mode 100644 index 000000000..45ec9f2d4 --- /dev/null +++ b/packages/front-end-interview-guidebook/contents/coding/en-US.mdx @@ -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. diff --git a/packages/front-end-interview-guidebook/contents/javascript/en-US.mdx b/packages/front-end-interview-guidebook/contents/javascript/en-US.mdx new file mode 100644 index 000000000..e8792d1f9 --- /dev/null +++ b/packages/front-end-interview-guidebook/contents/javascript/en-US.mdx @@ -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(n2) 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. diff --git a/packages/front-end-interview-guidebook/contents/overview/en-US.mdx b/packages/front-end-interview-guidebook/contents/overview/en-US.mdx new file mode 100644 index 000000000..2361bd971 --- /dev/null +++ b/packages/front-end-interview-guidebook/contents/overview/en-US.mdx @@ -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) diff --git a/packages/front-end-interview-guidebook/contents/quiz/en-US.mdx b/packages/front-end-interview-guidebook/contents/quiz/en-US.mdx new file mode 100644 index 000000000..48c5b9181 --- /dev/null +++ b/packages/front-end-interview-guidebook/contents/quiz/en-US.mdx @@ -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, ``, ` +``` + +**jQuery refresher**: jQuery UI's `slider()` method (constructor) takes in a JavaScript object which serves as customization options. Doing `$('#slider')` selects the `
` 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 +
+ +``` + +### 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
...
; +} + +; +``` + +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(); +``` + +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 ( +
+ +
+ ); +} + +; +``` + +```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 ( +
+ + +
+ ); +} +``` + +#### 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 ( +
+ +
+ ); +} + +; +``` + +```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 ( +
+ + +
+ ); +} +``` + +```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 ( +
+ + +
+ ); +} + +; +``` + +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 ( +
+ + +
+ ); +} +``` + +```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. */} diff --git a/packages/front-end-interview-guidebook/contents/user-interface-questions-cheatsheet/en-US.mdx b/packages/front-end-interview-guidebook/contents/user-interface-questions-cheatsheet/en-US.mdx new file mode 100644 index 000000000..406f8bae8 --- /dev/null +++ b/packages/front-end-interview-guidebook/contents/user-interface-questions-cheatsheet/en-US.mdx @@ -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 `
`s for everything! +- **Heading hierarchy**: Ensure heading tags have a hierarchy and there's not more than one `

` in the DOM. +- **Interactive elements**: Use `