YOE: about 10 years
Position: E5 at Facebook
Location: London
Date: March - April 2020

Technical phone screen: (45 min)

• Q1: A string / array problem involving distinct characters and window
• Q2: https://leetcode.com/problems/shortest-bridge/
  Solved both pretty fast and bug-free, tested the code and discussed the approach and time complexity. However, I learned afterwards that I was expected to proactively talk about time versus space complexity, and test the example case without running the code.

Virtual Onsite: (2x 45 min coding, 1x 45 min behavioral, 1x 45 min system design)

Coding 1

• Q1: https://leetcode.com/problems/convert-a-number-to-hexadecimal/
• Q2: https://leetcode.com/problems/rotate-array/
  Solved the first quite quickly and optimally. Then we extended it from there and discussed all the possible low-level optimizations like bit manipulation, loop unrolling and multi-threading.
  Q2 took me some time because I knew it can be done in O(1) space, but couldn't see the pattern immediately. With some hints I managed to solve it optimally.

Coding 2

• Only 1 question: https://leetcode.com/problems/serialize-and-deserialize-binary-tree/
  Solved it optimally in 10 minutes using my special solution which (I think) is more elegant than the usual ones you see in the discussion, but would require some expertise in C++.
  Then the interviewer bombarded me with all different kind of computer science and software engineering questions for the remaining time of the round.

Behavioral
Work experience, past projects, standard "tell me about a time" questions, hypothetical scenario questions

System Design
Some question related to caching and balancing. Not exactly the "design twitter" type of question, but expect to talk about different components, latency, throughput, consistency and availability.

Result:
I heard back about 2 weeks later and was offered an E5 position.

Thoughts:
They are obviously looking for programmers with high coding-strengths. Unlike Google who favors curious people with good math instinct for tackling new problems, Facebook expects a strong candidate to know basic algorithms and a programming language extremely well in order to apply them in coding both quickly and bug-free.

Preparation:
I have mainly trained myself using LC questions and contests for the coding part. I managed to solve 1,020 questions on LC in the past 1.5 years, after I failed my interview with Fb and Google last time. After 3000 submissions and more, I admit that all except a few LC questions are indeed just the basics (compared to those harder and more interesting ones in competitive programming).

For system design I read and practiced the *** system design starting with letter "G".

As a side-effect of the training, I also start to see structures everywhere in real-life objects or activities that I never thought would be related, e.g. moving the mouse cursor is binary searching the hand's direction using the cursor's position, and that's the reason Fitts' Law contains logarithm. Or that the best strategy writing code on a physical whiteboard is using a different function for each snippet whenever possible, because chaining these functions is similar to chaining nodes in a linked list which allows much faster insertion and removal, unlike the traditional code block which is an array of letters that's painful whenever you try to insert anything in between.

In the last days before my onsite interview, I switched to a new account and time-attacked the top fb-tagged questions. The aim was to solve every question within time limit, in a single-shot submission without debugging, and without memorizing the solution. The solution must come naturally, i.e. it simply feels right for that problem.

My LC progress:

I highly recommend training LC problems in a breadth-first order: try to come up with the right algorithm, and if you can't do it after some threshold (say 20 min for medium questions), look up the solution for learning and move on to the next question without completing this one. Because if you complete it, all you do is applying the short-term memory from the solution on the problem, which wouldn't be helpful in the long run. The same principle applies to coding - if you can't get the code accepted in the first attempt without debugging with confidence, then your coding has an unidentified flaw. Now exposing the flaw is much more useful than completing the problem with a lot of debugging, which is both a waste of time and hiding the actual flaw. (For example, my flaws are keep forgetting about valid integer ranges, ignoring modulo arithmetic, and confusing between if and while in very complex logic.)

Update: Why solving problems in breadth-first fashion? Because unless you want to play the russian roulette, the coding interview can be characterized as requiring the candidate to reach certain skill level, judged by certain criteria. We know those criteria are Leetcode. Does this remind you about all the "Shortest Steps To Reach Some State" which typically can be solved with BFS? :)

Hope this helps ;)