Prepare for the Frontend Interview in 50 Hours

If you believe technical interviews are a bunch of 💩, you are not alone. These interviews are like performances where engineers prepare for weeks or months to put on a handful of shows for companies looking to hire. I realized during my time preparing for interviews that there are so many different topics to prepare for and that the resources for those are scattered across so many different places, if they exist at all. Many people have asked me where to begin, how much time to spend on each topic, and what different companies value. I created this guide in hopes of helping you get the most of your preparation time and beat the technical frontend interviews by providing a list of specific commonly encountered topics and questions to prepare for.

Unfortunately for frontend engineers, algorithms and LeetCode aren’t the only things standing between us and our dream jobs. In an effort to diversify the range and practicality of questions, many companies started doing the so-called “frontend interview” where HTML, CSS, and JavaScript knowledge is also required. The companies that do not have frontend specific interviews will likely put candidates through their generalist interview. In order to do well in all interviews and maximize the number of competing offers across different companies, candidates have to prepare for both generic algorithm problems and frontend scenarios, increasing the amount of knowledge and preparation the candidates need.

The estimated 50 hours in this guide assumes you have frontend experience and a good understanding of data structures and algorithms. The time amounts to roughly 1–2 weeks of full time studying and applying for jobs or 4 weeks of part time prep after work or on the weekends.

Types of questions

I prioritized this list according to how much each topic potentially weighs on your overall interview performance and the amount of improvement you can gain by preparing for it.

The hours is a rough estimate of how you can split up your 50 hours of prep time.

1. Frontend working knowledge — (5 hours) This comes in many shapes and forms including take-home projects and recreate-this-design live interviews
2. Data structures and algorithms — (25 hours) Leetcode style problems
3. Async programming and JavaScript specifics — (5 hours) Managing callbacks and events along with functional programming paradigms
4. Data manipulation — (2 hours) Transform one shape of data into another
5. Systems design — (10 hours) Frontend and backend systems design
6. Behavioral — (2 hours) How do you react in certain scenarios? What qualities do you have?
7. Frontend trivia —(1 hours) This is like playing jeopardy with HTML, CSS, and JavaScript where you answer questions about esoteric knowledge
8. Company specifics — (0+ hours?) Netflix culture?

Frontend working knowledge

Prep 5 hours

I put this before data structures and algorithms because this portion is often done as a technical phone screen or take home project earlier in the interview process. This is the one topic that should be most similar to the work you have been doing but that doesn’t mean you can completely skip preparation. Many of the requirements, including using vanilla JavaScript with no frameworks, will be different than what you are used to at your current workplace. Startups and less technical companies tend to value this part of the interview a lot. Because this is very similar to actual work, poor performance here is detrimental to your candidacy and heavily impacts leveling potential for frontend specific roles during hiring committee review.

Recreate-this-design interview

During an on-site or phone screen, the interviewer may ask you to create something in code given a design or list of specifications. More often than not, this interview also serves as a frontend systems design interview as well.

• Log viewer (Squarespace 2018) — Create a scrollable view that renders log entries and details
• Poker cards (Airbnb 2019) — With a deck of cards, shuffle the cards, generate a poker hand, and display the cards
• Phone input (Stripe 2019) — Format an input such that numbers typed in are rendered like (123)456-7890

Tip #1: Ask questions to clarify the scope of the problem you solve for. The specifications you received is most likely incomplete. Is the list API paginated? How can users interact with the UI? Should it be designed for mobile? Your interviewer will likely have a more comprehensive rubric to grade you with.

Tip #2: Componentize wisely. Instead of writing one big chunk of code, break down the individual pieces and discuss how certain components could be reused.

Tip #3: Talk through performance. Consider how API loading impact your interface and how user experience can be improved with placeholders and loading indicators. Prioritize loading the most important part of the interface first if possible.

Tip #4: Consider accessibility. Does the interface support keyboard or touch navigation? Are the elements using the correct HTML tags with proper attributes?

Take-home project

A take-home project is sometimes used instead of a phone screen and consists of building a more complex app. It most likely comes with a blank slate or a very minimal skeleton to get started. There will also be a fairly lengthy set of instructions and specifications to follow. These take-home projects are not too common anymore because grading takes a similar amount of time as an interview and plagiarism is a common concern.

• Snake game (Squarespace 2018) — Create a snake game with HTML, CSS, and vanilla JS
• Hangman Solver (Hulu 2015) — Programmatically solve hangman by hitting an API endpoint with letter guesses
• Movie list (Vimeo 2016) — Given a movie list API, render the list of movies, make a popup for movie details, and animate it’s transition

Tip #1: Attribute code you have copied in the comments. If you found a function to generate a random string from StackOverflow, paste the link as comments in the code and briefly explain why. The grader will understand that you don’t want to spend 15 mins implementing UUID when the project is creating a todo list.

Tip #2: Do not borrow code in its entirety. If the company asked for a todo list, do not follow a tutorial for todo list in React. It is pretty obvious to the grader when the code is copied because others may have also copied from the same few tutorials with the same potential bugs.

Tip #3: Go a little above and beyond if there is no hard time limit. If you passed the suggested time limit and you barely finished, take some time to make the code and the user interface look good. I almost never hear of submissions being penalized for taking a little extra time. Often, I see feedback praising code cleanliness and good documentation even though these are pretty quick to fix and write. On the other hand, if you are way overtime, it is a sign that the role you applied for isn’t the right fit for your current skillset and that you need to prepare a lot more.

How to prepare

Practice using vanilla JavaScript as well as your most familiar library. After using React, Angular, or Vue, many engineers often forget the browser APIs such as addEventListener, getElementById, and fetch. While it is possible to look up documentation during your interviews sometimes, your problem solving speed will be impacted and you risk not finishing in time.

1. Create a formatted input such as a phone input — Use HTML and vanilla JavaScript to listen and handle changes to the input element.
2. Create an animated progress bar — Use only CSS to animate progress change. Make the animations smooth if updates are called before the previous animation finishes.
3. Create an infinite scroll feed with pagination — Think of this as building the Twitter or Facebook UI. The feed should detect when scroll is near the bottom of the list and call an API to fetch more data. Feel free to mock the backend paginated API.

Data structures and algorithms

Prep 25 hours

As an engineer, companies expect you to be able to code. While I personally disagree that frontend engineers need to know paradigms such as greedy algorithms, dynamic programming, and discrete math by heart, most companies have at least one data structures and algorithms interview in their frontend interview process.

Depending on the company, some committees may allow an otherwise strong frontend candidate to progress with a mediocre algorithm interview. Others will reject everyone who did not pass.

The trick to passing these interviews is being fluent in data structures as well as identifying potential algorithms quickly. Most problems are variations of the same few underlying algorithms so it’s better to aim for deeper understanding of a few major variations rather than sheer quantity of problems completed. Make sure you practice using JavaScript too.

Commonly used data structures

1. Arrays — These are mutable lists in JavaScript. Helpful methods include concat, slice, splice, indexOf
2. Maps — 1:1 mapping of unique key to value, can be built with Map() or plain JavaScript object {}. Helpful methods include Object.keys(), Object.entries(), Object.values(), for (let key in obj) { ... }, {}.hasOwnProperty(). If you use a plain JS object, note that there are built-in prototype methods such as constructor that may interfere with your keys.
3. Stack — First in, first out ordered data store, use an Array with push() and pop().
4. Queue — Last in, first out ordered data store, use an Array with unshift() and shift().
5. Set — Check for uniqueness, Set() has methods that include has() and add(). Use Array.from(set) to convert to an array. Alternatively, use Map().
6. Tree or graph — Use JavaScript objects as nodes, pointers don’t exist in JavaScript.
7. Trie — Tree where nodes have many children nodes that could correspond to characters in the alphabet. Very useful for finding words or patterns such as anagrams, palindromes, and word search puzzles.

Commonly used concepts

1. Greedy algorithms —Make optimal local decisions until a full solution is found, i.e. knapsack problem, task scheduling
2. Dynamic programming — Build on previous solutions to find new solution, i.e. Fibonacci sequence calculation, array subset
3. Search and graph traversal — Traversing through nodes or arrays, i.e. binary search, depth first search (DFS), breath first search (BFS), Dijikstra’s shortest path, and topological sort

Algorithm Complexity

The different data structures and algorithms have widely different ways to access data. To compare the speed of each algorithm, a commonly used measurement is called the Big O notation which measures how many times each element is accessed. Refresh your memory with the Big O Cheat Sheet.

How to prepare

Leetcode is probably the best known online resource for practice. I highly recommend the paid Leetcode subscription for their solutions and company specific problems ranked by frequency. If you need a quick refresher on programming concepts, Cracking the Coding Interview is a good book to review. If you never had a formal computer science education or never taken an algorithms class, I suggest taking a full algorithm course online. It will help you understand the general problem solving techniques instead of memorizing solutions to specific problems.

• Opinionated list of Leetcode questions to cram —This is the minimum you should spend time on. The 19 problems should take about an hour each on average to study and complete depending on difficulty. I have been asked by various companies every problem in the “Cram Level 1” section and a few in the rest as well. If you don’t have much time to prepare, work through these, read the different solutions, and make sure you can solve them on your own in JavaScript.
• Curated list of top 75 Leetcode problems — This is a more expanded set that covers a bigger breath of topics. Even if you don’t have time to work through these problems, it’s helpful to read the prompt, think about how to solve it, and understand the approaches to different solutions.
• Leetcode Premium company specific questions — If you have more time to practice, go into the lists of questions for each company you are interviewing for and sort the list by frequency and work from the top down. All 5 of the problems listed under Square were asked during my interview in 2019, 3 of which were hard level problems that I could have better prepared for had I known about it. The Google and Facebook problems are pretty accurate too. The subscription pays for itself if you land a higher paying job.

Generally, most companies will ask 2 easy or 1 medium difficulty questions per interview. Hard questions are rare. You should aim to finish Leetcode medium problems in 20 mins and hard in 40 mins during your practice.

Tip #1: Be honest and let the interviewer know if you might have seen the problem before. It is very obvious to an experienced interviewer anyway. You should still go through the same steps as you would normally in explaining and solving the problem.

Tip #2: Always talk through the problem solving strategy first before coding. Start with the brute force case, then optimized solutions. Talk though the complexity in O(N) for all of them. Sometimes the interviewer is looking for a specific solution.

Tip #3: If you have no idea how to get to an optimal solution, quickly code the brute force solution and work on optimizing that. Be receptive to the interviewer’s hints.

Tip #4: If you don’t think you can finish the most optimized solution in the allocated interview time, mention this to your interviewer. They might ask you to code the most important part of the optimized solution first or complete a less optimized approach from start to finish.

Tip #5: When you are truly stuck during an interview, think out loud and list all the different data structures and algorithms you know. Sometimes the interviewer will drop hints when you list each one.

Async Programming and JavaScript Specifics

Prep 5 hours

Asynchronous programming is at the heart of JavaScript and code execution in the browser so a lot of companies now test for understanding of this fundamental concept. Many companies use an async problem in place of an extra algorithm based problem for frontend candidates as well. While good performance here can help your candidacy, a bad one will impact leveling potential. Most hiring managers think of async programming as something that can be learned, although it would take a strong algorithm performance to offset a weak interview here.

If you are struggling, Eloquent JavaScript has a great section about async.

How to prepare

Implement these in vanilla JavaScript:

1. Promise (WeWork 2019, Flatiron Health 2019)— Implement a Promise that accepts callbacks and executes them in the order they are chained with. For added challenge, implement one that allows parallel functions to execute and waits for all of them to finish. Do not use the built-in Promise.
2. EventEmitter (Jet.com 2019, TwoSigma 2019) — Create an event emitter object or class that can be subscribed to using callback functions according to the event name. When an event with a specific name is fired, all functions that were attached to that name should be executed. Each subscription can be unsubscribed as well. Do not use the built-in EventEmitter.
3. Throttle/Debounce (Google 2016, Jet.com 2019)— Create a function that limits the frequency of a function called within a specific time frame. Implement leading and trailing as well. Remember to cancel when the async function is no longer needed.
4. Chaining timeouts (Google 2016)— Given a list of functions and their respective timeouts, execute each function one after another after the previous timeout ends. Be sure to cancel the timeouts if the function is no longer needed. For added bonus, allow arrays of functions that run in parallel.
5. Function currying (Squarespace 2016, Jet.com 2019)— Write a counter that can be repeatedly incremented like add(1)(2)(10)(4) infinitely.

Data Manipulation

Prep 2 hours

Like the async programming section, you probably use these utility functions often but rarely implement from scratch. It’s a matter of dedicating a little bit of time to practice so your execution is perfect when it comes time for interviews. These are often used as phone screens.

How to prepare

Implement these Lodash functions in vanilla JavaScript and compare your solution to their source code on GitHub:

1. flattenDeep (Facebook 2019) — Given nested array of elements, remove the nesting so that all the elements are placed in a single array.
2. merge (Jet.com 2019) — Given two objects, merge all the keys from one object into the other.
3. map (Facebook 2019) — Given an array and a function, return the list of results from applying the function to each element in the array.

If you need more practice, try implementing other Lodash functions.

System Design

Prep 10 hours

This interview is the bread and butter of engineers who want to land a job at a senior level or above and also the most important technical interview for determining candidates’ leveling. Candidates that do well on the systems design interview can potentially land a level higher than what the years of experience entails. Similarly, a bad one will almost always result in a under-leveled offer or even rejection.

System design is about architecting scalable, performant, and maintainable systems given a set of requirements. Sometimes, the given requirements are meant to be vague in order to gauge candidates’ ability to deal with uncertainty. Other times, the requirements can be more stringent to see if candidates can work within certain constraints. It is also important to understand how people and processes work with these systems as well.

I’ve found that the best way to learn about frontend systems is to keep up with current technology by reading technical blogs and watching conference talks. I personally subscribe to React Status, Frontend Focus, and JavaScript Weekly. I’ve also attended in person and watched videos from Fluent, React Europe, React Amsterdam, JSConf Berlin, and Chrome Developer Summit. All of these conferences upload past talks onto YouTube for others to watch for free.

Frontend Systems

There are two different areas of focus in frontend systems interviews, design systems/reusable components and web app architecture. The design systems interview will ask you to architect a complex reusable component, usually popup tooltip or input forms that comprise of many simpler components. The web app architecture will ask you to create the frontend for a popular web app such as Twitter or Gmail. Often times, the conversation starts in one of these two areas and touch upon the other as well. Unfortunately, I have yet to find a good one stop resource for learning about these frontend topics so here’s a list of relevant information I’ve gathered over the years.

• Design Systems — There are so many examples of component libraries and design systems out in the wild. Read the principles behind these systems and why systems are made a certain way. Take note of the simplest pieces such as token values and atoms, how they build into more complex inputs and buttons, and put together to form a user interface.
• Atomic Design — Brad Frost is one of the first to coin the term for the hierarchies of reusable components in user interfaces. He recently wrote a lengthy but insightful book about design systems and the processes and talent necessary to maintain it in large organizations. This talk is a good high level overview of design system challenges.
• React as a UI Runtime — What does React do under the abstraction that their APIs provide? You are expected to understand what frameworks do and provide an informed opinion on how it compares to alternatives you are familiar with.
• Progressive Web Apps with React — A good frontend system in 2020 generally looks something like a PWA. This is a high level overview of the different parts of a PWA along with some code examples.
• The Cost of JavaScript — Addy Osmani explains web performance in a way that’s very easy to understand. This talk during PerfMatters Conference will give you a basic understanding of where frontend performance bottlenecks are and how to mitigate them.
• Creating an Accessibility Engineering Practice — In depth resource about why accessibility is important and how to build an app that supports it.
• Inside Look at Modern Web Browser —High level overview of what browsers do at each stage of the render pipeline, great for answering discussions about how browsers parse code and display information. There’s 4 parts to this series of blog posts.
• Metrics & Performance Budgets — How to create trackable goals around web performance. What does fast really mean?
• Adaptive Loading — Strategy for loading only what’s necessary for the current user interface and device type.

Backend Systems

As mentioned, some companies don’t have frontend interviews and may ask backend and infrastructure focused systems design interviews. These should give you enough breath of information to talk about systems beyond the backend APIs for frontend.

• Grokking the Systems Design Interview — Paid course on Educative that goes through popular types of systems. Content is pretty concise and covers enough information to sufficiently pass a full stack or backend leaning systems design interview. Well worth the $39 for a month of access to the platform or $79 for lifetime access to the course, especially if you in a time crunch.
• System Design Primer — Free resource on GitHub that covers a very wide breadth of topics as well as many popular types of systems. As a frontend or full stack engineer, you will probably not encounter topics beyond backend and databases.

Behavioral

Prep 2 hours

The behavioral interview is usually conducted by a manager to determine your level of expertise, culture fit, and career interests. This is also an opportunity for you to improve your candidacy profile by highlighting your own strengths against the needs of the team or the company as well.

Expertise

You will be asked indirectly about your current role and past roles by examples of projects and teams you have worked on. When talking about your previous experiences, try to give examples that are of the highest impact and scope. The hiring committee and hiring manager will take this feedback into account when determining potential level at the offer stage.

Typically levels correspond to stories like this:

• New Grad (L3)— “I helped my team ship the new checkout experience by building the new payment input components and address forms.”
• Junior (L4)— “I rebuilt the shopping cart page from scratch as part of the new checkout experience to improve user experience and performance by migrating away from our legacy code .”
• Senior (L5) — “I lead the project to deliver a new checkout experience by scoping the project with our product manager and breaking down the technical tasks with my team. I also helped coordinate cross-team technical dependencies and resource constraints with other leads as they came up during development.”
• Staff (L6) — “I advocated for the e-commerce wide effort to improve performance and lead the effort across our shopping experiences by identifying areas of improvements. I then worked with stakeholders on each team to explore possible projects and define goals. Across the projects that include creating a brand new checkout experience and optimizing product pages, we saw a 30% reduction in page load times and an overall conversion rate improvement of 10%.”

Culture Fit

At smaller companies, this is more of the Airport Test — “Would you want to be stuck in an airport with this person?”. Do you like the person and would the person get along with you and the rest your team?

At larger companies, especially ones with more objective hiring criteria, this becomes a negotiation and conflict de-escalation discussion. You will be asked about how you resolve disagreements with coworkers and receive difficult feedback. There are a few right answers to these questions and some companies seem to prefer certain ones over others — the more “tech bro” companies like Palantir and TwoSigma seem to prefer direct feedback while the “diversity focused” types like Airbnb and Stripe seem to prefer the negative sandwich feedback. It really depends on the interviewer’s personality and also the personality types that the company attracts.

Career Interests

What types of projects interest you? Is it building user interfaces, component libraries, or architecture optimizations? How much CSS and HTML do you want to write? How much or how little backend development do you want to be involved in? Do you like fast moving projects or a steady stream of work?

Where do you want to be for your career in the next few years? Do you want to take on a bigger scope of work? Are you interested in leading a team or managing people? Or is work life balance extremely important to you because of other obligations?

How to prepare

Put some thoughts into how you would answer these questions and what examples you would give.

1. Tell me a little bit about you and your past work experiences.
2. What are you looking for in your next role?
3. Tell me about a project that you are most proud of.
4. Tell me about a project that failed and what you learned from it.
5. Tell me about the best feedback that you’ve received.
6. Tell me about a time you received critical feedback and how you handled it.
7. What is your biggest strength?
8. What is an area of improvement for you?
9. Tell me about a time you disagreed with your peers or your manager.
10. Was there ever a time when you advocated for something few people believed in? How do you influence others and get buy-in?
11. Why do you want to work for company X?
12. What interests you about team Y?

Frontend Trivia

Prep 1 hour

Sometimes, companies ask a few quick frontend focused questions to gauge your level of comfort with frontend early on in the process. If you don’t know the answers to a few of them, it’s not really a big deal although more preparation is always better.

• Facebook — recruiter phone screen
• Spotify — technical phone screen
• Squarespace — online HackerRank test
• Airbnb — technical phone screen

This Frontend Interview Handbook has 3 sections, HTML, CSS, and JavaScript. It covers pretty much everything interviewers might throw at you. You can read over them to refresh your memory.

Company Specifics

It goes without saying that not every company looks for the same combination of technical and people skills. Always do some homework and research into what the interview entails and mentally run through the leaked problems.

Interviews

Some companies have special interviews.

• Netflix has a huge emphasis on culture so it is a requirement that the candidates review the Netflix Culture page and Reed Hasting’s thoughts on culture to formulate their own opinions to discuss during the interviews.
• Shopify has a Life Story interview where the recruiter interviews the candidate about their upbringing, background, and life details that don’t normally surface in an interview. It’s important to have a few stories prepared that showcase your life in a positive manner about family, friends, and colleagues.

Additional resources

• Glassdoor — great resource for getting more details about the interview process, offer timelines, and occasionally some leaked questions
• Leetcode forums — lots of detailed interview experiences here too, mostly larger companies like Microsoft, Facebook, Google, and Amazon
• Rooftop Slushie— platform where people pay current employees at specific companies to answer questions, some pretty good information about teams, culture, and leaked problem sets too
• Blind — anonymous tech oriented discussion app, some pretty juicy insider information about company culture and team dynamics. great for getting second opinions on your job offer and negotiations

Additional Resources

This Tech Interview Handbook is written and curated by the same person who put together the Frontend Interview Handbook. It has a lot of good information about resumes, application processes, offer negotiations, and general tech job hunting tips.

Closing Thoughts

Don’t get too upset if you can work through these exercises just fine but stumble during your actual interviews. Everyone’s been there, even many of the engineers you admire. Try practicing with a buddy and do mock interviews with each other using the same tools such as CoderPad, white board, and Zoom to simulate the actual interview environment as closely as possible.

Good luck with your interviews!