Front End Interview User Interface Coding Questions — How to Prepare
Guide to preparing for User Interface questions in front end / web developer interviews — Concepts to know, interview rubrics, and important practice questions.
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.
The time allowed for apps/games questions are 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.
Observe that most games will be 2D grid-based games. Make sure you know how to create grid layouts in HTML and CSS!
User Interface coding interviews share a fair bit of similarity with non-front end coding interviews. In general, you should:
- 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 execute code and preview the UI.
- Whether you can install dependencies beforehand.
- Make your self introduction under a minute. Unless requested, do not take longer than this otherwise you might not have enough time to code.
- Ask clarifying questions upon receiving the question. Clarify the following:
- Browser support, as this will affect the browser APIs you can use.
- 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 around the component states and APIs as opposed to complex data structures and algorithms.
- 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.
- Follow our User Interface Best Practices for a list of things to take note of during User Interface coding interviews.
- After coding, read through your code once and try to spot basic errors like typos, using variables before initializing them, using APIs incorrectly, etc.
- 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.
- Explain any tradeoffs you made, cases you explicitly didn't handle, and how you would improve the code if you had more time.
- 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.
- Be familiar with the topics under the "Important Concepts" below. The Quiz section can also be a good start since you might be asked on these concepts in the form of quiz questions during coding.
- 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 when writing your classes.
- Read our User Interface coding deep dive guides:
- Pick a study plan and practice the User Interface coding questions 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.
|Data Structures||Arrays, Maps, Stacks, Trees, Sets|
|Software Engineering||SOLID Principles, Design Patterns, Model-View-Controller|
|HTML||Semantic HTML, Form validation/submission|
|CSS||Box model, Selectors, Specificity, Positioning, Units, Flexbox, Grid, CSS custom properties (variables)|
await Handling variadic arguments
|DOM||DOM traversal, DOM creation, DOM manipulation, Accessing element/node properties, Event delegation|
|Runtime APIs||Timer (|
setInterval), Network (Ajax,
|Accessibility||ARIA roles, states, and properties, Keyboard interactions|
- 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.
- 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.
Many of our 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 which improves the product. An example of a question broken down into stages:
- Accordion: Build a basic accordion that focuses on rendering and show/hide functionality.
- Accordion II: Build an accordion with improved accessibility that has the right ARIA roles, states, and properties.
- Accordion III: Built a fully-accessible accordion that has keyboard support according to ARIA specifications.
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 stuff, but this trains you to think ahead and consider what are the possible things you have to take note of when working on the solution. Better to find out during practice than during actual interviews.