Cracking the Facebook Developer Interview (1/2)

The views expressed below are mine and mine only! I’ve learned a lot through other engineers sharing their interview experiences. Maybe someone can learn something from mine.

Ever since my friends/colleagues heard that I joined Facebook, there’s been a common theme around the questions that I’ve been asked:

  • “Did Facebook reach out to you for an interview?”
  • “How were the interviews like?”
  • “How many interviews were there?”
  • “How did you prepare?”

I wanted to answer these questions in one long post but I decided to cut this out into two pieces with tips sprinkled in:

  • [Part 1] Getting the interview call + Passing the Phone Screens
  • [Part 2] The Dreaded Onsite

How did I end up getting an interview call from Facebook?

Well, I’ve my 6-month co-op at Apple to thank for. When I was in my final semester (Spring 2017), I applied to all the Big Ns and ton of medium-sized and small startups. Sure enough, I had a university recruiter at Facebook reach out to me. The initial recruiter screening mostly centered around my internship (ignoring my side-projects and other past experiences) helping me draw a strong conclusion on why I got selected.

The interview process is divided into two stages i.e. phone screens and a final onsite round. Number of phone-screens can vary based on your performance.

The date for the initial phone-screen was chosen and I started studying. I half-assed a ridiculously optimistic study plan (completing CTCI and ~50 Leetcode questions) and I failed the interview. Failed because I couldn’t complete an absurdly easy Linked List question. Looking back, I was extremely fearful of failing and making me a fool of myself in front of the interviewer. Scared that I might get asked the one question I skipped, or failing to answer something trivial that every CS student must know.

Fast-forward to one afternoon in July 2018, I receive an email from a different Facebook recruiter this time hiring for iOS engineers.

We schedule an initial call which surprisingly included a 5-question iOS quiz that I was not prepared for. Luckily, I managed to answer all of them correctly proceeding towards the phone screen.

This time around, I was serious. I created a quick list of questions and books that I wanted to tackle before the phone-screen and decided to go all in. I didn’t want to bow out this time because of my inability to answer a Linked List question. This was an extremely intense month for me as I had to juggle work and my interview prep. I did very little socializing during this time and concentrated solely to getting onto the onsite round. I completed almost all Leetcode Easy and Medium questions asked for FB. I researched the company values and had my post-interview questions prepared.

My body was ready.

Facebook phone screens have a typical format that the interviewer will walk you through. The first 5 minutes are for small-talk, while the last 10 minutes are reserved for questions for the interviewer. The 45-mins in between are to solve 2 coding questions that test your algorithm and data-structure knowledge.

Unlike the last time, I was better prepared and passed my phone-screens fairly easily. Here are a few things that helped me immensely in my prep:

  • Practice, practice and practice
    • The first thing I always did in the morning was going through the problems that I did the day before to ensure I’ve thoroughly understood the solution.
    • I always wrote out my solutions in Sublime Text (with auto-complete disabled) before submitting it to Leetcode. This was to mimic the phone-screen environment.
  • Test cases
    • Always come-up with a good passable test-case and 2-3 edge case inputs. After you complete coding your solution, make sure it works against those test-cases.
  • Explain your process
    • Don’t start coding the brute-force solution right away. Explain the brute-force solution and ask the interviewer if he’s happy with it or if he’s looking for something optimized. In most cases, interviewers won’t ask you to code the brute-force solution.
  • Mock Interviews
    • There are many websites that offer free peer-to-peer platform for tech interview practice. You are anonymously paired with another techie where you solve one interview question in the first 30 minutes and play the role of an interviewer for the next 30 mins.
    • The great thing about mock interviews is that you get to play both roles (interviewee and interviewer). As an interviewer, I came across few engineers with amazing interviewing skills (which I happily borrowed). Most good engineers never started coding straight-away spending the first few minutes communicating their thought process and writing pseudo-code in the code editor explaining how they plan to go about the problem.
    • I completed ~18 interviews on Pramp and a few more on other websites. I focused a lot on quality over quantity of mock interviews and it helped make me a lot less nervous when the actual phone screens came about.
  • Prepare good post-interview questions:
    • Asking good questions post the interview leaves a good impression. Be sure to read the engineering blog-posts, open-source projects and try and ask questions in their allotted time.

In my next post, I’ll give out more details about my on-site experience and share a few do’s and don’t. Bye!