Meta Software Engineer Interview Experience — Phone Screen Plus a Four-Round Virtual Onsite

Meta phone screen + virtual onsite writeup, with the questions and my thought process included.

Since I signed an NDA, I'm coding the problem names as homophones — sorry about that.

Phone Screen

45 minutes, two questions. The first five minutes were self-intro, and pretty much the rest of the time was spent coding.

Question 1, coded 1091: a 2D grid, get from the top-left corner to the bottom-right corner, where 0 is walkable and 1 is not. I first walked through both BFS and DFS approaches out loud, and the interviewer let me pick one to actually write — I picked BFS. After I finished, the follow-up was to print out the path. My first instinct was to carry the whole path along in the queue, but the interviewer hinted that there might be a more space-efficient way, so I switched to maintaining a parent map in the queue and reconstructing the path by walking backward from the endpoint at the end.

Question 2, coded 560: given an array and a target, count the number of subarrays that sum to the target. This one was basically a freebie — prefix sum + hashmap, done in five minutes. The interviewer asked me to come up with my own test cases, and I mentioned an empty array, a single element, all zeros, negative numbers, and target equal to 0.

One thing worth flagging for everyone: Meta really does care about test cases. I saw this mentioned in a bunch of posts on this forum too — you should dry-run every problem yourself after you finish writing it.

VO Coding 1

The interviewer was very nice, and interactive the whole time.

Question 1, a variant of 162: instead of finding a peak, find a local min, same binary search approach. I talked through the approach out loud first, and the interviewer pushed on a few edge cases: what if the array only has one element, what if two adjacent elements are equal. After I answered, I started coding, made a typo along the way, and the interviewer pointed it out directly. My sense is Meta doesn't require you to be bug-free on the first pass, but your logic needs to be clear, and you need to run your own test cases.

Question 2, coded 680: delete one character and check whether the string can become a palindrome. After I finished, the follow-up was what if you can delete K characters. I said switch to recursion plus memoization, treating (left, right, k) as the state. The interviewer asked about complexity, and I said O(n*k).

VO Coding 2

I ran into a variant in this round and got a bit rattled.

Question 1 was a variant of 200 — instead of directly asking for the number of islands, you had to implement an API, something like isSizeExist(int size), that asks whether there's an island whose size is exactly that number. My approach was to precompute all the island sizes with DFS first, store them in a HashSet, and then the API just does an O(1) lookup.

I made a mistake here — I initially put set.add() inside the DFS itself, and only caught it when running test cases and fixed it. I'd been grinding a lot of backtracking problems recently, and the muscle memory got me.

Question 2, coded 129: sum up the numbers formed by concatenating the digits along each root-to-leaf path in a binary tree. Standard DFS, finished it quickly, and spent the leftover time talking about the iterative version and whether recursion could stack overflow if the tree is very deep.

System Design

The question was to design a system that can search text-only status updates users post, supporting AND and OR query conditions.

I started by clarifying a few things: roughly what QPS, whether real-time search needs to be supported, and whether we needed to worry about ranking and relevance. The interviewer said not to worry about ranking, and to focus on the data structures and storage.

I then went in the direction of an inverted index — a mapping from term to a list of status ids, where AND is an intersection and OR is a union, and keeping the lists sorted lets you use skip pointers to speed up intersection. The interviewer seemed fairly satisfied and then started digging deeper: when a user posts a new status, how do you update these indexes?

That's where I had to talk about tokenization, normalization, and indexing. I described a rough pipeline: on write, push into a message queue first, have the consumer do tokenization and normalization (case folding, stemming, stop words), then update the index.

The interviewer then asked what happens if the index gets too big to fit on a single machine. I said shard based on term, using consistent hashing. He followed up asking whether a query with multiple terms would need scatter-gather, and I said yes, then we talked through the tradeoffs between sharding by term versus sharding by document.

This round went fairly smoothly, mostly because I'd seen this exact question mentioned in a post on this forum beforehand and had already looked into it.

BQ

The interviewer was pretty serious the whole way through, one question after another — felt like he was watching the clock.

• Most proud project, and it had to be a recent example
• Talk about a project you had to start on with incomplete information
• The project changed direction halfway through — how did you handle that
• What critical feedback have you gotten, and what did you change afterward
• An experience working with someone difficult to work with

I'd prepped six or seven stories total and ended up covering basically all of them. My sense is Meta's BQ is genuinely collecting signal — for every question he'd dig into the details: what exactly did you do, why did you decide that, was there data to back it up, what would you do differently if you did it again. So you can't just give a story in broad strokes, you need specific numbers and outcomes.

Some thoughts

Fluency matters more than anything else. Meta's questions really aren't that hard — like 90% are medium — but two questions in 45 minutes is genuinely tight. Go through the frequently-asked questions on this forum two or three times so that once you see a problem, you can lay out the approach, write it, and run test cases within 20 minutes.

Don't dump all three approaches on the interviewer right at the start. I saw a post on this forum saying that makes it look like you memorized the answer. A better way is to build up gradually: start with the most direct approach (say, using a map to track frequency and then sorting), then point out its own weaknesses (wastes space, needs a full re-sort when new data comes in), and only then naturally arrive at the optimal solution (a heap, O(K) space, O(logK) time). Saying out loud the reasoning of "given this constraint, trying to achieve this efficiency, so I'm choosing this method" is more useful than just throwing out the optimal solution directly.

Always come up with your own test cases. Almost every interviewer asks for this — have empty set, one element, two elements, all identical, all increasing, all decreasing, and has duplicates memorized ahead of time.

Take BQ seriously. Especially for a slightly higher level, the quality of your stories directly determines the signal. Take the same "how did you resolve a conflict" question — "my coworker and I talked it over and reached an agreement" versus "I drove cross-team alignment, wrote a doc, ran meetings, summarized in the channel, and got the timeline realigned" — these send completely different level signals.

If you get stuck, say so out loud. In one round I went down the wrong track, and it was the interviewer's hint that got me back on course. Rather than silently thinking for five minutes, it's better to say your current line of thinking out loud and let the interviewer help redirect you.

Wishing everyone a smooth landing too!