How to prepare for frontend interviews

A frontend specific interview is not the same as a generic software engineering interview. Therefore, the preparation focuses are also different.

In general, a frontend interview follows the same structure as a general software engineering interview, but its coding and system design questions tend to be heavily web specific.

Coding preparation

Practice your Javascript skills and algorthimic skills on bigfrontend.dev. They have a great list of Javascript questions involving deep understanding of web and Javascript. However, there are also some extremely tedious and difficult questions, so here's my recommendation for an efficient preparation:

  1. Focus on the easy and medium question. Don't underestimate the easy questions.
  2. There are a set of questions that are naturally really good questions to ask. They usually have some of the following characteristic: requires knowledge of DOM tree, requires manipulation of DOM, requires knowledge of closure/hoisting, requires knowledge of prototypical inheritance, is a common technique/pattern throughout the industry. Some good examples are: implement debounce, traversing the dom, virtualize the dom, implement a promise and/or its static methods.
  3. Understand the trade offs between different Javascript data structures and algorithm complexities, e.g difference between Map and {}.

If you're really weak on some of the fundamental algorithmic concepts, then Leetcode would be a good place to practice problems with those concepts.

To reinforce the knowledge, I personally would redo a question 3-5 times on separate days to make sure I fully grasp the concept.

UI preparation

You should be familiar with how to write good UI using only html, css, and javascript without leveraging another framework.

  1. Accessibility, e.g semantic tags, aria attributes, keyboard navigation, screen reader, color contrast, font sizes, etc.
  2. Layout organization, e.g flexbox, grid, z-index stack, margins, paddings, etc.
  3. Performance, e.g choosing optimal data structure and algorithms, minimize DOM operations, avoid forced reflow
  4. Widgets, e.g carousel, tooltip, infinite scroll, typeahead, modal, etc.
  5. Reusability, can it scale to other use cases?

System Design

System Design for frontend is very tricky because there are two ways that the question can be presented.

  1. Design a specific component
  2. Design a full stack system

Let's first talk about the technical side of the system design.

It is very helpful to have your own structural approach to tackle a system design question. If you don't know where to start, Front-End Engineer on Youtube demonstrates a great structural approach in their videos. In general, you can simplify it as:

  1. General Requirements (e.g, user facing features and product behaviors)
  2. Functional Requirements (e.g, technical and implementation concerns)
  3. Component Architecture (e.g, diagrams of moving parts within a component or a system )
  4. API Design (e.g, data/schema design, api endpoints, )
  5. Backend Design, usually less details involved (e.g database choice, sharding technique if applicable, CAP)
  6. Optimization (e.g, layered data fetching, server side rendering, caching)

Another big key to doing great on a system design is to actually have experience with it. If you never got the chance to work on a complex system, then you can always read about it. My personal favorites are:

Now let's talk about the social aspect of system design

  • Focus on your strengths. You do not need to know the details of how everything works. For example, if you're good at product UX, elaborate upon it. If you're a performance expert, actively talk about how you would make something more performant. You still want to show that you know how to connect system together, but you don't need to "fake" expertise in another domain. It is very easy to tell when someone don't know what they are talking about.
  • You need to lead most, if not, the entire conversation regarding what features it should have, what trade offs you are making, what kind of architectural design you're thinking of, and the requirements needed for the system/product.
  • You are responsible for making sure that your inteviewer can follow your thought process. I personally would pause about every 5 minutes to ask if the interviewer is still with me.
  • The interviewer is very likely to be biased toward a certain part of the system. If they ask about another part of the system, you should pivot your focus to their ask and only continue with your agenda when they seem satisfied.
  • It is very important to have your interviewer on the same page as you. If you want to dig deep into a certain part of the system, make sure your interviewer is with you. You don't want to spend the entire interview talking about something exciting but the interviewer is completely clueless.

Conclusion

Sometimes, some companies like to ask question(s), which requirs the use of a web framework like React. I'm not going to cover this as it is too framework specific. The only advice I can give here is to always clarify with your recruiter if you will encounter such questions in your interview, so you can better prepare for it.

Good luck!