Background
A recruiter cold-emailed me about an E5 position at Meta two years ago. I was already half-looking to leave my job, so I went for it. I made it to the last round, but the product architecture round and one of the coding rounds went badly for me.
I'm back this time because layoffs look likely where I work now, and I wanted to prepare differently. My prep came down to three things: an online course, a paid LeetCode account, and lots of mock interviews. Once I cleared the online screen I set a one-month window for myself, partly to avoid burning out. The idea was that a month of real focus could pay off for years afterward.
My interviews were not flawless. The main lesson for me was that you don't have to be perfect, whatever people on Reddit and similar sites make it sound like.
Preparation:
Coding doesn't come naturally to me, so I went through almost all of the coding lessons in the course, leaving out dynamic programming since Meta has traditionally stayed away from it. The lessons broke unfamiliar concepts down simply and drew out how the algorithms work. Each coding section had an AI helper that told me what was wrong in my code and cleaned up my syntax. If coding is where you struggle, my advice is to lock in the concepts first with lessons like these. The practice problems there are mostly ones Meta tends to ask, so they help with spotting patterns. On LeetCode I worked through nearly all of Meta's last-30-days list, and I tracked everything in a spreadsheet: the problem, its category, how hard it felt, and whether it needed a second pass. A list of recent, frequently asked Meta questions also helped me. One example is Help Mouse Find Cheese, a typical backtracking problem, in a variant you won't find on LeetCode.
For the AI-enabled coding round I practiced in an AI coding sandbox. Its problems weren't identical to the ones I got, but they were close. I kept a Google doc with the standard solutions for each problem, and I went through most of them two times (there were around 4). Doing that made me confident I could use the AI quickly and well and still explain what the solutions were doing.
I mostly flopped product architecture on my first attempt, and it carries a lot of weight at E5. This time I started by learning the usual technologies and patterns from system design lessons. Tradeoffs are what matter, such as being able to say why I'd choose Postgres rather than Dynamo, or websockets rather than SSE. Once I had that foundation I went on to the typical questions: video first, then the written walkthrough, then my own practice design. I didn't try to make those practice runs polished. Lots of people recommend a 40 to 45 minute timer, but I'd write up my answer, notice where it was weak, and ask the AI bot about the gaps.
The polishing happens in mock interviews, and that was a big change from my first attempt. I paid for mocks in three areas: behavioral, coding, and product architecture. If your budget allows, I'd say do it, and that goes for behavioral too. Hearing a current or former Meta engineer go over what worked and what didn't in my mocks settled my nerves and let me perform better on the actual day.
Interview
I scheduled the rounds across two days. I'd advise doing the same instead of squeezing everything into one day, because the rounds wear you out and you need time to recover.
I felt the behavioral round went well, though my interviewer was having connection problems. She offered to let me redo it, but I declined, since I'd already told some solid stories that I thought showed senior-level leadership and depth. My guess is Hire, maybe Strong Hire.
The AI-enabled coding round went by fast for me, and I even got to the bonus question. You should really use the AI tools, but you also have to prove to the interviewer that you understand the work, by checking what the AI produces and explaining the algorithm. I tend to want to show off what I can do myself, so in my first practice sessions I never used the AI. Getting through all 4 sections unaided is hard though, and as I understand it Meta cares about speed, particularly in AI coding, so try to demonstrate it. I'd call this one a Strong Hire.
Algorithmic coding is where it all went wrong. I got through the first question quickly, but the interviewer's follow-up was a LeetCode hard, and he told me we had to move on before I'd cracked it. I had decided that a solution had to be perfect and fully working to pass, so I lost my concentration at once and couldn't get the final question either. Afterward I felt awful and figured the whole thing was over. Somewhere between Lean Hire and Lean No Hire, I'd guess.
I spent an hour wallowing, then decided to give the product design everything I had, since I owed that to myself after so many hours of prep. I had practiced and gone over that exact question many times. I gave the high-level overview and then discussed 3-4 deep dives. I was sure it was a Strong Hire, but the recruiter later passed on that I hadn't spent enough time on UI, which is expected for a Product Engineer role, though I passed regardless. That puzzled me, because no one had asked about it. The takeaway: if the role is Product Eng, check with your interviewer whether they want UI design covered. Given that UI gap, I'd guess this was a Hire.
Follow Up Interview
When the interviews ended I counted 3 Hire or Strong Hire results against 1 Lean No Hire and assumed I was out. To my surprise the recruiter contacted me and said they wanted another data point on coding, so I could retake the algorithmic round.
On a call she told me to show more of my problem solving and to push toward working solutions. I allowed myself about 2 weeks to get sharper, partly because I'd taken a week away from studying after the first set of interviews.
During the week I did study, the biggest help was one more mock interview. I noted down what I needed to improve and was able to work on those things during the mock. I also went back over problems that had given me trouble. A lot of my interviews seemed to involve two pointers and sliding windows, which are techniques for working over a list, so I reviewed those as well.
After this extra effort I sailed through the first problem. The second was a LeetCode hard that I hadn't looked at in a long time. I kept talking throughout and went over possible approaches, and I did land on a solution, but time ran out before I could code it. To me that shows communication and problem solving count the most, and that copying a memorized solution won't carry you. Meta knows these problems are hard, and although you should aim to finish with optimal time and space, being able to explain your thinking and understand the problem is worth a lot. I figure it was a Hire, since a week later I heard I'd reached team match!
Final Thoughts
Getting through Meta takes a fair amount of luck, though steady preparation lets skill matter more. Not every round needs to be perfect. If one goes poorly, put it behind you for the next one, since you never know how it will turn out. In the coding rounds, nobody demands finished code for every question. Meta seems to accept that some are very difficult, and what they want is to see how you work through the problem and communicate. Whatever else you do, book the mock interviews if you can, because they pay off.
Discussion
Loading comments…