Preparing for the Facebook interview — A brutally honest guide
This article exists because I got frustrated with the usual rhetoric of preparing for these “FANG” companies by practicing (read: memorising) thousands of programming problems and buying interview-courses at which every other article seems to be directly or indirectly pointing. I’m terrible at memorising even simple stuff and absolutely despise exploitative false hope that the usual “interview preparation courses” sell to many candidates. Thus, I took a slightly different approach that took a bit of honest introspection on the ideal outcome, and the means to achieve it. As I am transitioning more towards engineering from a research centric career, I felt this approach without seeking shortcuts helped me not only with the interview but to be a better engineer as well. Hopefully it’ll be useful to others at a similar situation as I.
This article assumes you have a decent understanding of algorithms and software development. The scope of this article is not to tell you what, but how to prepare. A little of my background that’s relevant — I have a PhD in Computer Graphics and have moved from academia to the games industry as a Rendering Research Engineer. This doesn’t imply that you’ll need to have a certain token degree to do something; just that this preparation guide will work best when you have a bit of CS background. Frankly, programming is a tool for me and not my hobby, nor have I ever did any competitive programming. I was headhunted around mid 2020 by facebook recruiters and was given an interview offer at their Augmented Reality division “Facebook Reality Labs” in London. Your journey may be a little different so I’m skipping the “getting an interview” part and diving straight to the preparation. I’ll focus on facebook here but I’ve heard most FANG interviews are quite similar. There are 2 types of people in this world. 1) Those who can extrapolate from incomplete data.
Stuff you’ll need
0) The preparation documents/resources your recruiter sent you.
1) An account at an online Programming Practice Platform (example: leetcode, codechef, codebleh, hackerblah etc.)
2) Books. Here are the 3 must haves: CLRS, Design Patterns, CtCI.
3) A physical Whiteboard. Trust me. It’ll save you a lot of pain.
4) Some rigorous note taking (and a youtube playlist) to save useful resources in one place. Use it or lose it.
5) Time management and focus retention. This will make or break your prep.
Stuff you won’t need
1) Algorithm coaching companies/courses. Go back to the basics. Trust your books and yourself, not some ex-Google, ex-Facebook, ex-Husband, et-cetera.
2) Grokking the X interview. (before a mob comes with pitchforks to prove me wrong, get it if you want but IMHO, those outdated articles for 80 something quids is a joke when you can study SysDesign for free from actual sources.)
3) Alienating your family especially in these trying times and do endless hours of “leetcoding” to get a job at a certain company. Apparently, this is ‘en vogue!’
4) Following what people are saying in various social media, especially Blind.
Pre-Preparation:
- Documents from your recruiter: Get one thing straight: your recruiter wants you to excel at the interview. Interviewing a candidate is a very costly (both time and money) process so they’ll (atleast mine and all other internal recruiters for FB/G I know) give you all the resources you’ll need to start your prep. If you weren’t given any, ask for it. Ask for time before the interview if you want to prepare more. On our first call, my recruiter gave me a tip to think out loud and keep talking for the entire duration of the interview which proved to be absolutely pivotal during.
- Time management: Its easier when you already have a job, as managing a shorter chunk of prep-time is easier for a concentrated focus; plus you don’t have the additional worry of putting food on your plate if you do not get the fancy job. Having a larger prep-time is good but it is difficult to keep yourself in focus — especially for neurodivergent people. Keeping track of the daily routine, agenda and goals helps a lot.
- Note taking: If you think you can revisit your entire CS curriculum in a month or two and remember all of it, you’re delusional. Get a notepad. I’d highly recommend using a physical one. Not taking enough notes is one of the single biggest mistakes that the grownup professionals make. Take notes of everything you study even if you think you don’t need to.
Programming Preparation:
(or, Why doing 969 LC problems wont guarantee you an offer and likely do more harm than good)
Picture this — you’re interviewing some Engineer to hire for your world-class team. Would you hire someone who has memorised the optimal solution of a problem, or rather go for someone who can think independently, communicate, and you both arrive at a solution together even though that’s slightly sub-optimal?
How would you detect the first type of person? One of the tricks is to ask a question that has several approaches and trying to get a signal on how does the interviewee think based on the approach they take. This is why they tell you (read the book CTCI) that if you’ve already seen a problem before, tell the interviewer. You know why? Because nobody, not even John Carmack himself will be able to come up with an algorithm like the Aho-Corasick or the KMP inside 20 minutes from scratch in an interview if they did not know the solution beforehand. KMP took Donald Knuth, Morris, and Pratt over 7 years to develop and you’re just a dude — so if you do this with a straight face without telling the interviewer that you’ve already seen this problem, it can be fairly certainly deduced that you’re prone to memorising solutions.
The goal of these interviews are to get different signals on your skills and thinking ability. Memorising a solution is not technically ‘cheating’ but with due respect, the best tech companies in the world are (ideally) looking for the next technology leaders, and not just some dude who can memorise a lot of programming puzzles, because they are frankly, a-dime-a-dozen.
This is one of the reasons why you’ll likely see that many people who have solved 200–500–1000 programming problems couldn’t get through these interviews. Don’t get me wrong as there’s a bit of luck involved in here too, but mugging problems generally isn’t going to cut it here. You need to think in an algorithmic way yourself.
Attack this in two ways: 1) Start brushing up the data structures and algorithms from your favorite textbooks/online resources. 2) Get an account at a platform to practice the programming challenges inside time limit. Keep at it even if you’re initially rusty. It helps if the platform has: a) Difficulty tags, b) method tags, c) company tags. I bought one of these premium version platform for a month before my onsite to browse the “Facebook”” tagged problems which helped with my confidence. I actually coded/submitted 34 such problems and browsed through about a hundred of them. I didn’t get any common problems in the actual interview!
Once you start solving these problems, you’ll very likely to see a few patterns emerging except for a few oddball ones that will require a non-trivial approach to solve. If you can’t think of a solution in say 2–3 hours, leave it and search for the answer. Everything is available online.
As mentioned in the beginning, I’m not going into any detail on what to prepare in DataStructures and Algorithms because a) that’s irrelevant, and b) this article assumes you have a decent background in SWD. I can later share some more strategies into various type of questions but I’ll have to do it separately to keep the length of this at a manageable length.
System Design Preparation:
Before you do anything, please watch this video where Jackson talks about how to approach a system design interviews. Trust me it is worth the 50 minutes of your life. Especially note how around 43 mins in, he starts talking about the internal tech-talks and whitepapers on the big systems by their designers in larger companies. I’ll elaborate why it is necessary and how you can include this in your prep!
Without going into specific details of SysDesign, here is my short take on this: you will never be able to design a system, however simple, in 40 mins. This is simply because once you’ve addressed a skeleton of the system, the interviewer will start to peel the onion and force you to go deeper. There is no right answer (although there are wrong answers) to this question, just different levels of approaches. Depending on the seniority level and the role you’re applying for, the interviewer will seek the level of depth in your answers. All they want is to get the signals — what are your stronger and weaker areas — that’s it! Your goal would be to engage the interviewer for the duration of the interview. A good answer would look like an onion where in each step you go into further depths on specific modules of the system while also keeping touch with the bigger overall picture and have a bit of time to conclude. Watch how jazz prodigy Jacob Collier explain the same concept in varying levels of detail to different audience below! Your goal would be something like this — starting from a top level view to gradually expand your answer.
I’ve devised three parallel approaches to prepare for this interview.
1) Getting the structure of the basic building blocks of a distributed, scalable system.
2) Reviewing the common 10–12 types of systems and how they work,
3) Studying the tech-talks (videos, podcasts) and papers of the famous distributed systems, platforms and products.
Approach 1: Basic Building Blocks: The best way to start this is to actually understand how distributed system works. David Malan has a brilliant introductory video on Distributed Scalable Systems.
Once you go through these type of contents, the basic building blocks of scalable systems will start to feel trivial to you. You need to serve a lot of people? Get a Load Balancer first. You need to queue requests and process asynchronously? Get a Message queue. You need associative storage? Get Redis. Need key-value store? Look no further than Cassandra! How about distributed volatile caching? There’s Memcached. Need to make DBs scalable? Get Consistent hashing. Need to provide noncritical logs (ex: like count)? Do dirty caching. You wanna store and retrieve media content? Use CDNs. You see where I’m going with this?
This approach is comparable to the brute force approach of solving a programming problem! It gives you a certain confidence that no matter what system you are given to design, you’ll be able to do it with these building blocks! Thus, it is important to get a decent understanding on all of this so that you can expand on them as you go along. There are many nuances and tradeoffs are there but the approach 3 later in this section will prepare you for that.
Approach 2: Commonly Occurring Systems: The grokking course page provides one thing for sure — the list of commonly occurring systems. It is probably clear by now that I despise this exploitative business trend around various interview preparation platforms/social media influencers preying on millions of hopeful candidates and indirectly telling them “buy our question/solution sets, mug them up and get a job at Facebook/Google”. Sad part is a lot of them are FANG alumni and they should know better that it does not and should not work like that.
Open Google and study the solutions for these list of problems to get an honest understanding of how stuff works. There are quite a few youtube channels that have decent cursory solutions for common SysDesigns. Gaurav Sen, and Narendra L comes to mind. There are many others.
Understand that these are some garden variety solutions to very complex problems. Design decisions depend on many things and they come from a lot of experience from actually designing complex systems. Unfortunately not many of us will have that hands-on opportunity so, here comes the last part of my approach — standing on the shoulders of giants.
Also, while you’re at it, practice these designs on the physical whiteboard that I’ve told you to purchase while keeping time! Use this for the actual interview if you are interviewing virtually! This will save you a lot of pain.
Approach 3: Learning from the “Horses’ mouth”: Perhaps the most important step is what Jackson’s video tells us at the 43 min mark — to go through the actual tech talks and deep dives into systems form the actual designers. You know what is a goldmine that almost no one I’ve asked around knows exists? The Facebook Engineering page. You see, most people think Facebook’s products are the FB app, IG, WhatsApp, Occulus and so on while the contributions of Facebook engineering are far more than these consumer facing products. There are a plethora of just brilliant internal and open sourced tools like Cassandra, Haystack, Scribe, Spark, PyTorch, GraphQL and so many others. Please learn about them. Bonus point — do you know Facbeook has a podcast all about mobile and related tech?
Next, start expanding your circle to other giants namely Netflix, Twitter, Instagram, Snapchat, Dropbox, Tesla, not to mention, Google! Here’s a video where they take a deep dive into Netflix’s famous ZUUL gatekeeping system.
Or perhaps the challenges Instagram faced while scaling the system for billions of requests in a matter of months.
Or perhaps Slack?
My point is, there are plenty of resources out there that covers incredible depth. You need to actively seek them out, pick an interest area and keep learning — not just for passing an interview but to actually understand how these work. Its fascinating!
3. Behavioral Preparation:
I must confess I did not prepare much for this which is why out of the 6 Onsite interviews I had, my behavioral went the worst despite having a wonderful interviewer making me feel comfortable throughout. My strategy was to be objective, honest and candid. However the lack of practice meant I became too comfortable during the interview and swayed from the topic at one point. Don’t let that happen to you. Jackson Gabbard to the rescue again!
I have interviewed a few people in different capacities and it is quite easy to sniff the dishonest out even for a formally untrained interviewer like me. Trained interviewers at FANG companies will be able to smell dishonesty a mile away. Don’t be someone else — be yourself. Be honest. Be to the point.
Conclusion — Study Honest:
Everyone says “Study hard, study smart”. I haven’t seen many saying “study honest”. Please realise and remember that there are a lot of factors that ultimately influence the final outcome of an interview; so don’t make “getting the FANG offer” your ultimate goal. This might sound pompous (and a bit like survivor’s bias) but making your objective to be a better engineer will be beneficial either ways and you’ll likely see the fancy outcomes are all falling into their own places sooner or later. Being brutally honest about whether taking shortcuts to an apparent success is going to work for you in the long run will also help your future career progression. In short — Study honest.
Ask yourself: What would you do if you weren’t afraid?
