Frontend system design interviews - the definitive guide to approaching them

Learn how to approach the frontend system design interview in 2022. A behind the scenes look at what big tech companies are looking for.

Introduction

Top tech companies are in desperate need of experienced frontend engineers. These companies are looking for frontenders that have knowledge in the architectural and software engineering principles, that years ago were mainly associated with backend developers.

It's becoming more common for these companies to have system design rounds focussed 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 there many great resources that focus on the backend domain, there seems to be few resources that go into depth on how to approach frontend system design interviews. In particular, resources that are grounded in what companies are actually looking for in candidates.

The frontend world moves fast. Frameworks come and go, and patterns fall in and out of style as we learn together as a community. Despite the rapidly evolving frontend landscape, companies from startups to big tech companies are looking for a particular set of common attributes in candidates.

These are the attributes that go beyond the current frontend technology trends. And make you an effective engineer whatever tech stack you find yourself using. Understanding how you can 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 goes into detail on what each of these attributes are, and why they are important for frontend software engineers to have. 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 on how to tackle and prepare for the frontend system design interview, and be equipped with the following:

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

• Know what specific signals an interviewer is actively looking for, that go beyond specific technologies, and how to prove you have them throughout the interview.

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

• Understand the heuristics for generating good questions.

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

The attributes interviewers are looking for are necessary for frontend engineers to have at all levels, but especially so as you reach more senior levels in your career. The framework outlined in this guide also applies to approaching ambiguous problems more generally.

With that out the way, let’s get into it and have you nailing your next frontend system design interview.

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.

You might be stronger or weaker in some depending on what level you are interviewing for. 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 top engineers that companies naturally screen for as part of their hiring process. So let's see how they play out in the context of the frontend system design interview.

Problem solving ability

Alright captain obvious. Let's break this down concretely. What this means in practice:

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 break down the problem into smaller distinct pieces. Such that they can be solved individually such that you can piece them back together to solve the larger specific problem you have articulated.

Humans usually don’t solve vague problems all at once in a big chunk. So we'll need to start with a solid understanding the problem we are solving first. So we can then begin to identify how to break it down.

We don't want to waste time creating solutions for problems that don't exist, or solutions to the wrong problem.

In the context of the frontend system design interview, knowing what questions to ask in each phase of the interview 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.

Technical proficiency and knowledge

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

Before going into the interview, 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. The use-cases it supports, and maintain an awareness of what it doesn't currently support.

As you begin to break down the problem into separate smaller problems - the solutions to those smaller problems will in practice 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 allows 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 to? 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's always time constraints.

In real world projects at tech companies there's 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 are assessing your ability to make 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.

Often in real projects you’ll likely need to move forward 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 into the next attribute.

Adaptability

This attribute touches on both "soft skills" as well as the hard skills in designing systems and frontend components that are adaptable to change. It's your ability to respond to changes in requirements. In practice this relies on two things:

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

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.

For both low level component API design and high level frontend system design, a lot can be said on ways to achieve long term adaptability. This is a topic unto itself (so stay tuned and subscribe to the newsletter for future upcoming posts on this topic 😅).

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 in relation to these as you progress through the interview. These 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.

A some questions to keep in your back pocket as you design

• What can possibly go wrong here?
• What are the specific failure modes?
• What does the user experience when things fail?
• What does the user experience when backend is slow ?
• How will we know if things have gone wrong?
• How will we know if what we built is successful?
• How will we handle 100X more data on this screen or component?

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

Product and design sense

Frontend engineering is a highly collaborative role. We work closely with designers, product managers, and backend engineers. Being able to view a particular problem through the lens of each of these disciplines is empowering. It allows you to view a problem space with 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.

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

The frontend applications we are building end up being 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. There are many established patterns you can utilize whenever we can’t fit something into the screen at once.

Some example UX patterns for fitting more stuff into the screen

• virtualized list
• paginated tables
• tabs
• scroll view
• drawer
• master-detail pattern
• full page navigation
• modal
• combo box
• collapsible section

The more broad your knowledge is in this area the more likely you can think up 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 compared to the 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, these are red flags you definitely want to avoid during the interview.

It’s good to be aware of them so you can course correct 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 interviewers are assessing your technical communication and collaboration skills in conjunction with your technical proficiency.

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

While it’s a collaboration, you’re in the drivers seat, and its your job to drive the interview forward towards 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 move through each step in a methodical manner.

Later on in this guide, we’ll go over how to structure your overall approach the the interview, and how to break the interview itself 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 where you don't. It shows humility, and shows 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 show case your technical proficiency and knowledge in areas where you are strongest. Unless the interviewer explicitly asked to go deeper into a particular topic it's better to direct the conversation to areas you are most comfortable.

For example it would be challenging to do a deep dive and talk through the different problems you might face when building a responsive site that also needs to support left-to-right, and right-to-left languages if you’ve never worked on an app that requires mobile responsiveness or internationalization.

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:

• 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 stages of the interview outlined below, you’ll want to be aware of both the amount of time being spent in one section and the concrete design artifacts you need to create for each section.

Creating design artifacts and building momentum

The main tool used in frontend system design interviews is the whiteboard. Utilizing it effectively means you’ll want to be able 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 design on the whiteboard. It's also a shared understanding between you and the interviewer of what the overall solution is along with 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 it in your head. If you’re a technical lead on a team providing this space for input is essential.

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 the solution explored. Creating design artifacts on the whiteboard as you move through each section of the interview will help you build momentum and confidence throughout the interview.

Next up we'll dig into what the distinct stages are 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, where you will introduce yourselves and the interviewer will give you your question.

Your goal here is to listen closely to understand the the problem being presented. The question will either be a high level design question, or a lower level design of a frontend component. It's likely the the question will relate some how 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.

Examples of high level design questions

• “How would you go about designing a chat application like Slack?”
• “How would you build a photo sharing application like Instagram?”
• “How would you design a rich text editor ?”

Examples of low level design questions

• “How would you go about designing an infinite scrolling newsfeed?”
• “How would you design a combobox / typeahead component ?”
• "How would you design a loading progress bar for an API?"

Requirements gathering

Your goal during this stage of the interview 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 of system as part of your job, and the interviewer is a product manager that you work with.

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

The example questions below are definitely not exhaustive. But hopefully give you an idea on 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 employees accessing an internal system from company hardware and networks. Versus a 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 responsive, 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 into in the interview.

From 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 a number of 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.

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

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

Can explore approaches to testing, observability, analytics and 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 all in depth.

So you’ll need to scope things down, proactively call out considerations as they come up, and focus 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 in the time of 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 of how you plan to structure the time available in the interview and what you will focus on.

The artifacts you create on the whiteboard in this phase will be a list of requirements. Mostly likely a list of bullet points, with the 2-3 main use-cases highlighted as 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 on 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 towards 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.

Non-exhaustive list of some additional considerations:

• Security - How do we make the app secure for end users? Where are the potential vulnerabilities?
• Accessibility - How do we make the system accessible for all types of users?
• Performance - How do we ensure the app is fast? How do keep it fast as more features get added and changed?
• Delivery - How do we efficiently bundle and send the code down to the user?
• Testability - How do we know the application doesn't have critical bugs and can be changed with confidence?
• Resiliency - What are the failure modes? How can we gracefully handle errors when the unexpected happens?
• Observability - How do we know the application is working as expected?

The maintainers 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 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 frame 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 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. If you are interested in seeing this framework applied to real questions, stay tuned by signing up to the newsletter at the end of this guide.

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, so 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.

To recap this phase of the interview

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 be 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.

If you would like to see examples of applying this framework to a set of real world problems you can sign up to the newsletter Frontend Mastery monthly newsletter.