I have read several informative posts on LeetCode regarding FAANG interview experiences, so I figured it was my turn to contribute.

I made it pretty far. After the "vitual onsite" interview, my "packet" (containing the feedback of my 4 interviewers) was given thumbs up by an initial group of reviewers and then passed on to a more senior group who rejected it. While I am not totally sure why, between my wife and myself, we have some theories. For starters, the weakest feedback came from the "System Design" portion. I had actually opted for a "Product Design" and received good feedback on that. However, there were some comments about I did not design certain aspects of the system "to Facebook scale". I knew that I was missing a component and asked the interviewer for help. Overall, the feedback was good, but not great for that portion. My wife has a theory that Facebook likes to have "brand champions" in its employee base. I do not have a Facebook account, I had actually deleted it a while back quietly. Perhaps when the upper level execs were deciding whether they wanted to hire an experienced engineer like myself, and my application was kind of on the fence, this played a factor. It is hard to say for sure, but I did think that was an interesting take.

The recruiters that I worked with were really top notch. I was contacted through LinkedIn and asked to do an initial phone screening. The expectation is that you complete 2 coding questions in 45 minutes. I am not going to give the exact questions, but needless to say, you can easily find most/all of these questions on LeetCode. Something to note for interviewers, Facebook interviewers are more ore less "discouraged" from asking Dynamic Programming questions! How do I know? I watched some recorded prep videos provided by Facebook and they said as much. I can confirm, that out of the 7 coding questions I received in total, 0 of them required Dynamic Programming. This was a bit of a relief to discover because once I started digging into that subject, I realized it was not my strong suite.

Back to the initial phone screen. I did well! I answered both questions well enough for the interviewer to recommend me to the next round. One of the questions was an array-type searching question and another was related to binary tree traversal. Again, you can find the exact questions or ones like it easily on LeetCode. Although something that I learned over the course of my interview, memorizing solutions is not good enough. I had seen/solved about half of the questions that I encountered during my interview. Every single time, the interviewer asked follow-up questions, asked for explanations, asked for my thought process, etc. A huge and understated component of this type of interview is communication and explaining things. You must be able to show that you are able to critically think on your feet.

A while back, I actually had an interview with Amazon and one of the major things that I took away was that in order to do a 4 hour interview, you need stamina! I kind of petered out toward the end of my Amazon interview, so for Facebook I decided to drink some Zipfizz. It is similar to 5 hour enery drink and they sell it at Costco.

The format for the "virtual onsite" interview was 4 x 45 minute interviews with a 45 minute break in the middle.

1. Behavioral - Pretty standard stuff. How do you resolve conflict? Tell me about recent projects. What did you do when you ran into issues? At the end of this interview, there was a "warm-up" coding question that I solved easily.
2. Coding - The first question was related to linked lists. The second was a very popular question on LeetCode. Again, referring to my comment above, simply solving the popular question was not enough. For follow-up, the interviewer asked for a specific way to optimize it for memory that is not on LeetCode. The LeetCode solution has 3 ways to solve it, I did it using 2nd most optional solution and I think it was the right choice. Afterwards, I watched a video on YouTube regarding Facebook interviews and they sometimes ask a question with multiple solutions with the most optimal solution being difficult to implement. The expection is that candidates who try to implement the most optimal solution might run out of time or have a bug. The more "practical" candidates who solve it in an unoptimal way and finish are better off. Then you mention "there is an optimal solutions" for bonus points.
3. Coding - The first question was a very popular question on LeetCode. The second question was one that I had not seen, but related to intersection of lists. I solved it in an "optimal" way when lists are similar size. For follow-up, the interviewer gave examples of lists that were totally diffent in size, I ended up writing a 2nd algorithm. For follow-up on that, the interviewer asked how to choose which algorithm to use - which boiled down to calculating Big O. Do you see a pattern here? Knowing how to write algorithms quickly is needed, but not enough.
4. Product Design - This was the interview that I had probably the least amout of preparation for. This is probably the part of the interview where being remote hurt me as I was using Google Drawings to draw out my API's, components, etc. You need to really dig into this. Some of the feedback that I got was that I did not dig deep enough. Towards the end of the interview I ended up mostly talking instead of communicating through Google Drawings. It might have been easier to draw out my system on a whiteboard, I am not totally sure. This is the part of the interview that seemed the most open ended to me and it might have been my downfall.

In case folks ask, I have solved 250+ LeetCode questions. I did subscribe to Premium for a while and did several Mock interviews that I believe helped in terms of getting my timing down.

Not sure what else there is to say other than I hope some of you find this helpful.