Frontend system design interviews - the definitive guide

Introduction

Top tech companies are in desperate need of experienced frontend engineers. These types of companies are looking for frontenders with knowledge of architectural and software engineering principles, that have historically been associated with backend developers.

It’s becoming more common for these companies to have system design rounds focusing on the frontend domain as part of their hiring process. These types of interviews are common for both experienced and entry-level roles.

A lack of resources for frontenders

The frontend system design interview shares many similarities with the traditional backend system design interview, specifically in how they are structured.

While many great resources focus on the backend domain, there seem to be few resources that go into depth on how to approach frontend system design interviews. In particular, resources are grounded in what companies look for in candidates.

These are the attributes that go beyond the current frontend technology trends. And make you an effective engineer in whatever tech stack you use. Understanding how to demonstrate these attributes can go a long way when practicing and preparing for the frontend system design interview.

About this guide

This guide aims to provide a framework for the frontend system design interview, grounded in the specific attributes companies are looking for.

The first half details each of these attributes and why they are important for frontend software engineers. Not surprisingly, these attributes transcend just the interview process and the frontend domain. They are also ones you can continually focus on developing as you progress towards more seniority as a frontend developer.

The second half then provides the framework for approaching the frontend system design interview. And outlines how you can demonstrate each of these attributes as you move through the different stages of the interview.

By the end of this guide, you will have the knowledge to tackle and prepare for the frontend system design interview and be equipped with the following:

• Be aware of what questions to expect in frontend system design interviews.

• Understand the specific signals an interviewer is looking for that go beyond particular technologies. And how to prove you have them throughout the interview.

• Learn how to take ambiguous problem statements and break them into manageable chunks.

• Understand the heuristics for generating good questions.

• Confidence in approaching your next frontend system design interview, knowing you can work through it step by step in a systematic way.

These attributes interviewers are looking for are necessary for frontend engineers to have at all levels, especially as they reach more senior levels in their careers. The framework outlined in this guide also applies to approaching ambiguous problems more generally.

What companies are looking for behind the scenes

We’re about to dig into all the attributes top tech companies are looking for when hiring frontend engineers.

They are attributes companies would expect an experienced frontend engineer to have. Depending on the level you are interviewing for, you might be stronger or weaker in some areas than others.

But you’ll want to have these in the back of your mind when practicing, so you can communicate in such a way that shows you possess these attributes when going through the interview.

As we will see further on, the interview can be broken down into distinct stages, and in each stage, you’ll have a chance to show these attributes to the interviewer. These attributes also tend to overlap with each other somewhat.

These are the foundational “hard to fake” qualities of experienced engineers that companies naturally screen for as part of their hiring process. So let’s see how they play out in the frontend system design interview context.

Problem solving ability

Alright captain obvious. Let’s break this down concretely:

1. Your ability to deeply understand the problem/s enough that you can clearly articulate a specific problem statement/s to be solved.
2. Your ability to break down the problem into smaller distinct pieces. Such that they can be solved independently, so that you can piece them back together to solve the larger specific problem you have articulated.

As humans we’re not great at solving vague problems all at once in a big chunk. So we need to find ways to break things down, that starts with a solid understanding of the problem we are solving first.

We also don’t want to waste time creating solutions for problems that don’t exist, or solutions to the wrong problem (often by misunderstanding the actual problem).

In the frontend system design interview context, knowing what questions to ask in each interview phase is a core part of demonstrating this attribute. Understanding the problem space in detail begins with asking the right questions. Which then allows us to break down the problem further into smaller pieces.

This also helps us know what things to optimize for when the time comes to make a difficult decision or trade-off. Later on, we will expand more on some guidelines on how to ask good questions.

”If I had an hour to solve a problem and my life depended on it, I would use the first 55 minutes determining the proper question to ask, for once I know the proper question, I could solve the problem in less than five minutes.” — Albert Einstein

Technical proficiency and knowledge

Frontend system design interviews are very open-ended, and the initial question is often vague. This is usually true for high-level questions and lower-level component design exercises. This is intentional because interviewers assess your ability to explore a problem space, as much as your ability to produce a solution.

It’s a helpful framing to understand that there are no solutions, only trade-offs within a given context. Even when arriving at a specific solution, you’ll want to understand its strengths and weaknesses. Including the use cases it supports and the ones it currently doesn’t.

As you break down the problem into smaller problems, the solutions to those smaller problems will be solved by specific frontend patterns, technologies, protocols, and techniques.

As you identify solutions to problems, what’s important here is your ability to discuss, or at the very least mention, trade-offs upfront with multiple different approaches.

Your technical knowledge and proficiency in the frontend domain allow you to make informed decisions regarding patterns, technologies, and various architectures. All while understanding their limitations and strengths for the given problem at hand.

Ability to drive a solution to completion

At what granularity should we break things down? How many possible solutions should we enumerate and analyze?

While there is no “right” answer to those questions, a pragmatic answer is “enough so you can move forward confidently with the information you have available”. Because there are always time constraints.

In real-world projects at tech companies, there are usually tight deadlines. In frontend system design interviews, it’s around one hour. So as you break things down and enumerate potential solutions, you’ll need to make decisions and drive the interview to a working solution.

For each sub-problem, there will be multiple options with different trade-offs. In practice, we move things forward by making informed decisions and committing to a course of action.

There’s a delicate balance here. Interviewers assess your ability to progress through the design question without getting stuck in paralysis by analysis. But on the other hand, charging ahead with the first solution that comes to mind and not mentioning other potential options is also a red flag.

You’ll likely need to move forward in real projects and make decisions based on limited information. So understanding the trade-offs with a given approach is important. Knowing how the current design can evolve over time to support future requirements that aren’t an immediate priority now is even better. This leads us to the following attribute.

Adaptability

This attribute encompasses both “soft skills” related to personality and “hard skills” required for designing high-level architectures and adaptable lower-level frontend components. It refers to your overall ability to respond to changing requirements, which in practice relies on two factors:

1. Not being dogmatic about a particular approach, pattern, or technology and being open to discussion. Also, feeling comfortable being challenged without getting defensive. Viewing the interview as a collaboration between you and the interviewer is helpful.

2. Understanding the trade-offs and limitations of a given approach (a common theme in this guide). Without this, you are effectively blind to how the system can evolve over time. Understanding the use cases a particular design supports is important, but for large complex systems, understanding the use cases it doesn’t currently or can’t support is just as important. A lot can be said here about ways to achieve long-term adaptability for both low-level component API design and high-level frontend system design.

Operational awareness

This is your ability to consider all the things outside the immediate working solution. It includes things like resiliency, performance, accessibility, testing, observability, security, scale, etc. in your design. And calling out any concerns concerning these as you progress through the interview.

Here are some are useful questions to have in the back of your mind so you can proactively call things out as you go along, even if you don’t end up digging into them in depth.

You can probably think of many more questions whose answers are not without trade-offs. There is a lot to consider for a production ready system, too much for a one-hour interview to go in-depth on all of them. But it’s useful to maintain an operational awareness beyond the immediate solution. Your ability to think in terms of the wider context surrounding the solution and not use just the solution itself is a good way to demonstrate your experience in frontend system design questions.

Product and design sense

Frontend engineering is a highly collaborative role. We work closely with designers, product managers, and backend engineers. Viewing a particular problem through the lens of each of these disciplines is empowering. It allows you to view a problem space through many different lenses. And avoids the “if all you have is a hammer, everything looks like a nail” issue highly specialized people tend to have.

General knowledge of UX trends and patterns is also useful because they open up different ways of solving a particular problem. It goes a long way if you can proactively identify potentially poor user experiences, bottlenecks, or issues with the UI design.

The frontend applications we are building are expressed in a particular style of common user interface elements. Having knowledge of general UI patterns and their trade-offs from a UX perspective can help you think of different solutions and weigh them up.

As one simple example, if you’re asked a scaling question, such as how would we handle 1000X of whatever it is we are rendering. One way of thinking about this is to only show what is relevant to the user and to defer and hide what is not immediately relevant. You can utilize many established patterns whenever we can’t fit something into the screen at once.

The broader your knowledge in this area, the more likely you can think of solutions to problems. Or even better, avoid whole classes of problems by taking a different approach to the end user experience if possible.

In practice, this attribute is weighted less in frontend system design interviews than in previous ones. But nonetheless, one to keep in mind due to the highly collaborative nature of frontend engineering.

Things to avoid

We now have a good grasp of the different attributes to focus on demonstrating concretely. On the flip side, you definitely want to avoid these red flags during the interview.

It’s good to be aware of them so you can course correct them if you catch yourself unintentionally exhibiting any of these, either from nervousness from the pressure of the interview or lack of real-world experience to draw from if you are going for a junior role.

Jumping straight into solution mode without probing clarifying questions

This is probably the most common mistake candidates make for both coding and system design interviews.

Not being collaborative

Keep in mind that interviewers are assessing your technical communication and collaboration skills with your technical proficiency.

This is weighted more heavily in frontend system design interviews. The last thing you want to do is be dismissive of a question or challenge from the interviewer without providing any technical reasoning.

While it’s a collaboration, you’re in the driver’s seat, and it’s your job to drive the interview toward a reasonable solution. But at the same time, you need to be receptive and open to feedback, as they will likely give you helpful hints along the way.

Being all over the place

Without the right framework on how to approach system design interviews, it can be common to jump from one thing to do next in an unstructured way. This is about sticking to one thing at a time and moving through each step methodically.

Later in this guide, we’ll go over how to structure your overall approach to the interview and how to break it down into sections to work through. And how much time you should be roughly spending on each section. This provides structure to the interview and can help you avoid this.

Don’t bullshit if you’re not sure

Sometimes you might simply be stumped by a question. If you don’t have knowledge of a particular area, it’s better to be open about your lack of experience rather than trying to pretend you do.

If you get caught in this situation, showing vulnerability is better than pretending you have knowledge in an area you don’t. It shows humility, and you are open to trusting others’ opinions which is critical for working in teams.

Not playing to your strengths

The frontend domain has many sub-specializations within it. You can go incredibly deep on any number of topics. With only around an hour in the interview, you want to try and showcase your technical proficiency and knowledge in areas where you are strongest. Unless the interviewer explicitly asks to go deeper into a particular topic, it’s better to direct the conversation to areas you are most comfortable.

What to expect in the interview

Now we have a good idea of what interviewers are looking for when running these interviews and what to avoid. Let’s switch our attention to the interview itself.

Most frontend system design interviews will be centered around either a high-level design question, like “how would you go about building instagram?”, or a lower-level design question, like “how would you go about designing and infinitely scrolling newsfeed?”

Generally, the format for a one-hour interview will look roughly something like this:

• Initial intro and question ~ 5 minutes
• Understanding the problem and requirements gathering ~ 5 minutes
• The design phase ~ 25 minutes
• Optimizations, adaptability, deep dive questions. ~ 20 minutes
• Ad-hoc questions. ~ 5 minutes

As you move through the interview stages outlined below, you’ll want to be aware of both the amount of time spent in one section and the concrete design artifacts you need to create for each section.

Creating design artifacts and building momentum

The primary tool used in frontend system design interviews is the whiteboard. Utilizing it effectively means you’ll want to show a clear thought process by taking what’s in your head and laying it out in structured sections.

If the input to a frontend system design interview is a vague question. The output is a clearly defined set of requirements, prioritized use cases, a high-level plan, and a design on the whiteboard. Additionally, it’s a shared understanding between you and the interviewer of the overall solution and its pros and cons.

This ability is an important skill to have when working on a team when designing features. Providing this structure for the team allows others to chime in with ideas versus just having them in your head. Providing this space for input is essential if you’re a technical lead on a team.

At the end of the interview, ideally, you could hand over the whiteboard to someone else, and they would have a high-level understanding of what is required, and a good idea for the solution explored.

Creating design artifacts on the whiteboard as you move through each interview section will also help you build momentum and confidence throughout the interview.

Next, we’ll dig into the distinct stages in the frontend system design interview. Along with what tangible design artifacts we should be focussed on creating in each stage.

The interview format

General problem statement and overview

The initial introduction to the interview usually goes for a few minutes, during which you will introduce yourselves, and the interviewer will give you your question.

Your goal here is to listen closely to understand the problem being presented. The question will either be a high-level design question or a lower-level design of a frontend component.

The question will likely relate somehow to the product the company builds. Or a specific highly used component within the product. So doing some initial practice runs using the company’s product you are applying for can help get you in the right frame of mind before the interview.

Requirements gathering

Your goal during this interview stage is to explore the problem space with the interviewer. You want to collect a list of functional and non-functional requirements. As you dig for requirements, make sure to listen for any hints. In most cases, they will deliberately leave the initial question vague. In other cases, they may explicitly tell you what area to focus on.

Guidelines for gathering requirements

The best way to get a solid set of requirements is to ask good questions. The best way to generate good questions is to start with the users of the component or system in mind.

Thinking about who the users are, how they will access the system, and what they will do once they can use the system can help you get started generating many various considerations.

One way to frame it is if you are tasked with designing this feature as part of your job, and the interviewer is a product manager you work with.

Starting with these questions from the end-users perspective will help you find the primary use-cases for designing and can lead you to explore a wide range of factors that need consideration.

The example questions below are definitely not exhaustive. But hopefully, give you an idea of how asking about the users can lead to identifying what the main functional and non-functional requirements will be.

Who are the expected users of this system?

For example, there is a big difference if we expect the users to access an internal system from company hardware and networks versus anyone with a computer and internet connection.

How will users access this system?

This is a broad question that can go down lots of different paths. What devices are they most likely to access it with? This question brings up a wide range of considerations. E.g., accessibility, mobile responsiveness, low power CPU devices.

Once they’ve accessed the system, what are they most likely to do?

A web application may have hundreds of different features available to users. This is a good question that helps prioritize the top two or three use cases to design for in the next phase of the interview.

What are the main use cases they will use the system for? Use this question to focus your main efforts on the interview.

Where are they likely to access it?

Brings considerations in networking strategy and offline support. Will they be in different counties? On the subway with spotty connections? How will we handle internationalization?

How will our frontend application be delivered to users?

Seems simple on the surface, but there are several considerations here. From how the application is deployed - bundling and build pipelines, touching on approaches to different rendering architectures.

How many expected users are there?

This opens many considerations around scale both for high-level design questions and low-level component API design.

How will we know users can successfully use the system as we intend?

Can explore approaches to testing, observability, analytics, error monitoring, and resiliency through graceful degradation.

By just asking simple questions about the user, we have already encountered a large number of considerations.

There may not be enough time to mention all the considerations in a one-hour interview, let alone discuss them in depth.

So you’ll need to scope things, proactively call out considerations as they arise, and focus on diving deep into particular areas where you are strongest.

Recapping the requirements gathering phase

You’ll have three main goals in this phase before moving into the design phase:

1. Define the functional and non-functional requirements. Start asking about the end user. This will likely generate more potential considerations than is possible to cover during the interview.

2. Define the scope of the interview. Work with the interviewer to identify the top 2-3 core use cases of the component or system to focus on for the design phase.

3. You can also optionally propose a course of action and outline how you plan to structure the time available in the interview and what you will focus on.

In this phase, the artifacts you create on the whiteboard will be a list of requirements. Most likely, a list of bullet points, with the 2-3 main use cases highlighted as the top focus.

• For specific use-cases, it might be helpful to phrase them as user stories like “as a user, I want to upload a photo and see it displayed on my feed”, or “as a user, I want to type my search query into this box and see a list of suggestions”. These act as generic problem statements you can then start to break down.

• Bullet list of non-functional requirements and considerations.

• Numbered list of how you plan to approach the interview in stages. Shows your plan of attack and gives the interviewer confidence you can break down an ambiguous question and drive it toward a solution. Also provides a chance to get early feedback on what areas the interviewer may be looking to explore.

High level architecture design

You’ll have the top use-cases of the system or component as you move into this phase of the interview.

There are no hard and fast rules here. But one way to think about structuring this phase of the interview is taking a top down approach. It can be helpful to start high level from the top with basic wire-frames, and then depending on how you prefer to think about things, work from a top down perspective to flesh out those details, or work from the bottom up.

Starting with basic wire-frames can help you understand the problem of the particular use-case you are solving and get on the same page as the interviewer. A good approach from there is identifying the abstract data entities that power the specific use-case.

The design artifacts you’ll create for both high and low level designs typically include but not limited to:

• High level wire-frame to define the problem and to confirm you on the same page as the interviewer.
• Data entities - e.g pseudo code of type definitions for data entities.
• Break down of wire-frame into individual components, identifying their hierarchy and composition.
• The higher level APIs those components rely on.
• Both user and system initiated events use that interact with the data entities that power the functionality of the use-case.

Guidelines for high level designs

As you being to design solutions to use-cases it’s helpful to be constantly asking - “what is the user trying to do here?” to help frame your solution. Asking this helps prevent creating solutions to problems that aren’t relevant and helps you stay focussed on driving a solution forward that keeps things simple.

As you practice on real examples it’s good to keep things simple. No need to over-complicate things. The majority of times solutions won’t be ground breaking new designs. A “good enough” solution is one where it solves the specific use-case in front of you, and you have analyzed it’s trade-offs and called out any potential limitations. This is much better than an over-engineered solution that attempts to solve everything at once.

It can be helpful to apply different lenses to look at the problem from different view points. Especially if you get stuck or not sure how to move things forward. Switching lenses can help you enumerate different potential solutions and considerations that apply to your solution.

The users viewpoint

Thinking in terms of how the user will actually use the system, and being able to visualize that, can help uncover edge cases and different user experiences you may need to take into consideration.

For example, when navigating away from an infinite scrolling list, when the user comes back would they expect the scroll position to be in the same spot of the list when they went back?

Thinking about the small details like this from the users first person experience can help uncover implementation details you’d need for a high quality solution. While you are not expected to solve every single problem or consideration that comes up, identifying potential problems ahead of time goes a long way.

The architects viewpoint

In the frontend system design interview it’s useful to work with your interviewer and make a few assumptions about your users so you know what trade-offs to make as the architect of the system. It’s always useful to base things on what users actually do.

As a real world example, we may implicitly make the assumption users will be using our frontend application in long lived sessions. And so when deciding on a appropriate rendering architecture we land on a client side rendered SPA. Trading off initial page load time for a faster post loading experience.

But what if that initial assumption isn’t correct? For example, perhaps the main entry point into the app is via link in an email notification that something has updated or requires action. And in practice users often do full page loads, and have relatively short lived sessions. In that case you might want to consider optimizing for a faster initial page load based on how the users actually use the system.

This is a random example, but remember everything is a trade-off. And what is the “right” trade-off will come back to who is using the component or system you are designing and how they actually use it.

The maintenance viewpoint

As you design in this phase it’s good to proactively call out how things can fail or break, or potentially be a bad user experience.

For example if you’re talking about network communication, you can bring up things like retries, error states, loading skeletons for slow network communication etc.

How will we know if something is broken? What kinds of monitoring can we put in place to ensure our experience is working correctly and in a performant way? What does fault tolerance mean for this user interface? You don’t necessarily have to go dive deep into them, unless the interviewer asks, but just mentioning them as you go helps demonstrate your operational awareness.

For lower level design questions, this means thinking about how the API can be adapted over time. What happens when we want to reuse, copy or adapt specific aspects of this component with another in a separate part of the app? Does the abstraction allow for that? How easy is the component to adopt and use as a consumer?

Recapping the high level architecture phase

Your goal here is design solution for the main use-cases identified in the requirements gathering phase. To recap:

1. Solve the problem in chunks. With the specific use-cases acting as the entry point for further technical breakdown.

2. To get started, you can frame the use-case by drawing simple wire frames so you and the interviewer are on the same page. Before committing to a particular solution you can ask yourself “what is the user trying to do here?” And “what does it look like for this use-case to be solved?” Keep it simple.

3. Identify the underlying (data) entities that powers the use-case.

4. Identify the individual pieces and components that will utilize those entities.

5. Identify the higher level APIs those pieces will need, in order to make the use case possible (in practice typically CRUD interfaces).

These are just some guidelines to help you get started. The best way to feel confident about this phase is to go work through real problems you are likely to encounter.

Optimizations, deep dives and adaptability questions

Alrighty, we’re in the final stages of the interview now. Let’s finish strong.

In this phase the interview will usually switch to a phase where the interviewer asks more probing questions. They will typically end up being how you would adapt the design to meet a new set requirements. Either functional, like “how would we go about supporting real time collaboration?” or non-functional, like “how would we go about supporting 100x more data for larger customers?”.

This is a good chance to demonstrate your technical depth on a particular subject and your adaptability. There’s no hard and fast rules here. What you discuss will depend on what the interviewer wants to probe more on. But it’s very likely the topic of frontend performance will come up. So you’ll want a solid understanding of performance fundamentals if you lack real experience in this area, to ensure you can discus this aspect in depth.

Here are some example questions you might expect to see in this phase of the interview:

“A customer has raised a support ticket about bad performance and you are tasked to investigate, what do you do ?”

Similar to the initial question they will usually be open ended to see how you take an ambiguous problem statement and drive towards a solution. In this case they’re looking for general debugging ability and performance knowledge. Which can roughly be broken down to:

1. Reproducing reliably.
2. Narrow down. Identify the type of slowness e.g browser rendering performance or an I/O operation being slow.
3. Identifying the root cause.

The principles are the same, narrow down until you find the root cause, enumerate options to solve the issue, identify their pros and cons and make an informed decision on how to move forward.

”A backend API is slow, however the backend team is flat out and does not have the bandwidth to fix the problem this quarter, what can you do on the frontend to alleviate the pain of this?”

Again a good way to explore a problem space is to ask things about the user. Based on this, you could ask things like “How important is it for the user to see the latest data immediately?”

In this case you wouldn’t go wrong to discuss different strategies that can be used to improve perceived performance. High lighting different strategies like pre-fetching upfront at the appropriate time, and various caching strategies.

”We now need to support real-time collaboration, what needs to change on the frontend?”

Sometimes you’ll get a question that requires you to adapt your existing design to new requirements. These types of questions will also be pretty open ended. So like we did with the initial question, we’ll want to identify the foundational changes required, and focus our attention on those.

In this case, switching to a real-time system would very likely change both how and what data is sent back and forth between the client and server. So we could focus our attention on the network communication and discuss different potential approaches such as web sockets, server sent events vs long polling and the pros and cons of each as a starting point.

”We have a requirement that customers need to support third party plugins - how would the design need to change in order to support this?”

Similar to the question above, you’ll want to narrow things down to the core challenge posed by this new requirement and solve that first.

In this case because third party plugins would involve running other peoples untrusted code, you wouldn’t go wrong starting with how to make things secure, and how specific technologies like iframes etc can provide the properties an end solution would need.

Recapping the optimization phase

In this phase of the interview you will be asked some form of optimization question that either deep dives into a particular aspect in more detail. Or how the system can be changed to support new use-cases. Performance is a popular topic in this phase.

In the case of changes to requirements, for each requirement change, you can suggest multiple methods and enumerate their pros and con, and estimate the impact this change would have on the rest of the system. What else would need to change? What assumptions have now been broken?

Putting it all into practice

Well done if you’ve made it this far. This guide was written to help you think about the frontend system design interview at a higher level. Breaking down what tech companies are actually looking for, and how to structure your approach to the interview when working through practice problems. Goodluck.

Additional resources

Here is a non-exhaustive list of resources to help get you started as a refresher.