Updated by Meta candidates
Software Engineer (E5) Interview Experience
I had done really poorly on the easy coding question, but I still got through to the next round, which was really surprising. Then in behavioral, the interviewer said, "that does not sound like a conflict," and I had to change my story on the spot.
Interview process
A recruiter cold-reached out to me for an E5 software engineer role, and the whole process felt very standard Meta. I had a short recruiter call, then a coding screen with two common problems in one session, and I actually did poorly on the easy one but still barely made it through. After that I got the full loop spread across multiple days, and they gave me a few weeks to prepare. The final coding rounds were mostly standard too, but I felt weak in behavioral because I did not have the right work stories ready, especially for conflict, and I think I mishandled system design by not controlling time and not setting scale assumptions myself. I got the rejection after the final round.
- Recruiter screen
- Phone interview
- Final round
Interview tips
I would treat this as a very standard Meta process, but the bar is still a little above what an average prepared person can get away with. I would absolutely do the most common coding questions, but for system design I would not just watch videos. I would go deeper on core concepts, come up with my own design first, and then compare it with a strong answer to understand why each piece is there. I would also practice under time pressure so I stay focused on what was actually asked instead of going in different directions. And for behavioral, I would have real work stories ready, especially a story that is an actual conflict and not just a mild disagreement.
Company culture
My impression was that Meta's process here was extremely standardized. The recruiter was checking pretty clearly for E5 signals like years of experience, project ownership, and mentoring, and the coding questions really did feel like the common top questions people prepare. What surprised me is that they still moved me forward even though my screen was borderline, so they seem willing to let a candidate prove themselves in the full loop if they are close. At the same time, the final bar felt strict. In behavioral, the interviewer was precise about what counted as a real conflict, and in system design they expected me to set the scale and constraints myself instead of waiting to be spoon-fed numbers.
Questions asked
Overview
The final loop was four interviews spread across multiple days, and I had am few weeks to prepare for it. My first round was behavioral, which threw me off because the interviewer narrowed what kind of story they wanted, and I do not think I handled that well. The two coding rounds were mostly standard Meta-style questions, with one question I had not seen before, and I felt okay there. The last round was system design, and that was where my time management and lack of self-driven assumptions hurt me the most.
Question types asked
Specific questions asked
Please don't use a project outside of work.
How did you convince your manager these tasks were worth pursuing?
What specific challenge came up in that project, and how did you overcome it?
I had actually prepared a different story, so I was surprised when they explicitly told me not to talk about something outside of work. I switched to a work project and explained why I was proud of it, but I felt shaky because I was not sure what exact shape of answer they wanted. They kept drilling into how I convinced my manager the work mattered and how I handled specific hard parts, and I do not think I framed those parts strongly enough.
That sounds like a disagreement, not really a conflict. Why was it actually conflict?
I first used a story about disagreeing with my manager, but the interviewer pushed back pretty directly and said it just sounded like I made my case and then my manager agreed. That made me realize I had not explained why it was a real conflict in the first place. I had to switch to another story on the spot, and honestly I still do not think I answered the conflict part well.
How would you handle the traffic spike when everyone tries to book at once?
How would you make sure the system stays consistent so we don't lose people or oversubscribe?
I built the design around the reservation path and tried to focus on the surge case where a drop happens and everyone is booking at once. The interviewer cared most about handling load and keeping consistency so we do not lose users or hand out the same inventory incorrectly. The mistake I made was that I waited for them to give me scale numbers instead of driving that myself, and they never did because it was open-ended. I also kept my answer pretty standard and did not ground it enough in concrete technologies or sharper tradeoffs.
Get full access with a membership, or share your experience to try it free.
