Position: Senior Software Engineer -- Machine Learning

Education and background:
Undergraduate: MS in engineering from a top school in Europe
Graduate: MBA from a top10 school in the US
Graduate: one year of MS in applied math (didn’t graduate but took a few classes)

I’ve never been (nor am I) a fan of “classical” software engineering roles per se. I find this job boring and requiring a special type of personality and mindset. However, a few years ago, after some time spent in investment banking and on the buy-side, I transitioned into what later got called “data science.” Soon I became bored by analytics and uncovering “insights” and started focusing on more academic aspects of machine learning. It immediately clicked with me (think of things like Kullback-Leibler divergence or cross-entrophy), and I decided to interview for more complex roles requiring deeper knowledge of ML concepts. I never thought of getting a PhD at that point, though, mostly because of opportunity costs and my inability to get into top programs anyway. Most recently, I’ve been working for one of the most recognizable tier2 tech companies.

First contacts with Facebook:
I received a LinkedIn message from a recruiter sometime last summer. We chatted on the phone and shortly after she confirmed that I could proceed with interviews. I was pleasantly surprised by the fact that the company didn’t rush me at all and was willing to give as much time to prepare as needed. I told the recruiter that I would need three weeks to get ready for a phone interview.

Coding:
As you can guess, three weeks wasn’t enough time to become a pro in Leetcoding. The website (as well as Reddit and other online sources) has a lot of decent posts about prep strategies. After going through these posts and not being able to solve questions like Valid Palindrome, I decided to push a phone round even further. During the prep phase, I developed these rules:

1. Consistency and discipline. I solved Monthly LeetCoding Challenges without a single day off. I was doing my prep work first thing in the morning while my brain was fresh and ready. I guess the quality of work I was doing for my then-employer took a toll but it was a trade-off I was willing to make. But again -- if you work in a huge corporation, it won’t go bust just because of one person preparing for interviews.

2. Progress tracking. I’ve created a huge spreadsheet to which I was adding problems after solving them. It has a following structure (below are columns’ names):
   Name of the problem and the link | Topic | Result | Reviewed at | My code | Summary
   Topics are tags such as “string,” “DP,” “backtracking,” “graphs.”
   “Result” is whether I was able to solve it, how much time it took, etc. Most often, however, the value in this column was “No clue.”
   “Reviewed at” contains the most recent date
   “My code” is a link to Github where I put solutions. I tried to have at least two solutions to each problem. In the comments, I would state time and space complexities and add a few sentences about how it’s solved.
   “Summary” is a very brief description of how to solve a question. For example, for Linked List cycle, I wrote: “Fast and slow: if they meet, there is a cycle.”
   I’ve also added some cell coloring to highlight the most frequently asked questions later for specific companies.
   This set-up helped me to quickly navigate through the pile of problems I worked on.

3. Learning the basics. I strongly believe that having a CS degree isn’t a prerequisite for passing a Leetcode interview. However, I did spend some time on the theory. I used the following materials:
   Books: “Grokking Algorithms” (it might be too basic for most of you, most likely)
   “Cracking the Coding Interview” (it used to be a must but not anymore. I hate this book)
   “Elements of programming interviews in Python” (this one is also tough but resonated with my way of learning more than CTCI did)
   Youtube: Introduction to Algorithms (if you want to really learn, have time and patience)
   Algorithms by Abdul Bari (in case MIT is too much for you)
   Vivekanand Khyade -- Algorithm Every Day (a huge fan of this guy, he’s so patient in his explanations)
   Kevin Naughton Jr. covered a lot of problems
   Sai Anish Malla posts excellent explanations of Leetcode problems
   Back to Back SWE might or might not work for you but give it a try

4. Talking out loud. Make an effort to learn how to talk and code at the same time, it will be helpful in any interview.

5. Specifically for Facebook, don’t waste time on implementing brute-force solutions in an interview but rather move to the most optimal one(s).

After approximately six months of studying, I scheduled a phone interview. As you see in this post, I didn’t solve the questions flawlessly but did a decent job in communicating my thinking process. As such, I received an email a couple of hours later saying that I passed the round. My further coding prep wasn’t much different from what I described above.
My coding questions were all FB-tagged. They weren't the most popular ones based on the Problems Set but I came across all of them during the prep phase. I was asked a variation of “Reconstruct Itinerary,” “Game of Life,” “Missing Ranges,” “Word Search,” and others.

System design:
After I cleared my phone round, I asked for five weeks to prepare for an on-site. This is when I touched system design materials for the first time in my life. Overall, I found these questions easier than programming. Probably it will be a case for anyone who is coming from a liberal arts background or who ever interviewed with consulting companies. A liberal arts background helps to process large amounts of text, while any experience with solving cases is very applicable to requirement-gathering, driving a discussion, and presentation aspects.
Books: Designing Data-Intensive Applications is a must. It’s a thick book and, most likely, you won’t need to read the whole thing but you definitely have to have it on your desk (or an electronic version in case you have an O’Reilly subscription).
System design Interview -- An insider’s guide has a few solved examples, and I found the author’s writing style very easy to digest
Youtube: there are many videos with problems like “Design Twitter,” “Design a queue,” etc. You probably want to watch a few of them and find the ones that resonate with you most.
Courses: Gr the System design interview is a must.
Classical System Design Primer is a good starting point.
A tremendous repository with hundreds of links to every possible paper and article. You have to choose wisely, otherwise you’ll never finish reading all the links.
Another similar repository with many many links.
I solved most of the common problems on my own and drew solutions in Google Drawings.
In my designs I was following the following sequence: gather requirements (functional and non-functional), capacity estimates, basic design, discussion of bottlenecks and potential problems (mostly around scaling the solution), design of databases (if applicable), improvements to the original design, distributed aspects (sharding, caching, potential problems, such as inconsistencies if two requests from the same user land on different nodes, etc.)
I think that the key here is to be able to drive the whole discussion on your own. At the same time, I made sure I was checking in with my interviewer regularly, making sure I was on the right track. At the same time, I showed that I didn’t require too much handholding and could make trade-offs and design decisions.
In my interview, I was asked to design a HackerRank-like service.

ML design:
This is probably the least covered type of an interview. Usually questions revolve around various recommendation- or feed-based systems. Facebook has put together a Field Guide that gives an accurate idea of what you need to be able to talk about. On the theory side, make sure you understand how to build scalable solutions (most likely, you’ll end up with some sort of neural networks), how to handle sparse data (embeddings), and be able to talk high-level about traditional models (SVM, regressions with regularization, tree-based methods). You cannot overlook the serving portion: be ready to discuss how you will make inference and provide model’s results to your users. Often you cannot run inference in real-time and need to precalculate your recommendations, for example. In System design, you’ll come across such things as “pre-warm cache,” and these approaches can be used in the ML round, too. Another topic to pay attention to is feature engineering. Be able to provide examples of features you want to build for a given problem.
Courses: Gr the Machine Learning Interview and Machine Learning Design from the same site are the must.
This repository is the best starting point.
Production Level Deep Learning is a great source, too.
Here you can find a good number of links for further reading.
Finally, a huge list of papers and articles -- in case you have 6-8 months for the prep.
Pretty much every tech-company has an engineering blog where they discuss various problems and solutions. Reading some of the articles was very helpful. I paid a lot of attention to Facebook’s, Instragram’s, AirBnB’s, Uber’s, DoorDash’s, eBay’s blogs.
In my interviews, I was asked to design various variations of recommendation engines for several newsfeeds.

Behavioral round:
To me -- given my background -- that was the easiest round. You can easily find dozens of example questions online and explanations of the STAR approach. Facebook interviewers were focusing a lot on conflict resolution, on examples of ambiguous projects and misunderstandings/conflicts with the peers/managers. You need to prove your maturity and ability to resolve conflicts without burning relationships with another party and without escalating. Your ability to foresee problems and stay humane are also important.

PRACTICE:
I’ve done a lot of mock interviews: around 15 coding, 5-7 system design, 5-6 ML design, 4-6 behavioral interviews using my industry peers. As a result, I never had to solve a problem from scratch or come up with an example I never practiced before.

Negotiation:
I ended up with three offers. In addition to FB, I had an offer from another major social network and the most popular music service. I was able to use these offers during the negotiation and get very close to the top of the band. You can use levels.fyi once you get to this point.
Overall, it took almost 9 months between the first contact and a written offer. It was great to see that Facebook was willing to invest so much time in the process.

Summary:
Practice and consistency definitely beat talent and a CS degree. At least during an interview loop. Don’t reinvent the wheel and follow the steps of those who already went through the process.