This is the first post in a series about what to expect in a frontend interview in 2022. We’ll talk through every segment of the interview process and some tips for how to prepare for each.

*Disclaimer*: Every company is different. We can’t guarantee the advice here is relevant to your situation.

You need to ask your recruiter or hiring manager ahead of time what your prospective company’s hiring process looks like. If your company asks whiteboarding or brain teaser-style questions, you’re better off with more traditional interview prep resources such as [Cracking the Coding Interview](https://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/0984782850) and [Leetcode](https://leetcode.com/).

## Structure

Frontend interviews generally follow the same format as other engineering interviews:

1. Informational phone screen
2. Technical phone screen
3. Onsite
4. Offer and negotiation

Your company may incorporate its own elements, but the above format covers 90+% of interviews in our experience.

### The onsite

The onsite is where the bulk of the interview takes place. It’s a 4-6 hour marathon crammed into one day or (increasingly common in remote land) spread across 2 days.

The sections within the onsite will depend on the company’s preferences and your seniority, but you can expect some of the following:

1. Coding challenge
2. Behavioral/cross-functional
3. Systems design
4. Experience
5. Culture fit

We’ll go over each of these sections in detail later in this series.

## Reverse interviewing

Your job during the interview is not only to impress the company; it's also to find out whether the company is a good fit for you. All good interview processes leave room for you to ask questions of your interviewers. Don’t pass these up.

Example questions:

1. What’s your code review process?
2. What does mentorship look like here?
3. How do you prioritize technical debt?
4. What are some of the current technical challenges the team is facing?
5. What does the product roadmap look like for the next 3/6/12 months?
6. What separates average/good/great engineers here?
7. How does your team handle mistakes?

Asking insightful questions also shows the interviewer you care about your work environment and personal development.

**Do:**

- Ask the right people the right questions, e.g. if you're asking about cross-functional collaboration, ask a designer or PM rather than another engineer.
- Ask about things you're genuinely interested in. People can usually tell if you’re feigning interest.
- Ask about things that have come up in your research about the company, e.g. if they're known for a specific program like [Google's 20% projects](https://en.wikipedia.org/wiki/20%25_Project) that attracted you to the company, ask how real these programs are in practice.
- Ask about the company's funding status and IPO/acquisition timelines if you're joining a startup/private company. Some people consider these topics to be taboo, but they're an important part of your compensation. If a company is unwilling to share this information with candidates, it's a red flag.

**Don't:**

- Ask about information you can find company’s landing page. You'll seem unwilling to put in even a bare minimum effort.
- Ask cliché questions such as "What's the best/worst thing about working here?"

## What’s next?

In the next post, we’ll explore how to research your company. Follow [@frontendeval](https://twitter.com/frontendeval) and stay tuned for more!


An overview of the standard frontend interview structure and what questions you should ask your company

Navigating frontend interviews in 2022: an overview, and how to interview your company

Effective company research prior to your interview process will elevate you above your competition as a passionate and knowledgeable candidate. In this post, we’ll talk specifically about what aspects to research and where to look.

This is the second post in a series about what to expect from the frontend interview process in 2022. Here’s where we are in this series:

1. <a href="/resources/navigating-frontend-interviews-in-2022-an-overview">Overview and reverse interviewing</a>
2. Researching your company
3. Informational phone screen
4. The onsite interview — live coding challenge
5. The onsite interview — behavioral
6. The onsite interview — systems design
7. Offer and negotiation

Here are the key areas you’ll want to research in your research about a prospective company:

1. The interview process itself
2. Salary data
3. Recent news and finances
4. Opinions
5. Engineering blogs
6. Competition

## The interview process itself

[Glassdoor](https://glassdoor.com) is one of the only sites that has information about the interview process itself from people that have gone through it.

You may be able to find reviews or details about the specific questions that the company asks. If a question has been leaked on Glassdoor, it’s less likely you’ll be asked that specific question, but knowing what types of questions are asked is incredibly valuable.

## Salary data

If you're lucky enough for your company to be on [levels.fyi](https://www.levels.fyi/), it has the most accurate salary data for companies broken out by level. As of now though, levels.fyi primarily lists public tech companies and prominent Silicon Valley startups.

As an alternative, [Stack Overflow developer surveys](https://insights.stackoverflow.com/survey/2021#work-salary) give salary overviews by location.

As a last resort, check Indeed and Glassdoor. These tend to have outdated and inaccurate data but will at least give you a baseline.

## Recent news and finances

Search [Google News](https://news.google.com/) to see if your company has had any major wins recently, e.g. awards, new product launches, etc.

[Crunchbase](https://crunchbase.com/) will have information about your company’s fundraising rounds. This is especially important if you’re going to a startup. As an example of what to look out for here: if your company has raised a large fundraising round recently, they might be growing quickly, which is something to be aware of. They’ll also be unlikely to run out of money in the near future.

## Opinions

It’s helpful to hear how current and former employees are talking about the company. You may be able to find opinions about your company and its interview process on [Blind](https://www.teamblind.com/), an anonymous social network app.

Note: Blind opinions skew negative, but it can still be a valuable resource. Get what you need and close the app immediately if possible.

## Engineering blog

In rare cases, your company might maintain an engineering blog. These blogs are a goldmine of information about what technical problems your company is solving and how.

You’ll often find information about major architectural decisions your company has made. These are great talking points for your interview.

The blog's existence is also a positive sign your company prioritizes its engineering department.

## Competition

Lastly, it’s important to understand where the company fits among its competitors.

Search your company on LinkedIn and check out the companies in the "People also viewed" sidebar. Try and look at those companies' landing pages to see what makes your company unique in its competitive space.

## Wrap up

Look for opportunities to surface all this research organically during your interview process. Some example questions during the interview of when to bring up this information:

1. “Tell me about what you’re looking for in your next role”: talk about how your goals fit into the company’s history and where it’s going
2. “Do you have any questions for me?”: ask about news that you’re interested in (e.g. "I heard you recently adopted React Native, would love to hear more about that decision").

In short, you want to come off as someone who cares about the company and will accept an offer if you receive one!

## What’s next?

In the next post, we’ll explore what to expect from your first phone screen. Follow [@frontendeval](https://twitter.com/frontendeval) and stay tuned for more!

A guide on what aspects of your company to research and where to find information

Navigating frontend interviews in 2022: how to research your company

Your first call with a company will always be a “get to know you”-type call. Here’s what to expect and how to prepare for it.

This is the third post in a series about what to expect from the frontend interview process in 2022. Here’s where we are in this series:

1. <a href="/resources/navigating-frontend-interviews-in-2022-an-overview">Overview and reverse interviewing</a>
2. <a href="/resources/navigating-frontend-interviews-in-2022-how-to-research-your-company">Researching your company</a>
3. Informational phone screen
4. The onsite interview — live coding challenge
5. The onsite interview — behavioral
6. The onsite interview — systems design
7. Offer and negotiation

This call will take place with a hiring manager/recruiter. Their goal is to:

1. hear about your resume and story in your own words
2. gauge your interest in the company
3. understand your rough salary expectations
4. field your questions
5. (sometimes) get a rough idea of your technical ability

Let's go over each of these one by one:

### Your story

You'll usually be asked to talk about yourself and your resume ("Tell me about yourself"). Keep this succinct, 2-3 min max. Have a summary ready of the highlights of your career history.

Focus on roles that changed your career focus, or where you hit growth spurts in your development. Talk through what interests you now and where you might want to end up in the future.

If you're talking with a recruiter, don't deep dive on technical jargon. Know your audience.

Lastly, if you're uncomfortable doing this, **do not wing it. Write it out and practice!**

### Your interest

Your company will want to get a sense of how serious you are about the job. Hiring and interviewing is an enormous drain on the company’s resources, often requiring 20+ hours per candidate, depending on how far they advance. They want to know if you’ll have a good chance of accepting a potential offer.

Show that you've researched the company. See our [an earlier post in this series](https://frontendeval.com/resources/navigating-frontend-interviews-in-2022-how-to-research-your-company) about this for more information.

More and more companies consider themselves to be mission-driven, meaning they claim to use tech to drive public good. It's critical for you to express alignment and interest with the mission if this is the case for your company.

Note that if you fake this passion through the interview, you'll be expected to fake it the entire time you're at the company. You'll need to decide in advance if that's worth it to you.

### Your salary expectations

Salary often comes up in the first conversation. This isn’t the time for white-knuckle negotiation. It's a high-level conversation to see if your expectations are in line with the company's budget.

Your recruiter will always want you to name your price. Avoid doing so if at all possible. Negotiation disadvantages the party that names the first number, an effect known as “anchoring”.

Instead, try to get them to go first. Ask something like "what did you have in mind when posting this job?". If they still force you to name a salary, give a target range based on your market research.

Avoid giving your current salary at all costs. It limits your bargaining power. In some states, it's illegal for your employer to even ask about your current salary.

Frame the conversation around your target salary if you can.

See [this article at Nolo](https://www.nolo.com/legal-encyclopedia/can-a-prospective-employer-ask-for-my-current-or-past-salary.html) for more details and advice.

The most important thing here is not to lowball yourself. Don't think "I'll start low to get through the process and convince them to give me more money later". They won't.

Be honest with yourself. Make sure you settle on a range you’d be comfortable accepting. If not, the interview isn’t worth your time (unless you’re in it for the practice).

### Your questions

This is the time to ask how the interview process will go:

1. Whom will I speak to?
2. What kinds of questions will they ask me?
3. How long can I expect the process to take?
4. When will I hear back from you about next steps?

### (Sometimes) Pop-quiz style technical questions

I see this happening less and less, but some companies will ask short-answer interview questions during this call. This might happen even with a recruiter, who will write the answers down and relay them to a technical counterpart

There are a lot of Github repos that have these questions. Study them if you're seeing these questions a lot.

PS: this is a pretty silly way to assess engineering ability but if your company is using it, you have to play ball.

Example repos:
1. https://github.com/h5bp/Front-end-Developer-Interview-Questions
2. https://github.com/learning-zone/html-interview-questions
3. https://github.com/learning-zone/css-interview-questions
4. https://github.com/learning-zone/javascript-interview-questions

### Summary

Prepare to:

1. Tell your story about your engineering journey
2. Express why you're uniquely interested in the company and their mission
3. Find out whether your salary requirements might be a good match
4. Get details about the rest of the process
5. Answer pop-quiz style interview questions

## What’s next?

In the next post, we’ll look at the bread and butter of programming interviews: the live coding challenge. Follow [@frontendeval](https://twitter.com/frontendeval) and stay tuned for more!

What you’ll talk about when talking to a recruiter or hiring manager

Navigating frontend interviews in 2022: the informational phone screen

The behavioral interview is conducted by other engineers or people that work closely with engineers. The goal is to assess whether you handle tough situations in a way that’s consistent with company culture.

This is the fourth post in a series about what to expect from the frontend interview process in 2022. Here’s where we are in this series:

1. <a href="/resources/navigating-frontend-interviews-in-2022-an-overview">Overview and reverse interviewing</a>
2. <a href="/resources/navigating-frontend-interviews-in-2022-how-to-research-your-company">Researching your company</a>
3. <a href="/resources/navigating-frontend-interviews-in-2022-informational-live-coding-challenge">Informational phone screen</a>
4. <a href="/resources/navigating-frontend-interviews-in-2022-onsite-interview-live-coding-challenge">The onsite interview — live coding challenge</a>
5. The onsite interview — behavioral
6. The onsite interview — systems design
7. Offer and negotiation

Behavioral interviews **are typically geared towards mid-level or senior engineers**, but you may encounter them early on in your career.

The company’s goal with behavioral interviews is to assess:

1. How you resolve conflict or differences of opinion
2. What your communication style is like
3. Whether you’re an empathetic person
4. Whether you can explain technical concepts to less technical people

## General tips

### 1. Understand the culture

Look for a vision/values/culture page on your company’s website. If it’s there, make sure you read it.

If they have a detailed page that a designer clearly put thought into (e.g. [Netflix](https://jobs.netflix.com/culture), [Airbnb](https://careers.airbnb.com/), [Amazon](https://www.amazon.jobs/en/principles)), culture is extremely important to them. Don’t just read: **memorize** this page.

Tie these values into your answers at every opportunity.

### 2. Don’t use hypotheticals

People want to hear about your concrete experience. Avoid saying things like “I would” do this or that. Even if your interviewer doesn't challenge you on this type of speculation, they’ll dismiss your answers as fluff.

Many people swear by the [STAR framework](https://en.wikipedia.org/wiki/Situation,_task,_action,_result). Following this framework keeps your answers anchored in past behavior.

### 3. Reflect on conflict

In our experience, interviewers are particularly interested in how you deal with conflict. Prepare several examples of how you dealt handled disagreement with coworkers.

### 4. Keep it brief

Don't talk for more than 90-120 seconds at a time. If you find yourself going deep on a topic, pause and offer to go on if the interviewer wants to hear more.

### 5. Pay attention to job title

The interviewer's job title provides critical guidance as to what they're looking for, even if they ask generic questions.

* Product managers want to hear you tie your work to business outcomes
* Designers want to hear that you care about shipping pixel perfect designs
* Other engineers want to hear that you make good decisions and are easy to work with

## Example questions

The specific questions you'll get asked will vary depending on which function(s) you're talking to. Here are a few examples:

### Product managers

1. How have you worked with product managers in the past? How have you resolved disagreements with them?
2. Tell me about the last time you missed a deadline. How did you communicate it? How did you mitigate the negative impact?
3. What project management methodologies have you worked with before (e.g. Scrum/Agile, waterfall)? What did you like or dislike about them?

### Designers

1. Design and engineering can be at odds with one another, with designers proposing ideas that may not be performant, accessible, or easy to implement. How do you weigh trade-offs between achieving fidelity with the designs and technical constraints?
2. Tell me about the process of working with designers in your current role. What does the communication cadence look like? Who does what in the relationship?
3. Have you enjoyed working with designers in the past?
4. Tell me about the pros and cons of design systems. Have you worked with them in the past? What did you like about them?
5. Tell me about some websites or apps that you feel are particularly well-designed. What makes them well-designed?

### Other engineers

1. What makes for an effective code review?
2. What's your preferred method for aligning with your team on controversial decisions (e.g. adopting a new tool, library, or coding standard)? What's worked particularly well for you?
3. How do you approach disagreement with other engineers? What are the right avenues to communicate your disagreement?
4. What's your favorite/least favorite thing about being an engineer?
5. What are the immediate steps you would take when you're notified of a critical issue in production?
6. When you launch a new feature, how do you ensure it continues to work as intended?

## What’s next?

In the next post, we’ll take a brief look at systems design interviews. Follow [@frontendeval](https://twitter.com/frontendeval) and stay tuned for more!

How to communicate that you’re good at communicating

Navigating frontend interviews in 2022: onsite interview — behavioral

The live coding challenge is your quintessential "programming interview". You sit with a laptop and work on a problem in front of your interviewer. It’s not enough to be good at coding, unfortunately. Live coding is its own skill.

This is the third post in a series about what to expect from the frontend interview process in 2022. Here’s where we are in this series:

1. <a href="/resources/navigating-frontend-interviews-in-2022-an-overview">Overview and reverse interviewing</a>
2. <a href="/resources/navigating-frontend-interviews-in-2022-how-to-research-your-company">Researching your company</a>
3. <a href="/resources/navigating-frontend-interviews-in-2022-informational-phone-screen">Informational phone screen</a>
4. The onsite interview — live coding challenge
5. The onsite interview — behavioral
6. The onsite interview — systems design
7. Offer and negotiation

## Tactics

A few tactics you can use to maximize your chances of success:

1. Clarify the requirements first
2. Share an outline of your approach
3. Talk A LOT
4. Get it working before optimizing
5. Practice, practice, practice

Let's talk through each of these:

### 1. Clarify the requirements first

Take notes while your interview is giving the prompt. Avoid asking them to repeat themselves.

If you hear the prompt and start coding right away, you’ve almost certainly made a mistake. Ask questions to make sure you’ve understood the details.

Think through edge cases in advance. If you’re building a UI, think about invalid user input, error messaging, different screen sizes.

If you’re doing a more backend JS problem, think through the different range of inputs, e.g. invalid data types, negative numbers, empty arrays, null, etc.

Ask your interviewer what edge cases your solution needs to cover.

Interviewers (intentionally or unintentionally) leave things vague. Clarifying requirements is your job as an engineer. Do it during the interview too

### 2. Share an outline of your approach

Before you start working, talk through what you’ll solve first and where you anticipate running into problems

This has 2 benefits:
1. It clarifies your own thinking
2. It helps the interviewer follow your train of thought

Oftentimes, interviewers will offer guidance when you get stuck. If you don't provide an outline, they may have no idea what direction you’re taking and be unable to help.

### 3. Talk A LOT

The worst way to solve a live coding challenge is silently. These challenges assess your communication as much as your coding.

There should rarely be long stretches of silence. If you’re sitting silently staring at your screen, talk about what you’re thinking about.

As a hiring manager, I'd rather hire someone who gets 75-80% of a problem right and is a great communicator than someone who nails the problem and doesn't talk at all. No one wants to work with someone who has all the answers and can’t/won’t explain themselves

### 4. Get it working before optimizing

As with many things in life, it’s easier to bang out a rough draft then go back and edit. So don't worry about code cleanliness or performance on your first pass.

Getting a working solution is going to earn way more points than beautifully-optimized code that doesn't solve the problem.

In the vein of “Talk A LOT“, explain that this is your approach before you go about it. Most interviewers will assume this is what's going on, but better to be explicit

### 5. Practice, practice, practice

Coding in regular conditions is quite different than coding in a high-pressure, timed environment with someone looking over your shoulder and expecting you to talk the whole time

There are a few sites where you can do mock interviews with peers or experts, free or paid:

* [Interviewing.io](https://interviewing.io/) (paid)
* [Exponent](https://www.tryexponent.com/) (paid)
* [Pramp](https://www.pramp.com/) (free)

## Interview styles

In our experience, there are two flavors of problems you're going to deal with:

### Leetcode-style

This style of interview is based on sites like [Leetcode](https://leetcode.com/) and [Hackerrank](https://www.hackerrank.com/). You can expect to find questions such as “find the contiguous subarray of an array that produces the largest sum in the most efficient way possible”. In other words, stuff you **never** do as a frontend engineer.

Companies often put artificial constraints on you during these questions: no Googling or running your code. Your company may even have you write code on a whiteboard. It’s mind-boggling that companies are still asking people to write code on a whiteboard in 2022, but it still happens.

Thankfully, this style of interview has fallen out of favor with many companies assessing frontend candidates. However, it’s still popular for historical reasons. Interview culture takes a long time to change.

It's worth noting that the types of questions that a company asks about during its interview process says a lot about the types of talent it attracts and retains.

If your company is relying on coding challenges like this, it's not actually testing whether or not someone is good at frontend development prior to hiring them as a frontend developer. You may join a company only to find that no one around you knows how to write CSS.

### Practical

Companies are increasingly simulating your work environment as best as possible in their interviews. What this looks like specifically is:

1. Code in whatever IDE/editor you want: VSCode, Sublime, Atom, Emacs, vim, etc.
2. Look up whatever you need to look up on Google, Github, Stackoverflow, etc.

This type of question allows companies to get more of a sense of how you perform in the normal course of doing your job. It also allows them to ask more complex questions in the UI/UX sense.

Quick pitch for the exercises on [frontendeval](http://frontendeval.com) to help prepare you for these questions.

Other than general guidance about practicing, here are a few things to pay attention to when you search for information:

1. **Never** copy and paste code you find on Stackoverflow or anywhere without carefully reading it and understanding what it does. It reflects extremely poorly on you if you fail to consider the context and limitations of code you’re introducing into your solution.
2. For the same reasons as thinking out loud when you code, don't search in silence. Talk through your process and tell your interviewer what you're looking for.

## Remote interviews

COVID has moved so much of tech corporate culture online so you may end up doing this interview remote. Also, regardless of whether your “onsite” interviews are in-person or remote, you’ll likely have one technical phone screen as well that takes place remote.

The above resources in “Practice, practice practice” will have you interview remotely, so you’ll get some practice with this if you follow this guide.

Specifically, ask your interview what tools you’ll be using for remote interviewing: a remote coding tool or screensharing your own environment.

### Remote coding tool

[Coderpad](https://coderpad.io/) and [Codepen](https://codepen.io/) are among the more popular tools used to issue remote coding challenges, although there’s a broad ecosystem of other tools.

Most tools for this purpose are intuitive to use, but you're going to want to familiarize yourself with them in a high-pressure time-sensitive context. The two tools listed either have free or demo versions, so get comfortable with them in advance.

Things to look into:

1. Keyboard shortcuts
2. Adding libraries
3. Syntax highlighting and auto-indent nuances
4. How to run and debug code. Codepen in particular has a not-so-obvious console feature that doesn’t show errors.

The tool used for your interview is often a giveaway of what the type of problem to expect. If the tool has a visual component with HTML/CSS, like Codepen, you may be asked to implement a UI. If the tool has only a code component (and potentially a console for running the code), you'll be doing a JS-only problem.

### Screensharing your computer

Some companies allow you to use the environment on your own computer to complete the coding challenge. This is a good opportunity to showcase how productive you are in your particular editor/IDE.

Get used to screensharing your entire computer screen if you’re used to only sharing a specific window. If you’re allowed to look at documentation or Stackoverflow, your interviewer will want to see your search process as well. You may need to switch between terminal, editor, and browser frequently.

Remember to silence your computer's notifications and close all your other browser tabs to avoid any embarrassing situations.

## Wrap up

Just to reiterate one more time: live coding is very different from your day-to-day job. It exercises different skills, and you need to practice it!

Note: none of this is an endorsement of live coding as a way to assess candidates. There is plenty of research on how the timed elements bias the interview process. But these things aren't going away anytime soon. We want you to be set up to succeed regardless of how silly they are.

## What’s next?

In the next post, look at how to prepare for behavioral interviews. Follow [@frontendeval](https://twitter.com/frontendeval) and stay tuned for more!

Tips for how to ace everyone’s least favorite part of software engineering interviews

Navigating frontend interviews in 2022: onsite interview — live coding challenge

I have been interviewing a lot for the past year - not conducting interviews, I was the candidate being interviewed. Most of the interview processes I had with big tech companies consisted of 1-2 system design rounds depending on the level of the role. Unlike traditional **backend-focused** system design questions, for which you can find lots of prep resources online such as the famous [grokking system design interview](https://www.educative.io/courses/grokking-the-system-design-interview) or [system design primer](https://github.com/donnemartin/system-design-primer), I didn’t know what to expect for a **frontend-focused** system design interview as there are very few resources out there talking about this type of interviews.

Now that I have done a fair amount of system design interviews of both types, I want to give you a summary of what to expect, especially for the frontend ones since I have been mostly working on the frontend side.

Similarities
-------------------------------------------------------------

Both frontend-focused and backend-focused system design interviews share a lot of similarities in terms of the methodology you can adopt to solve the design questions:

* starting with gathering system requirements
* laying out a clear plan and identifying major distinguishable components of the system
* proceeding to end to end api design
* talking about optimization

Other kinds of similarities include:

* The interviewer is relying on you to drive the presentation. You can't rely on the interviewer to have your back.
* While the topics can be either micro or macro, you probably won’t need to actually write code - it is rare to jam some portion of coding in the middle of a system design interview
* Unlike scantron school exams, both types will consist of mainly open ended questions. There probably isn’t a checklist of things for you to cover one by one. Nor are you expected to drill deep into all of those. When you realize your interviewer is biased toward a particular part of the system, which they usually do, pivot your focus to that area. Other times you focus on your strengths and lead the conversation.

Differences
-----------------------------------------------------------

During the backend-focused system design interviews, you would spend most of the time talking about things like:

* backend/server side architecture, hand waving various backend services/components

* discussing which type of database to use and how to aggregate data across different shards

* designing SQL table schema

* choosing the right the cross-region strategy if your service has a global user base

* any other kinds of system characteristics like latency, availability, fault tolerance, etc.


For frontend-focused system design interviews, you would spend most of the time talking about stuff like:

* frontend/client side architecture, such as the appropriate rendering pattern to choose - client side rendering, or server side rendering or static generation or something in between?
* What kind of data fetching mechanism to use - REST vs. GRAPHQL vs. gRPC and what should the APIs look like?
* Specifics about UI components
    * a newsfeed which has an infinite scroll behaviour with all the images lazily loaded while ensuring the client side has the aspect ratio of the images upfront to prevent layout shift.
    * an autocomplete UI component which fetches search result data incrementally in batches while receiving images from server pushes in parallel.
    * a gallery page which pulls images and displays them in the correct order despite the asynchrony that comes with the network requests that might cause them to arrive out of order.
* How do you leverage different layers of cache to decrease latency or support offline mode.
* if they want to get framework-specific, which is totally possible, they might even ask you to define a particular React components’s props or manage complex state in a React app.

A lot times having one type of system design interviews means you can over simplify the opposite side:

* In a backend system design interview, the client-side/frontend is reduced to an API layer - you don’t need to consider all the intricacies of the browser or the pesky rerenders your real-time updates would cause.

* In a frontend system design interview, you can treat the backend as a black box and you don’t need to worry about how things like how to scale a database, or how your choice of using web sockets might affect the load balancers because of the need for sticky sessions support.


> But again, this is a summary of my experience and depending on who your interviewers are (are they frontend, backend and/or fullstack devs), the scope of the role and which team it is (are you going to be on a frontend team or are you expected to work across the stack and stretch into the backend?) your front end system design interview might be a bit of a hybrid where some aspects of backend system design interviews might come up.

Outside of the differences with the technical topics I needed to dig deep into during the interviews, I found there are two other interesting differences that stand out between the two types:

* For frontend system design interviews I was often encouraged to treat the interviewers as the **product manager** and we spent some time just fleshing out the brief solution for each user story. For the backend system design interviews, we didn’t really get to talk about any user interaction (I am aware that the definition of users of your system might vary, depending on whether it is customer-facing vs. developer-facing)
* These two types of system design interviews also differ a lot in terms of _estimating_ certain system's needs based on the potential scale of the system. The system needs can be storage needs or throughput needs or any other types of requirements.
    * It is common and expected to do these estimation during backend system design interviews since your design decision is only feasible when all of the system needs can realistically be met.
    * But for the frontend system design interview, I rarely needed to do any **quantitative estimation** - for example, when I was designing some live feed during a frontend system design interview, I didn’t need to do estimations like “_So let’s say each message was roughly 140 characters long and it is utf8 so that’s 140 bytes and an average user gets 10000 messages over a certain period of time so we ended up allocating 1.4mb memory on user devices_”. Again, I am not saying that this would never come up during a frontend system design interview. in my experience It is just much, much more rare compared to backend ones.

Career Ceiling
-----------------------------------------------------------------

> I am going to talk about something that is a little tangential. I don't think this is going to be a hot take but if you just want to pass the upcoming interviews, then you are welcome to skip this part.

I have done interviews for both frontend focused roles and general software engineer roles. As I went through the preparation process for the system designs interviews, it just occurred to me that there is indeed a career ceiling for a pure frontend focused software engineer role.

Ok so let’s first get this out of the way - you can be extremely successful as either a frontend dev or a backend dev.

Also it is hard to discuss any topic intelligently when we cannot agree on definitions. By saying frontend devs I meant developers/engineers who solely work on the UI of a software system. And by saying career ceiling I meant the potential terminal title and the highest level such a dev/engineer can achieve in the technical individual contributor track.

This is an unspoken thing and a very impolite conversation. And [there are exceptions](https://twitter.com/swyx/status/1236023548227072000) to this but just statistically speaking there seems to be a career ceiling for frontend-only devs.

#### Fighting the inertia

Part of the ceiling comes from some traditional baggage:

* modern frontend development is fairly new compared to the backend counterpart. I have seen some bias in the industry that frontend is not real engineering compared to the backend and that needs absolutely to be combated.

* power structure persists for a very long time and that’s partially why most of VP Eng and CTOs out there are backend/infra devs.


#### Economic reasoning

I had this realization that when I was going through the backend system design interviews vs. the frontend system design interviews - the technical topics those interviews tend to cover let me think about some economic reasoning leading to the perception of a "Frontend Ceiling” as well. Your value to the company really depends on how many machines/compute/storage run through **you**. As a dev/engineer, that means much money you control and frontend-only devs just don’t take as much. Of course frontend is just as hard and as important especially for consumer facing products but at the end of the day your compute is being run on someone else’s machine or device and the company just don’t value that as much as the compute that they themselves need to pay for and to scale.

#### Short-lived vs. Long-running

On top of that, normally the frontend/web apps are short-lived on the client side - the user opens the browser tab that loads your app and after 20 minutes they might just close the tab, and all the memory allocated by your app is on their devices from that point onward. On the other hand, the backend servers/services behind probably keep running for months or even years. One implication resulting from this difference is that you can generally get away with bad code that leads to performance problems down the road in frontend apps because they are short-lived and the scale of the data they are dealing with is probably small, but you cannot ignore that in a long-running backend service.

Good luck with your interviews.


Walk through the similarities and differences between frontend vs. backend system design interviews

Resources

Navigating frontend interviews in 2022: an overview, and how to interview your company

Navigating frontend interviews in 2022: how to research your company

Navigating frontend interviews in 2022: the informational phone screen

Navigating frontend interviews in 2022: onsite interview — behavioral

Navigating frontend interviews in 2022: onsite interview — live coding challenge

Frontend vs. Backend System Design interviews