Meta Software Engineer (L3) Interview Experience
Meta · Entry level · Software Engineer
In the age of AI, I could feel the interviewer adding little follow-up questions just to make sure I actually understood the problem, because if you were using AI tools, there’d be a lag. Even clearing the onsite doesn’t mean you’ll find a team quickly.
Interview process
It was pretty standard overall, but what stood out was how much they seemed to care that I really understood the problem and was not just spitting out a memorized answer. I had interviewed for this role before and made it to the final round, so this time they skipped the online assessment and started me with a phone screen after a recruiter call. After I passed that, I did a final loop with three technical interviews and one behavioral. The technical rounds were mostly straight-forward coding problems, but with more pressure on explaining brute force first, optimizing from there, and defending why I chose one approach over another. One thing that really matters is you cannot run your code, so you have to manually trace it and prove it works. The recruiter also made it clear that if you clear the loop, team matching can still take a long time depending on how specific you are about office and team preferences.
Interview rounds · 3
- 1
Recruiter screen
I had a recruiter call before the phone screen to go over the process and expectations, and then another one before finals where we talked about office preference, what kind of work I wanted, and how being picky can make team matching take longer.
- 2
Phone screen
CodingData Structures & AlgorithmsTechnicalMy phone screen was a standard coding round, but the interviewer kept pressing on why I picked a certain approach, what alternatives I considered, and whether I really understood the graph problem instead of just pattern matching it.
Q1. Given a graph traversal problem, return the integer for the longest path.
How they answeredI broke it down from brute force first so I could show I understood the proof of solution, then I talked through what was expensive in time complexity and how to improve it to the optimal version. I coded that out and then handled the follow-up of returning the actual path. What stood out was that he kept asking why I chose a certain traversal and what else I could have done, which felt very much like he wanted to verify I really understood the problem.
Follow-up questions- Why would you use DFS or BFS here, and why is that better?
- What other alternatives would you consider?
- Can you return the actual path, not just the length?
- 3
Final / onsite round
CodingData Structures & AlgorithmsTechnicalBehavioralMy final round was four back-to-back interviews: three technical and one behavioral. The technical side felt pretty standard for this company, but one thing people forget is that sometimes they want full class design, not just a single function. Also, you cannot run your code, so a big part of it is manually walking through an example and proving your solution works.
Q1. Solve a problem similar to Minimum Cost to Connect Sticks using a priority queue.
How they answeredI remember this one mostly by the pattern. It was very similar to Minimum Cost to Connect Sticks, so the key was recognizing it as a priority queue problem and building the solution around that. I do not remember the exact wording, but it was one of those rounds where identifying the right data structure early mattered a lot.
Q2. Build an entire class/object with different functionalities, and optimize one of the operations with binary search.
How they answeredI treated it as class design, not the usual one-function LeetCode problem. The important part was implementing multiple behaviors cleanly and then using binary search to optimize one of the operations. That round reminded me that for this company you really need to be ready for object or class-style coding questions, not just helper-function problems.
Q3. Solve a hard graph problem that involved topological sort.
How they answeredI remember this one as a pretty hard graph problem, and the main pattern in it was topological sort. I do not remember the exact prompt now, but it definitely felt like one of the tougher rounds in the loop.
Q4. How do you begin your work when you receive a new task or project?
How they answeredI walked him through my workflow for taking on a new task or project. My sense was that he was trying to understand how I work by myself and how I fit into a team, and he reacted really positively to that answer.
Q5. Tell me about a time you faced a tough problem at work and how you handled it.
How they answeredFor this question, my read was that he was really testing how I deal with ambiguity. That whole round was less about technical depth and more about how I think and operate when things are not fully clear.
Q6. Tell me about a time you had a disagreement with coworkers and how it was resolved.
How they answeredI framed it around how I work on a team and how conflicts get resolved. The interviewer told me afterward that he gave me a strong hire for that round, so I felt like the behavioral part landed well.
Tips from the candidate
Practice talking through the problem, not just solving it. I would always start with brute force, explain what is expensive, then show how I would optimize it. Also practice dry-running your code by hand because you cannot run it in the interview. Study the building blocks deeply, like graph traversal, topological sort, sliding window and even the sub-patterns inside those, so if you get something you have never seen before you still know where to start. And do not only prep one-function LeetCode questions. Be ready to implement a whole class with different functionalities too.
Company culture
What I noticed is they seem a lot more intentional now about making sure you actually understand the problem. I got more follow-up questions like why DFS instead of BFS here, what other alternatives are there, and that felt very tied to the whole concern about people using AI tools in interviews. The process still felt standard, but the interviewer was checking understanding much more aggressively than just checking whether I could land on the right code. They also put real weight on problem solving out loud, not just the final answer, especially since you cannot run code.