Hi everyone, I went through the loop for an E5 Software Engineer, Product role in the Bay Area. Below is a rundown of the timeline, how I studied, and what came up.
It started when a recruiter contacted me about the position. I put the phone screen roughly a month out so there was room to study. It consisted of two LeetCode problems in 40 minutes, which is the usual Meta setup. I learned I had passed two days later. After that I scheduled the onsite, with every round squeezed into one day, about a month after the phone screen so I could keep studying. The coding rounds there followed the same pattern of two LeetCode problems in 40 minutes. Three days after the onsite, I got word that I was heading into team matching. That stage was the slowest part by far, five weeks from beginning to end, though that was to be expected given it was late in the year. Things only really got moving once my recruiter began reaching out on my behalf. When matching was done, the offer negotiation went fast and was finished inside two days.
Preparation
- I practiced Meta-tagged LeetCode problems, ordered by how frequently they are asked
- I put together a list of the problems I didn't know how to solve and came back to them again whenever I couldn't recall the approach
How I approached the coding rounds
- Meta puts a lot of weight on speed, so I ran through the same sequence on every problem:
- Open by confirming the inputs and expected outputs with the interviewer
- Propose a minimum of two approaches, a brute force and an optimized one, and explain how each works in plain English
- Go over the tradeoffs together, backing the optimized pick with its time and space complexity
- Get the interviewer's buy-in on the plan before writing pseudocode for the optimized approach
- With spare time you can write the pseudocode; if you're using Python, or another language you're comfortable in, going straight to code is fine
- After the code is down, trace through it by hand as if you had debugger breakpoints, once with a typical input and once with an edge case. When you spot a bug, repair the syntax or logic and trace again, until the results line up with the outputs you worked out at the beginning
- Keep up the conversation the whole way through. An interview like this is a collaboration, not a written test.
For system design I used an online system design course. I would read the article first, then try to rebuild the design from memory, drilling the order of entities, APIs, databases, and then scaling and deep dives. I also played with comparing different prompts to work out why a given database or scaling approach suits one problem better than another.
The actual questions
Coding:
- Kth Largest Element in an Array
- Unique Paths II
- Best Time to Buy and Sell Stock
- A phone screen question from a LeetCode discussion post about E4 Meta phone screens
- Comparing two linked lists, also taken from a LeetCode discussion post about a Facebook phone screen
- Basic Calculator II, and the follow-up was Basic Calculator III
Product architecture system design:
The prompt was to design the frontend and APIs for the Facebook News Feed.
- This felt unlike a typical system design round. The conversation centered on the frontend, with no diagrams and barely any discussion of the backend. The interviewer gave me a mock-up of the intended UI, and we began from that
- From the mock-up I had to identify the UX flow and then derive the APIs. I made sure to cover cursor-based pagination, the shape of the API response, and the UX edge cases that come up with several different types of client
So that was my E5 SWE, Product loop. The onsite earned me a strong hire, and I think that may be the reason team matching began so soon, although I might just be flattering myself, so don't read too much into it. Hope this is useful!
Discussion
Loading comments…