Facebook frontend interview

Facebook frontend interview DEFAULT

Front End Interview Handbook

Get paid more. Moonchaser has negotiated hundreds of tech offers. Get 1-1 guidance from their experienced team of ex-FAANG PMs, SWEs, and Recruiters. Find out more

What is this?

Unlike typical software engineer job interviews, front end job interviews have less emphasis on algorithms and have more questions on intricate knowledge and expertise about the domain — HTML, CSS, JavaScript, just to name a few areas.

While there are some existing resources to help front end developers in preparing for interviews, they aren't as abundant as materials for a software engineer interview. Among the existing resources, probably the most helpful question bank would be Front-end Developer Interview Questions. Unfortunately, I couldn't find many complete and satisfactory answers to these questions online, hence here is my attempt at answering them. Being an open source repository, the project can live on with the support of the community as the state of web evolves.

Why do I want this?

Front End Interviews Demystified

Front End interview preparation resources are scarce but no fret, we tell you what to expect and everything else you need to know!

Learn more

System Design

What even is Front End system design?! Learn more about them and how to ace these interviews.

Learn more

Coding Questions

Coding questions are an entirely different ball game for Front End interviews. We tell you how to prepare for them (hint: not just LeetCode).

Learn more

Go From Zero to Hero

Go from zero to front end interview hero with this handbook. No prior interview experience needed.

Back to Basics

Learn to walk before you learn to fly. While React, Vue and Angular are cool, make sure you also know your fundamentals.

Community Effort

The best thing about Open Source is that the community vets the contents, so you can be sure the answers here have been proofread by many.

Who is this for?

Anybody who wants to land a job at a tech company for a front end role and is looking to make sure they don't stumble on the basic questions. To be frank, I revise the answers here from time to time as well!

Looking for high quality front end interview courses? Educative offers a ton of great courses to improve your interview game

Looking for Generic Interview Preparation?

You might be interested in the Tech Interview Handbook which has helpful content on general coding interviews such as algorithms, behavioral questions and an interview cheatsheet!

Table of Contents

  1. Pop Quiz Questions
  2. JavaScript Utility Function Questions
  3. Front End Coding Questions
  4. JavaScript Algorithm Questions
  5. Front End System Design Questions



If you are interested in how data structures are implemented, check out Lago, a Data Structures and Algorithms library for JavaScript. It's meant for reference and studying purposes, not really for production use.


Contributing Guide

Read our contributing guide to learn about how you can contribute, how to propose improvements or if you are interested in translating the content.


Many hours of hard work have gone into this project. Your support will be very appreciated!

Buy Me A Coffee


All projects and packages in this repository are MIT licensed.


I am providing code in the repository to you under an open source license. Because this is my personal repository, the license you receive to my code is from me and not my employer (Facebook).

Sours: https://github.com/yangshun/front-end-interview-handbook

2021 Front End Developer Interview Questions (And Answers!)

Table of Contents

  • Understanding the Front End Developer Interview
  • JavaScript Interview Questions
  • CSS Interview Questions
  • HTML Interview Questions
  • Algorithm Questions
  • Ecosystem Questions
  • Back End Interview Questions
  • Security Questions
  • Front End Interview Tools
  • Conclusion

Understanding the Front End Developer Interview

Interview Process

Front end interview processes can vary a lot by company. But, generally, they follow one of these two flows:

The Take-Home Interview

  1. Initial phone screen with a recruiter or hiring manager.
  2. A take-home challenge you complete on your own time.
  3. An onsite consisting of two or three in-person interviews. Likely covering or expanding on your take home.

The Standard Interview

  1. Initial phone screen with a recruiter or hiring manager.
  2. Phone screen with an engineer on the team.
  3. An onsite consisting of four or five in-person interviews.

The take-home challenges can range from building a complete front end application to a HackerRank style algorithm challenge. Sometimes a take home will be time-boxed to a set amount of time. One downside to take-home challenges is the additional time commitment. Also, if it's not time-boxed, you're essentially competing to be the person who spends the most time perfecting their answer. An upside is that most places that do take home interviews construct their follow-up interviews around the project you already completed.

This means, when preparing for front end developer interviews, you'll want to practice both the soft skills you'll need to do well on the recruiter or hiring manager screen, as well as the coding skills you'll need for the take-home and onsite.

What the Interviewer Is Looking For

When preparing for an interview, it's important to put yourself in the interviewer's shoes! If you've ever been on the other side of the table, draw on those experiences. They are likely in the middle of a workday with "Interview" on their calendar. Hopefully, they've looked at your resume and have been given some instructions from the hiring manager.

Some companies allow each interviewer to ask anything they want. Others maintain lists of "acceptable" or "banned" questions. Some even structure the entire interview process, assigning each person a specific subject to cover.

Either way, they have 45 minutes (typically) to meet you, introduce themselves, get to know you, and work through any coding challenges they may have brought. A good interviewer will outline the process in the beginning, but often they are broken down like this:

  1. The interviewer talks about themselves (2 minutes)
  2. The interview asks you to go through your recent work history (5 minutes)
  3. High-level technical questions (7 minutes)
  4. Coding challenge (25 minutes)
  5. The interviewee has a chance to ask questions (5 minutes)

Keep in mind some companies do things very differently. It's often a great idea to ask your recruiter for any information they can give regarding the interview process. Sometimes they will tell you the general structure, and other times they'll even give you a list of topics to study!

How To Approach Front End Developer Interview Questions

Interviews can be scary. The interviewee gets to pull a random question out of the air, and you have to get to work solving it! Keep in mind that there are many things you can do to improve your experience regardless of the question asked. Here are a few tips I always try to keep in mind:

  1. Don't start coding too quickly! Let them explain the question. Take a moment to make sure you really understand it. Ask clarifying questions. Maybe write a few "test cases," even if they are just pseudo code. For example, "So if I passed in the number 19837, it would return 13789"?
  2. Don't be afraid to ask questions. There may be some questions the interviewer won't answer, but asking questions will count in your favor most of the time!
  3. Break the problem down into smaller pieces. Coding challenges will often come wrapped in a big story. But at their core, they are usually relatively straightforward.
  4. Use magic functions! It's also quite common that you'll run into a discrete part you don't know how to solve while solving a coding challenge. Maybe you're writing code to access an API, and you've forgotten the syntax for `window.fetch`. Don't worry too much about it! Make a "magical" function like `getDataFromAPI` and just keep moving forward. It's always better to get something working than nothing at all. A well-named magic function can get you a long way. Things like `turnStringIntoArray`, `iterateThroughObject`, or `fetchChildDOMNode` can allow you to get back to the part of the problem you understand.

JavaScript Interview Questions

What is the `this` keyword in JavaScript?

`this` is a little tricky in JavaScript. Its value is determined by what the function you are inside of is called. In the global state, `this` is set to the window object. The value of `this` also depends on whether or not you are in strict mode. Inside a top-level function, a strict mode `this` will be undefined, whereas a non-strict mode `this` will be the window object. It's also worth knowing that the value of `this` can be overwritten with the bind method.

What is the difference between let, const, and var?

Originally, var was the only option JavaScript had for defining variables. In ES6, we got const and let as additional options. The important takeaways are:

  1. Variables defined with const cannot be reassigned.
  2. Const and let variables are block-scoped.
  3. Var variables are function scoped.
  4. Variables defined with var are hoisted.

What is the difference between == and ===?

Doubles equals checks for value only. Before checking, it does any necessary type coercion. For example, the string "1" will be == to the integer 1, but it will not be ===. Many projects these days prefer to always use ===. Although, some folks advocate writing code that works well with the == type coercion. 

How can you access HTML elements with JavaScript?

Familiarize yourself with getElementById, querySelector, and querySelectorAll. 

What options do we have to store data?

You can store user data in localStorage, cookies, or sessionStorage.

How can you traverse the DOM with JavaScript?

You can grab a DOM node with either `getElementById` or `querySelector`. You can then get all of its children by calling `.childNodes` (note: childNodes returns a NodeList, not an Array). You can then traverse the DOM by iterating through the childNodes and calling `.childNodes` on each one of them. You can walk your way back up by checking any node's `parentNode`.

For more information, check out all of the properties stored on DOM nodes.

What is functional programming in JavaScript?

Functional programming refers to using pure functions. In the context of JavaScript, this means familiarizing yourself with map, filter, and reduce. It's also worth understanding the concept of immutability.

CSS Interview Questions

What is the box model?

The CSS box model refers to the way CSS handles layout. Each element is composed of its content, padding, border, and margin.

Know your CSS selectors!

Many interview questions will require you to know class selectors like `.foo` and id selectors like `#bar`. It's also good to know that you can select siblings `div + p`, Descendents `div p`, and children `div > p`.

CSS specificity

If your CSS has two conflicting selectors, who wins? For example, if you write

Will the word "hello" be red or blue? To solve this, CSS has a priority order for which types of selectors win over other ones. `!important` tags are the strongest, and the universal `*` selector is the weakest. For a fun illustration to help you learn CSS specificity, check out specifishity.com.

What are pseudo-elements?

Pseudo-elements are keywords that let you specify specific parts of an element instead of the entire thing. For example, you can select an element's `::first-line` or select `::before` an element. 

What is Flexbox?

Flexbox is a W3 specified layout system for CSS. It allows you to easily position elements inside a container even if the size of that container is dynamic. You should familiarize yourself with some basic Flexbox layouts. Some free resources include:

What is CSS grid?

Grid is a W3 system for making entire page layouts. CSS Grid is great for literal grids and full pages, whereas Flexbox is great for groups of items on a page. Some free resources include:

HTML Interview Questions

What does semantic HTML mean?

Semantic HTML means using the most appropriate tag for the task at hand. It means using meaningful elements such as `<form>`, `<article>`, and `<table>` instead of only using `<div>` and `<span>`.

What is Web Accessibility?

Web Accessibility means making sure the web is usable by people with a wide range of disabilities. It includes making sure keyboard-only users can navigate your site while also making certain people who have difficulties hearing or seeing can use it as well.

What is the difference between a tag and an attribute?

HTML tags are elements. Think `<a>`, `<button>`, and `<div>`. HTML attributes describe characteristics of elements. Think `src`, `class`, and `id`.

What is the difference between inline and block elements?

Inline elements cannot have a height or width. Examples of inline elements include span, a, and img. Block elements get their own line and take up the full width available. Examples of block elements are div, p, and h1.

Display none vs. visibility hidden

Both display none and visibility hidden will hide the element from the page. The difference is that with display none, no space will be allocated for the element, whereas with visibility hidden, a blank space will appear on the page.

Algorithm Questions

Front end interviews usually aren't as heavy on the data structures and algorithms as general software engineering interviews. Even so, it's still important to know how to accomplish a few everyday tasks.


You should know how to push, pop, shift and unshift. You should also know how to map, reduce, and filter.


You should know how to iterate through an object's keys. For extra credit, learn a bit about Sets and Maps and when to use them!

Lesser used data structures

Sometimes, other data structures will come up during an interview. You might get questions about Linked Lists, Stacks, Queues, and Trees. For a quick study guide on these, check out itsy bitsy data structures.


The most important thing to learn is some of the quirkier behavior of JavaScript's sort method. Make sure you can use it to accurately sort an array of integers. Sometimes front end interviews will also ask about specific sorting algorithms. To brush up on those, check out this article on freeCodeCamp.

Big-O notation

Time and space complexity comes up from time to time in front end interviews. At the very least, it's good to understand that any algorithm you write could be used on a very small or very large data set. This means things like adding a nested for loop could have profound effects at scale. If you want to go a little deeper, it's worth reading about Big-O notation and understanding some common notations like constant time and logarithmic time. This article on Digital Ocean is a great place to start.

Ecosystem Questions

What are some popular front end frameworks?

You definitely shouldn't need to know how to use multiple frameworks to get a front end job. But it might help to be aware of the current trends. Take a look at React, Vue, Angular, and Svelte. 

What are some alternatives to writing pure CSS?

Lots of teams use a CSS preprocessor like Less or SASS. Some teams use css-in-js libraries like styled-components. Others still use utility frameworks such as Tailwind. Again, no need to learn how to use all of these, but they are nice to be aware of at a high level!

What are some options for testing JavaScript code?

Unit test frameworks like Jest are very popular. Teams also use tools like Selenium or Puppeteer to test the entire website.

What is the difference between unit tests and end-to-end tests?

There is a ton of overlap but at a high-level unit tests mean testing your actual code. Making sure that functions return expected results when given specific inputs. End-to-end tests are intended to test the website itself, not the code. They simulate clicks and scrolls and make sure the site behaves accordingly.

What are TypeScript and Flow?

They are both types of systems for JavaScript. Similar to SASS and LESS mentioned above, they allow you to author JavaScript with static types, and then they turn into pure JS when you deploy. They can help you catch bugs and better document your code.

What is a bundler?

We like to author code by separating components into individual files. This makes it nice for us as developers but would be very slow if you try to force the user to load all 100+ files. Therefore we use a tool like webpack to grab all the files and concatenate them together. That way, we can serve 1 or 2 "bundles" of code instead of 100 individual files.

What is a CDN?

A Content Delivery Network like Cloudflare gives us geographically distributed servers so people can load our app from a location near them. Instead of people all over the world having to wait for files to come from your hometown.

What tools can you use to debug web applications?

All of the major browsers have a built-in set of developer tools. These can be used to look at network traffic, find errors in the console, spot memory leaks or CPU bottlenecks.

Back End Developer Interview Questions

What is an API?

API stands for Application Programming Interface. In front end development, we often use API to mean a REST service we can access with HTTP requests to get back data. For example, api.github.com/user will return information about the currently logged-in user.

How do you access an API with JavaScript?

The most common way to access an API with JavaScript is using `fetch`. 

What is the difference between SQL and NoSQL databases?

SQL databases (MySQL, PostgreSQL, etc.) are relational databases and come with a structured query language. NoSQL databases (MongoDB, DynamoDB) are non-relational and have dynamic schemas.

Security Questions

What is HTTPS?

Hypertext Transfer Protocol Secure is a version of HTTP (Hypertext Transfer Protocol) that is encrypted. This means that sensitive data like passwords are not able to be read while in transit. Any sensitive information should be sent over HTTPS. Companies like Google are even starting to push that all websites should be served over HTTPS as its become readily available and fast.

What is XSS?

Cross-Site Scripting attacks are when an attacker sneaks some malicious code into a web page viewed by others. Think of a social media site like Facebook. If you uploaded an image that looked like `<img src=" javascript:alert('hello everybody')"></img>`, you can imagine the surprise other users would have when they clicked on your image and saw a browser alert!

What is a SQL injection?

Another type of attack. If you have a search form, for example, and when a user types in a name like "Kelly" you take that string and do an SQL lookup for it. Let's say your SQL looks like this:

`SELECT * FROM Users WHERE UserId = yourVariable`

An attacker could put something malicious in the search bar like `Kelly OR 1=1`, and now it will return a list of all users instead of just the requested one.

Front End Developer Interview Tools

There are a ton of great resources to help you prepare for a front end interview. They all cover the same things, so if you have one you prefer, definitely use it! That being said, some of my favorite tools are:

  • Leetcode - The de facto interview prep site with the largest number of sample questions.
  • Cracking the Coding Interview - The de facto interview prep book.
  • HackerRank - A Leetcode competitor but also the site most often used for take-homes. It's nice to get some hands-on experience with their UI before you begin.
  • AlgoExpert - A new site with fewer sample questions than Leetcode but premium videos for each one.


Front end interviews can be stressful! There are infinite things to learn. I always recommend people study but be sure to study at a healthy pace. Set realistic goals and a time limit when you'll start applying for jobs.

If possible, always practice with real tools like a whiteboard or the hackerrank editor. Practice not only solving problems but learning to talk while you code. Remember, don't rush into coding! Ask questions until you fully understand the problem. Also, keep in mind you can fail a question and still get an offer! Just do your best, communicate what you can, and stay open to any feedback from the interviewer. Good luck!

Sours: https://www.g2i.co/blog/2021-front-end-developer-interview-questions-and-answers
  1. First polymer pistol
  2. Clark howard home buying
  3. Epson label printer

Front End Interview Handbook

🔍 Front End Interviews Demystified

Front End interview preparation resources are scarce but no fret, we tell you what to expect and everything else you need to know!

Learn more

👩‍🎨 System Design

What even is Front End system design?! Learn more about them and how to ace these interviews.

Learn more

👩‍💻 Coding Questions

Coding questions are an entirely different ball game for Front End interviews. We tell you how to prepare for them (hint: not just LeetCode).

Learn more

💯 From Zero to Hero

Go from zero to front end interview hero with this handbook. No prior interview experience needed.

🍼 Back to Basics

Learn to walk before you learn to fly. While React, Vue and Angular are cool, make sure you also know your fundamentals.

👨‍👩‍👦‍👦 Community Effort

The best thing about Open Source is that the community vets the contents, so you can be sure the answers here have been proofread by many.

Sours: https://frontendinterviewhandbook.com/
How to Solve Coding Problems - Facebook Algorithm (Javascript)

I interviewed with Facebook in March for a front-end developer role. It was an insulting experience. The tech screen was with some low-level engineer. The first(and only question before I hung up on him) was to write a function in javascript to return the square root of a number.

My answer in 15 seconds: var sqr = function(e){ return Math.sqrt(e); }

Easy enough. But no, he wanted a function that demonstrated an algorithm to find the square root. Ok... I said. I spent a minute trying to salvage some odd details from high-school algebra and basically came up blank. I was thinking, well this isn't going to look good on me. I readily admit to him that my knowledge of figuring out square roots by hand is a rusty, having been out of high school for 12 years(even though in retrospect, this was something we were never really even taught anyway). But surely this guy, who is screening me for my ability to do front-end coding, will move on and start asking me some hard problems about javascript, css, cross browser problems, etc. No.

We spend the next 6-8 minutes with him circling back on his square root problem. I tried a couple more times to answer this question that is completely unrelated to the job I'm interviewing for. Finally, I get so fed up with this moron that my internal ticker clicks over and I realize, "Even if I get this job, I'm going to be dealing with these kinds of nazel-gazing engineers every single day. Not an environment I want to be in." I thanked him for his time, and he acts surprised and says "Are you sure? After everything it took to get to talk to me?". Yes, I say. I'm quite sure. >Click.<

I realized a long time ago what kind of people these are. When I was growing up, the garbage truck would come by on Tuesdays and Thursdays. When we first moved to the neighborhood, we would put our garbage out by the mailbox and some days it would be picked up and sometimes not. We would complain and nothing would change.

After a few weeks, I was standing out front when they came by. I noticed that everyone had their trash bags on the right side of their mailboxes. That morning, I had done that as well. But some new neighbors down the street had put theirs out on the left side of their mailbox. The truck comes by, grubby guys grabbing/throwing, grabbing throwing. All the garbage gone, except for the neighbors. The next time, I purposely left ours on the left side. Didn't get picked up that day.

So that was the day that I realized these guys had their Line In The Sand. It was Their Way or the Highway. They had a really crappy job. Probably crappy lives at home because they're garbage men. This was Florida, not NYC. There's no glamor or high-pay there. This was the one place where they were the kings, the arbiters of Pickup Or Not. This was the one point of control over their lives they could influence, and they grabbed onto with both hands and some toes.

So this little middling engineer at Facebook had his Line too, in the form of a square root function that Had To Be ANSWERED! "You shall not cross!" He exclaims internally. I'm positive he was quite satisfied with himself after I hung up. Some self congratulation at keeping another peasant out of the castle halls. Kind of like the junk yard dog on a chain behind the fence. Smug in barking and keeping away the kids, but still chained to his dog house.

Sours: https://news.ycombinator.com/item?id=571090

Interview facebook frontend

Frontend Practice

This week, I’m starting a new position as a Sr. Frontend Engineer at Facebook. Having recently gone through the interview process, I thought I could share the techniques and resources I used to prepare for frontend-focused interviews, as well as a few general interview preparation tips. Since larger, more established companies like Facebook tend to focus on fundamental concepts rather than one’s ability to use frameworks, I’ll focus on how I refreshed and solidified my understanding of vanilla JavaScript and the DOM APIs.

Being fluent in the JavaScript language and knowing the browser DOM APIs thoroughly is important for passing frontend interviews and also for excelling as a frontend engineer who can solve low-level frontend problems when they’ve hit the limits of their frontend framework. In the past, I’ve invested in this skill set by building complex UI patterns without libraries or frameworks. While preparing for my recent interviews, I utilized the following resources and techniques to brush up.


One site I found particularly useful for brushing up on these topics is JavaScript.info. It has a lot of articles on the JS language, built-in browser/DOM APIs, and various other topics including web components and regular expressions. The articles I read were succinct and clear. Some particularly helpful ones included:

It particularly helped me brush up on the core characteristics of nodes in the DOM, how to traverse and manipulate them, and the different types (element, text, comment).


Since I wouldn’t necessarily be able to look up web APIs during my interviews (my usual go-to reference is MDN), I wanted to commit the important ones to memory. A tool I’ve found useful for memorizing information is Anki, a flash card app that manages how often you should review a given card. When a card is new, it has you review it a couple of times in a session and report how easy the answer was to recall. As you go on, it increases the amount of time (days, weeks, etc.) between showing you the same card based on how easily you report recalling the information. It has desktop, iOS, and Android variants, as well as free online support for syncing your cards between them.

I used Anki to rehearse information including:

API Examples

In some cases, I found it useful to play around with certain JS features and browser APIs by creating code examples that I could refer back to later. For me, actually writing code solidifies knowledge better than just reading up on a topic. I also like to annotate my code examples with comments that explain concepts in my own words, which is another useful technique for enhancing my understanding and recall of these technical topics.

For example, here’s my code example illustrating the different between static and live node lists:

<!DOCTYPE html>
<html lang="en">
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<div class="foo"></div>
<div class="bar"></div>
<div class="foo"></div> <script type="module">
const bodyChildren = document.body.childNodes
const barNodes = document.querySelectorAll('.bar') const newElement = document.createElement('div')
newElement.className = 'bar'
document.body.appendChild(newElement) console.group('Live NodeList')
'bodyChildren[bodyChildren.length - 1] === newElement',
bodyChildren[bodyChildren.length - 1] === newElement
console.groupEnd('Live NodeList') console.group('Static NodeList')
console.log('barNodes.length', barNodes.length)
console.groupEnd('Static NodeList')

PrepTick Practice Interview

UPDATE 8/5/20: Unfortunately, it appears PrepTick may no longer be in operation, as their site is not currently working.

PrepTick is a paid service that matches you with another engineer who can do a mock remote coding interview with you. They matched me with an experienced engineer at a company similar in size to Facebook who was able to give me a great practice frontend coding interview. Afterward, he provided me with written feedback on the ways in which I did well and the areas where I could improve. It wasn’t exactly the same as an onsite interview, but it gave me the opportunity to practice core technical interviewing skills like asking clarifying questions, thinking out loud, and verifying the correctness of my code without running it.

There are other services that will match you with a peer for free mock interviewing where you and your peer take turns interviewing each other, such as InterviewBit and Pramp. I ended up using one of these as well, as I’ll discuss later, but if you’re pressed for time, want to ensure you get a good mock interview experience, and don’t mind spending some money, PrepTick is a good solution.

Other Frontend Resources

Besides the resources and approaches I detailed above, the following were also helpful:

  • Preparing for a Front-End Web Development Interview at Top Tech Companies: This post from an engineering manager at Amazon covers the topics you should study in preparation for a frontend interview. I particularly liked that it addresses frontend system design interviews, which is a topic I had trouble finding guidance on since system design interviews are traditionally backend-focused.
  • Performant front-end architecture: I’ve read a lot of great articles on frontend performance over the years, and this post gives a good summary of some techniques and important areas of concern. It’s a good refresher if you’ve previously delved deep into frontend performance literature. If you haven’t, I recommend this post as a good list of topics you can research further.

Interviewing for a frontend position involves your interviewers evaluating you on many of the same criteria that apply for other engineering positions. These criteria include general problem solving approaches and demonstrating soft skills when responding to behavioral interview questions. I used a few techniques and resources to prepare in these areas in addition to those specific to the frontend that I discussed above.

Writing Out My Career Story

It’s important to be able to tell the story of your career in a compelling way that keeps an interviewer interested while providing them the right level of detail. To gather my thoughts and practice how I’d tell my story, I wrote an outline summarizing the major projects I’d contributed to and the major milestones I’d reached at my last couple of jobs. I reviewed it regularly before my interviews so the details would be fresh in my head and so I’d be able to tell my story without struggling to organize my thoughts or remember various details.

Creating Cheat Sheets

For most types of interviews, there are certain important steps and behaviors that help you succeed. Many have written on them in the context of technical, system design, and behavioral interviews. After reading up on them, I summarized what I learned by writing “cheat sheets” that I could review before interviews so I would remember important steps, such as discussing my proposed approach to a technical question with an interviewer before I code it.

For example, here’s what I wrote out for technical interviews:

- Step 1: Clarify the problem
- Repeat it back in your own words
- Ask about inputs, outputs, edge cases, performance
- When/if to validate inputs
- Error handling
- Step 2: Solution Design
- Consider some example inputs
- Explain and discuss possible solutions
- If none of your approaches will work, explain why
- Come to agreement w/ interviewer on solution to try before coding
- Pseudocode if needed
- But let interviewer know real code is coming
- ASK: Do you want me to code this now?
- Step 3: Code
- Confirm you can use the data structures or libraries you want to use
- Use data structures generously
- Existing or of your own creation
- Step through code with example input
- Abstract away logic into helper functions that you can write later
- Later, confirm if the interviewer still wants you to write them
- Step 5: Test Code
- Carefully analyze bugs before fixing
- Step 5: Optimize
- Increase performance
- Add error handling
- Handle edge cases
- e.g. Empty input, input of size one, input with duplicates
- Refactor into multiple functions
- Step 6: Check with interviewer if you’re done

In addition to creating cheat sheets, I added cards to my Anki deck (see previous section on Anki) with the major points of each sheet to help me commit them to memory.

Besides cheat sheets covering the important steps for different kinds of interviews, I created one with a list of common behavioral interview questions and notes on how I’d answer each one. I reviewed this sheet frequently and also had my wife quiz me on each question to see how well I remembered my answers.

Here are a few examples of questions I prepared for:

  • Tell me about an interesting project you worked on or when you did your best work.
  • Where do you want to be in 2–5 years?
  • Tell me about a challenging bug you faced and how you solved it.
  • How do you mentor and elevate those around you?

Behavioral Mock Interview

In addition to doing mock interviews as practice for technical interviews, I also did one mock behavioral interview using the mock interview matching service Pramp. It was the one service I found that currently supports this type of mock interview. It matched me with another engineer with whom I could take turns interviewing and being interviewed. A day or so before our scheduled time, I received by email the list of questions I’d be asking during my turn as the interviewer so I could review them ahead of time.

During the session, we had enough time to interview each other and give feedback. Afterward, Pramp provided a structured form through which I provided more formal feedback to my peer. Overall, I found the experience helpful as an opportunity to practice in a setting more like a real interview, and I also received valuable feedback from my peer that helped me do better at my onsite.

Though both giving and receiving a mock interview means the overall session takes longer, it’s helpful to also experience an interview from the interviewer’s perspective and to see how another engineer handles behavioral questions. And I discovered it can also be a great way to meet someone new. After the session, Pramp gives you the option to ask your peer to connect, and if your peer agrees it shares your emails with each other. So in addition to helpful interview practice, I ended up making a new professional connection.

So there’s my overview of the most important resources and approaches I used to prepare for interviews during my recent job transition. I’m interested in how they compare with the experiences of other engineering job seekers, so please let me know if you have thoughts to share.

Sours: https://levelup.gitconnected.com/prepping-for-frontend-engineering-interviews-a05c65e29061
Solving My Facebook Phone Interview Question

This article is a guide on how to prepare for an engineering interview (including front-end) for Facebook (and other big companies like Google, Amazon…). It is based on my experience and the experiences of a dozen people that shared it with me.

It is in no way an official guide, and if you do everything written in here - it doesn’t mean that you’ll automatically get the job. But it will increase your chances considerably.

Before you read this article, go and check the official “Preparing for your Software Engineering Interview at Facebook” page. It describes the interview timeline and what to expect at each step very well.

This article is an addition to the official guide and is focused mostly on coding questions preparation. At the end you’ll find a step-by-step guide on how to practice.

Let’s begin!

Brush-up on your knowledge

Brush-up on your knowledge illustrationIllustration by Chip

Without knowing the basics - you’re not going to get far in the interview process. So it’s a good idea to revisit fundamental computer science concepts. But it will be different based on your experience and skill set:

  • Recent graduates: revisit algorithms and data structures. Learn system design
  • For experienced: revisit algorithms, data structures, system design and your domain of expertise
  • For front-enders: revisit algorithms, data structures, JS and product design

Algorithms and Data Structures

You’ll get asked about some algorithms and data structures in any case. It can be a coding question or finding the complexity (big O notation) of a piece of code. In fact, even if you don’t get asked about time or space complexity - it’s good to mention them for all solutions you provide.

For algorithms and data structures you can pick any of the following books:

I recommend Cracking the Coding Interview because:

  • It teaches you how to think about coding questions
  • It covers the main algorithms and data structures very well
  • It has solutions (Java in the book, a dozen of languages here)
  • It also has hints that you can use when you get stuck but don’t want to check the provided solution yet

Front-end specifics

For Front-end engineering positions, you have to know JavaScript very well (surprise!). You’ll get asked JavaScript questions such as prototype chain, scopes, closures, primitives… Don’t skip on ES6 (ES2015) and beyond features as many of these are de facto standard in the industry.

You’ll find JavaScript Garden to be a good memory refresher. Also Eloquent JavaScript (free online) covers basic DOM APIs pretty well and has some practical exercises to test your knowledge.

Product Design for Front-enders

It is easy to confuse Product Design with drawing interfaces, but in fact you’re asked how would you build products from a high-level perspective. You get asked questions like:

  • “How would you implement a news-feed (which has only posts of text and pictures)?”
  • “How would you implement a photos album?”

These are very vague questions, that’s why you should have a dialogue with your interviewer for the entire time.

I haven’t yet found any good resources on product design, but it follows the same pattern as the system design:

  • Ask questions and clarifications on vague bits
  • Make assumptions and state them where you don’t have enough information
  • Provide multiple possible solutions starting with the most obvious one
  • Make it a dialogue, and the interviewer will guide you through your assumptions

Practice whiteboard coding

Whiteboard coding illustrationIllustration by Chip

You may think - well, I’ve written code for X years, so I’ll have no trouble writing some code on a whiteboard. But if you never did it before, you may be surprised how different it is. No highlighting, no linting, no auto-complete and you can’t run it. And editing 2 lines above is just painful.

You can practice your skills on some paper, notepad editor or some on-line coding platforms (that have added benefit of tests). You may be tempted to run your test cases immediately after writing your code, please don’t do this. First try to check a few use cases by hand, as you’ll need to do this in the interview.

Try it now:

Implement a function to check if a singly linked list is a palindrome. Use constant space.

Learn and practice how to approach and solve a given coding question

All the above things are important, without them you have little chance of success, but these things may not be enough. It’s not enough to provide a complete solution for a coding question. Actually you may pass even if you don’t provide a complete or ideal solution. What matters most is the way you think. And that’s why I think a lot of people that have enough knowledge fail.

Let me repeat: It is more likely that you’ll pass the interview if you communicate and show the way that you think, rather than providing a complete and perfect solution. And this is a skill that can be easily trained.

The book that helped me a lot to prepare for the interview, and actually made me a better engineer is Cracking the Coding Interview. If you don’t intend to read the book (although I highly recommend you do) then the most important piece of information is the skills diagram:

Skills Diagram

you can get a PDF version here

How to practice

Now that you know what to expect from the interview, it’s time for practice. Depending on your skills it may take you anywhere between a week and few months.

The key is consistency. Carve some time every evening and solve one exercise. It’s more efficient than solving 20 exercises during the weekend and then forgetting about it during the week.

With Cracking the Coding Interview book:

  1. Go through introductory chapters
  2. Skills diagram is available in the book but I found it easier to have it printed and hanged on the wall
  3. Practice coding questions
  4. Check hints when you’re stuck or you think that you nailed it (there may be a better solution)
  5. Always follow the diagram
  6. Always try to simulate whiteboard coding
  7. Check provided solutions
  8. Repeat from 3

Without the book:

  1. Print the skills diagram
  2. Get a coding question (preferably one that also has a provided solution)
  3. Follow the diagram for each coding question. It should become a habit
  4. Check your solution against the provided solution
  5. Repeat from 2

Side effects illustrationIllustration by Chip

I began preparing long before I had the interview. And in the meantime, I started noticing that I was applying the newly developed way of thinking: I analyzed more, thought how the code will look like and only then wrote it down. It was a very pleasant side effect as I was writing more thought-through code faster.

Take aways

If you really want that job at Facebook (or Google, Amazon…) then you want to increase your chances of getting it. These tips will help you prepare, but in the end it’s down to you how much time and effort you’ll invest into that.

And even if you don’t get that job now, you’ll end up acquiring a few new skills that you can use in your day-to-day job. With most of these companies you can reapply in 6 months (ask your recruiter), and next time you’ll have much less to prepare.

Sours: https://bumbu.me/facebook-engineering-interview

Now discussing:

If you're interviewing at Facebook or you're just curious about the process, we want to be transparent about what to expect so you feel well informed and have a positive interview experience. Three Facebook Software Engineers have broken down the stages of our Software Engineering interview process, covering the Initial Interview and Onsite Interview with many tips, links and insights to help you prepare and do your best.


My name is Bosmat, I'm an engineering manager at Facebook in Menlo Park. I've been with Facebook since 2011 and I regularly interview engineering candidates. Our initial interview serves as a screening step to determine whether to continue with a full series of onsite interviews. This interview will be the first with a Facebook engineer and is primarily a coding interview. Below is some insight on what to expect, how to prepare and some tips for a successful interview.

="Bosmat leaning against a wall and smiling"

What to Expect:

  • Introductions: The interviewer will first introduce herself/himself and explain what they do at Facebook.

  • Career Aspirations: For the next 5-10 minutes, the interviewer will ask questions about your experience and your career aspirations.

  • Coding:The next 30-35 minutes will be spent on coding.
    • This takes place in an online collaborative editor shared between you and the interviewer (or on the whiteboard if you do the initial interview in person).

    • You are given one or more coding questions to complete in this editor. We ask questions that are short enough to explain in a few minutes and to solve in 10-30 minutes.

    • In this section we try to understand your approach to problem solving.

    • We typically don't ask trick or estimation questions (we don't care how many ping pong balls can be fit in Sea World).

    • You could be asked to solve a problem in any way you choose, and then the interviewer could add further constraints or requirements.

  • Ask Us Anything: The last 5 minutes is for questions. This is a great opportunity to get an insider's perspective directly from a Facebook engineer.

How to Prepare:

  • Invest time in preparing: It's important for any engineer, even senior ones, to brush up on their interview skills, coding skills and algorithms. An interview is typically different from your day-to-day job. This is the first technical interview in the process, so any preparation for this interview will be beneficial for the next ones.

  • Practice answering many different coding questions: Practice answering a coding question with the most efficient bug-free solution without using a compiler. A few resources that offer coding questions to use for practice: Careercup, Topcoder, or Project Euler.

  • Write code in a simple text editor: In the interview you will write your code in a similar environment (like CoderPad) without syntax highlighting or auto-completion.

  • Practice by coding by hand: Coding interviews will be done on a whiteboard. Practice some of the questions with a whiteboard or pen and paper to help prepare.

  • Practice under time pressure: You will have a limited time for the coding question, so it will be important to finish it in time. If possible, have a mock interview with a friend to simulate the interview experience.

  • Go over data structures, algorithms and complexity: Be able to discuss the big-O complexity of your approaches. Don't forget to brush up on your data structures like lists, arrays, hash tables, hash maps, stacks, queues, graphs, trees, heaps. Also sorts, searches, and traversals (BFS, DFS). Also review recursion and iterative approaches.

  • Think about your 2-5 years career aspirations: You will be asked to talk about your interest and your strengths as an engineer.

  • Prepare 1-2 questions to ask your interviewer: There is 5 minutes at the end of the interview for this.

  • Suggested reading resources: Cracking the Coding Interview, Introduction to Algorithms, Algorithms in C.

Tips for the Coding Interview:

  • Think out loud: We pay a lot of attention to the way you solve problems, which can be as important as having the right answer. Thinking out loud gives the interviewer insight into your thinking process and can also help them follow along with your solution. Moreover, it allows them to give hints when needed.

  • Locate a good interview spot:Choose a quiet place and ensure that you have good Internet connection and strong phone reception. Headphones will help with having your both hands free for coding.

  • Speak clearly: Ensure you are speaking clearly and likewise, if you can't hear the interviewer clearly, let them know so they can accommodate! You don't want to waste the whole interview trying to understand each other.

  • Use the programming language you're best at: It's important to write your solution correctly and in time, so use the language you are most familiar with.

  • Manage Your Time Effectively: Spend some time figuring out the ideal solution to the question. Don't jump too quickly into brute forcing the first solution that comes in mind. If you can't find a better solution in a reasonable time, start writing a working solution, then iterate and improve it as you go. Some interviews end without any coding because the interviewee couldn't find the ideal solution. It's better to have non-optimal but working code than just an idea. Once you have a working solution, you can then try to improve its efficiency, code design or any other aspect of it.

  • Share your reasoning: Make sure you can talk about your solution; you will probably be asked to explain them. Engineering is all about tradeoffs, so be prepared to discuss them.

  • Find and fix the bugs by yourself: Don't wait for the interviewer to find them for you.

  • Use the hints you are given: Usually, the interviewer knows the question well enough to know which hints will help you next if you get stuck.


My name is Brent, I'm a software engineer at Facebook Seattle. Interviewing with any company can be a nerve-racking process, and the best thing you can do to ensure your best possible outcome is to *prepare, prepare, prepare*. To help you prepare for your Facebook interview I’ve put together a few tips about what you can expect, how to study and tips for each type of interview.

="Brent, a software engineer at Facebook's Seattle office"

As an interviewee for an engineering position at Facebook, you’re going to have 4 or 5 interviews over the course of the day. These will be distributed across 3 different types of interviews:

1. The coding interview – where you’ll solve some general coding questions.

2. The design interview – where you’ll be asked to show off your design skills. The design question will be focused on either systems or product, depending on your background.

3. The behavioral interview – where you’ll talk through your previous work experience, motivations, and a number of other behavioral questions.

Unless you've scheduled your interview for very early or very late in the day, someone from engineering or recruiting will take you to lunch. This will give you a chance to ask lots of questions of someone who isn't interviewing you.

1. The Coding Interview - What to Expect:

The coding interview is typically harder than the initial interview: we ask more difficult questions and have a more exacting evaluation. This interview is 45 minutes. Not all interviewers follow the exact same time breakdown, but the following is typical:

  • Introductions: The first five minutes will be an introduction and possibly brief questions about your background.

  • Coding: The next 30 minutes will be one or more coding problems.

  • Ask Us Anything: We try to reserve the final five minutes for your questions for the interviewer. This part gives you a chance to learn more about Facebook from someone in engineering and gives your interviewer a chance to learn more about your interests.

How to Prepare:

If you haven't already, check out Bosmat's post about coding interview preparation above. She provides some great resources for coding interview preparation that are useful for both the initial screen and the onsite coding interviews.

2. The Design Interview - What to Expect:

The design interview is 45 minutes. These almost never involve coding - you'll spend the interview talking and drawing on the whiteboard. As with all interviews, the interviewer will typically save the last five minutes for your questions. The purpose of the interview is to assess the candidate's ability to solve a non-trivial engineering design problem. To that end, your interviewer will ask you a very broad design problem and evaluate your solution.

There are two types of design interviews: systems design and product design. I've outlined the specifics of the systems design interview and Dan, a software engineer at Facebook in Menlo Park, describes the product design interview below.

We try to match candidates to engineers with related expertise. Candidates come from all sorts of backgrounds: some build complex user interfaces, others build network libraries, others build platform APIs for third parties. We expect every candidate to be familiar with basic design principles, but we'll try to match you with a interviewer so that the conversation is as engaging as possible. We aim to have the conversation be based in an area slightly familiar to you, allowing you to demonstrate your design abilities on an unfamiliar problem, but in a space that is not completely foreign to you.

="View from outside five meeting rooms with employees inside"

Systems Design Interview - How to Prepare:

  • Improving upon a design: Think about and review the complex systems you’ve already designed. What would you change about your approach if you did it all over again? What worked well?

  • Designing from the ground up: Think about how you’d design a system that Facebook (Or Twitter, Google, Uber, Dropbox, etc) already has. It’s a good thought exercise to think through the complicated, high-scale systems that you already use every day. How would design it from the ground up?

  • Blog Up: Read engineering blogs about approaches that work and false starts big companies have had along the way.

  • Start with requirements:Your interviewer might ask: “How would you architect the backend for a messaging system?” Obviously this question is extremely vague. Where do you even start? You could start with some requirements:
    • How many users are we talking about here?

    • How many messages sent?

    • How many messages read?

    • What are the latency requirements for sender->receiver message delivery?

    • How are you going to store messages?

    • What operations does this data store need to support?

    • What operations is it optimized for?

    • How do you push new messages to clients? Do you push at all, or rely on a pull based model?

  • Ask Us Anything: The last 5 minutes is for questions. This is a great opportunity to get an insider's perspective directly from a Facebook engineer.

  • Design tutorial: This is a good online tutorial about design questions.

Product Design Interview - How to Prepare:

  • Reflect on your projects: Think about the projects you’ve built. What was easy, and what was difficult?

  • Your interviewer might ask:“Tell me how you'd design an email server.” Some questions you might want to think about:
    • How do you store mail, especially as the system gets large enough that it won’t fit on one machine?

    • How do you handle mailing lists with large numbers of recipients?

    • How do you handle people abusing the system for spam?

    • How do you guarantee the reliability of the system in the face of potential system failures?

  • A different interviewer might ask:Tell me how you'd design a client-server API to build a rich document editor.” Some questions you might want to think about:
    • How does the client request data on the document from the server, especially as the document gets large enough that we wouldn’t want to download it in a single request?

    • How do we represent the rich document aspects like bold and italics in our API response?

    • How do we design the system so that new features can be added on the server without breaking older clients?

  • Start with requirements:Your interviewer might ask: “How would you architect the backend for a messaging system?” Obviously this question is extremely vague. Where do you even start? You could start with some requirements:
    • How many users are we talking about here?

    • How many messages sent?

    • How many messages read?

    • What are the latency requirements for sender->receiver message delivery?

    • How are you going to store messages?

    • What operations does this data store need to support?

    • What operations is it optimized for?

    • How do you push new messages to clients? Do you push at all, or rely on a pull based model?

Tips for the Design Interviews:

  • Outline your high-level approach: When you take your approach, outline it then think about how it can be broken down into subparts.

  • Identify your focus: There's not enough time to discuss every detail of the design, find the interesting and hard problems to focus the discussion on.

  • Navigate the holistic and the details: Move effortlessly from the goals to the high-level approach to the precise details and back again. A good solution covers both high level ideas as well as low level specifics. Talk about what components you’ll use and how they fit together - “Responsibilities will be divided as so between Service A and Service B...” Also describe the implementation details - “A pub-sub queue makes sense here because…"

  • Explore the inherent tradeoffs: In any engineering problem, you will need to make intelligent decisions about tradeoffs. A good solution compares and contrasts different approaches. It explores the tradeoffs present in any complex engineering problem and it makes intelligent, reasoned decisions about those tradeoffs.

  • Drive the discussion: Part of the signal the interviewer hopes to gather is whether you've learned how to build large systems through hard experience. Your ability to anticipate and work around typical problems is part of that signal.

  • Make it a conversation: Be sure to ask clarifying questions. But make sure you drive towards a good solution.

3. The Behavioral Interview - What to Expect:

The behavioral interview is actually part behavioral interview and part coding interview. The behavioral part is about you and your history, your resumé, and your motivation. The purpose of the behavioral interview is to assess whether the candidate will thrive in Facebook's peer-to-peer, minimal-process, unstructured engineering organization.

The coding part is a shorter version of the coding interviews above. We include a coding question in this interview to supplement the two coding interviews and get additional coding signal.

How to Prepare:

  • Know yourself: Take the time to review your own resume as your interviewer will almost certainly ask about key events in your work history.

  • Motivation and collaboration:Different interviewers will ask different questions. When I do a behavioral interview, I typically seek two signals in particular:
    • One, what is the candidate's motivation? Why do they want to work at Facebook? Why are they working as a software engineer?

    • Two, how do they collaborate with their peers? How do they resolve conflicts?

  • Have concrete examples or anecdotes:Support each question with examples. Some typical behavioral interview questions are:
    • What were some of the best things you've built?

    • What are you proud of?

    • What could you have done better?

    • What were some excellent collaborations you've had?

    • Tell me about a time when you advocated for and pushed your own ideas forward despite opposition?

    • How do you deal with conflict?

    • How do you like to give and receive feedback?

    • What kinds of technologies are you most excited about?

    • Why Facebook?

Tips for the Interview:

  • Familiarize yourself with our 5 core values (move fast, be bold, focus on impact, be open, and build social value). This is how we work together to make the world more open and connected. We look for people who believe in these values and practice them daily.

  • Be yourself! Be open and honest about your successes and failures.

  • Be humble and focus on team work, leadership and mentorship qualities.

Sours: https://www.facebook.com/careers/life/preparing-for-your-software-engineering-interview-at-facebook

340 341 342 343 344