Meta Phone Screen: What It Tests and How to Pass It
- Meta phone screen runs 45 minutes: ~5 min intro, ~35 min coding (two problems back to back), ~5 min questions
- Both problems must be completed — one perfect solution and a blank second is a weak signal; budget 17 minutes per problem
- No code execution in CoderPad — you find bugs by reading and tracing, so practice writing compiler-free code before the interview
- Four scored dimensions: problem-solving, coding, communication, and testing/verification — most candidates skip the last one entirely
- Meta interviewers are required to give hints before certification; take them, pivot visibly, and do not defend the wrong approach
- Silence is a red flag: narrate your thinking throughout, give the interviewer something to write about your communication
- Pass rate is ~50% among filtered candidates who already cleared the recruiter screen — the effective difficulty is higher than it looks
If you want a shot at Meta's onsite, you first have to get through the Meta phone screen. It's a 45-minute coding interview with one engineer, two problems, and no way to run your code. Most candidates treat it like a warm-up. The ones who fail treated it exactly like that.
There Are Two Different Screens. Know Which One You Have.
Meta's process has two early stages that candidates regularly confuse.
The recruiter screen comes first: a 30-minute conversation about your background, motivation, and rough leveling. No code, no algorithm questions. Take it seriously but don't over-prepare.
The technical phone screen is the actual filter. This is the 45-minute CoderPad session with a software engineer. Passing this is what gets you to the onsite loop. The rest of this post is about this round.
Timeline in practice: recruiter screen first, technical screen typically a few weeks later, onsite a few weeks after that. The exact spacing depends on scheduling and team demand.
What Happens in the 45 Minutes
The breakdown is predictable:
| Segment | Duration | What happens |
|---|---|---|
| Intro and resume | ~5 min | Brief background chat, low stakes |
| Coding | ~35 min | Two DSA problems back to back |
| Your questions | ~5 min | Ask something genuine |
The coding window is 35 minutes for two problems. That's 17.5 minutes each, which feels generous until the timer starts. You get no grace for spending 30 minutes on the first one. The second problem does not care about your elegant solution to the first.
Two Problems, No Code Execution
The two-problem structure is one of the most misunderstood parts of this interview. You need to complete both problems to have a real shot at passing.
A lot of candidates treat the second problem as a bonus. It isn't. One perfect solution and a blank second is a weak signal. Two clean-enough solutions with complexity analysis is the bar.
The other constraint that catches people off guard: Meta disables code execution in CoderPad. You can write code. You cannot run it. No syntax highlighting either.
Think of it like a chess move. You commit, then you wait. Every variable name, every loop bound, every base case has to be defensible before you press the next key. The "just add a print statement" instinct will not save you.
Practice writing code you'd trust without a compiler. Structured loops, explicit variable names, no "I'll fix that after I test it." The off-by-one errors you'd normally catch on the first run are the ones that quietly cost you the offer.
How Hard Are the Problems?
Officially, both problems are LeetCode easy or medium. In practice, the mediums lean toward the harder end of that bucket. The public "medium" tag spans everything from Two Sum II to LRU Cache. Meta's phone screen pool sits closer to LRU Cache. Expect a variant of merge intervals, a sliding window with a specific constraint, a graph traversal with a twist, or a tree problem that requires tracking multiple values per node.
Meta likes variants of well-known patterns. The structure is familiar but the specific requirement is just different enough that a memorized solution won't quite fit. They're checking whether you understand the pattern or just know the answer by heart.
If you see "merge intervals" and immediately start typing the standard solution without reading the constraints, you're going to have a very confusing 17 minutes.
What Topics Show Up?
Four patterns drive most of the round: sliding window or two pointers on arrays/strings, hash-map counting or grouping, tree DFS or BFS with multi-value state per node, and interval merge or grid traversal. Linked-list reversal, monotonic stacks, and binary-search-on-the-answer appear, but less often.
What makes Meta variants distinct is the layer of constraint they bolt onto the base pattern. A sliding window where the window can shrink based on a second condition. A tree DFS where you return two values per recursion and combine them at the parent. A merge intervals where intervals carry metadata that has to survive the merge. The base solution is never the final solution.
System design does not appear at the phone screen stage. Behavioral questions are minimal. This round is pure DSA.
The Meta-tagged LeetCode list, filtered to the last 30-90 days, is a widely shared proxy for what appears, though it isn't an official source. The specific questions rotate; the topic mix stays consistent.
How the Interviewer Scores You
Meta uses four scored competencies across coding rounds: Problem Solving, Coding, Communication, and Verification.
Problem-solving: Did you understand the problem? Did you arrive at an optimal or near-optimal approach? Brute force that converges toward optimal with a clear explanation beats a fast-coded optimal solution with no commentary.
Coding: Is the code clean and correct? Can you handle edge cases? The no-execution constraint makes this harder. Interviewers watch for off-by-one errors, missed null checks, and logic bugs you'd normally catch at runtime.
Communication: Did you talk through your approach before coding? Did you ask clarifying questions? Did you narrate during the implementation? Silence is a red flag at Meta. The quiet focus you've trained into yourself through hundreds of LeetCode sessions is actively working against you here.
Verification: Did you dry-run your code on an example? Did you name edge cases explicitly? This is a scored dimension at Meta, and most candidates skip it entirely. Not because they're careless. Because LeetCode trained them to just hit Submit and see what breaks.
Here's the part most write-ups miss. After the interview, the interviewer writes a binary Hire / No Hire and then a confidence score in the comments. Meta is the only FAANG that does this. The practical effect: a low-confidence "No Hire" on the phone screen leaves room for the recruiter to push for an onsite anyway if the rest of the packet is strong. A high-confidence "No Hire" closes the door immediately. This is why coachable behavior on a hint matters more than your raw score on any one problem. A clean pivot after a hint moves the confidence rating, even when the final solution lands the same place.
What Interviewers Are Trained to Do
Meta is the only FAANG where you can't become an interviewer unless you give good hints. Hint-giving is part of the certification, not a courtesy. This matters in practice.
If your interviewer offers a hint, take it and run. A designed part of the process is exactly what it is. An interviewer who gives a clear hint and watches you pivot quickly sees coachability and adaptability. An interviewer who gives a hint and watches you defend the wrong approach is writing something else entirely under Communication.
Don't ignore hints. Don't argue with them. Say "that's helpful, let me think about that" and actually use the information.
The Five Things That Get Candidates Rejected
1. Running out of time on problem two. The most common failure mode. Spending 30 minutes on problem one leaves five minutes for problem two. A partial solution for both beats a complete solution for one.
2. Coding in silence. You can solve the problem correctly and still get a no-hire. The interviewer submits a written debrief. If you said nothing for 35 minutes, there is nothing to quote under "communication." The hiring committee reads what the interviewer wrote, not the code you typed. Give them material. What narration actually sounds like, mid-solve:
"Okay, I want to find the longest substring with at most k distinct characters. Sliding window feels right. I'll track a left pointer, a right pointer, and a hash map of character counts. When the map size exceeds k, I shrink from the left until it's back under. I'll track the max window size as I go. Let me code that, then trace through 'eceba' with k = 2 to check."
That paragraph is two sentences of approach, one of data structures, one of invariant, one of plan. It gives the interviewer five separate things to quote.
3. Not asking clarifying questions. "Can the array be empty? Can values be negative? Do I need to handle duplicates?" Thirty seconds of questions prevents a wrong assumption that derails your entire approach.
4. Skipping complexity analysis. Meta expects you to state your time and space complexity once you have a working solution. If you don't bring it up, your interviewer will. Have the answer ready before they need to prompt you.
5. Declaring done without tracing through an example. "I think that's right" is not a trace. Walk through your code with an actual input, step by step, variable by variable, before you say you're finished. This is how you catch the bug you'd normally catch with a print statement. It also shows the interviewer you care about correctness, not just being done first in an interview with no one else in it.
How Should You Prepare?
The phone screen is a focused target. You don't need to master every advanced algorithm. You need to be fluent at medium-difficulty DSA problems across the topics above, without an IDE, while talking.
Weeks one and two. Build the foundation. Work through the core patterns: sliding window, two pointers, DFS/BFS on trees and graphs, hash map problems, interval merge and insert. Understand why each pattern works, not just what the code looks like.
Weeks three and four. Work the Meta-tagged LeetCode problems from the last 30-90 days. Prioritize problems that appear more than once. For problems you get stuck on, figure out the structural signal that would have pointed you toward the right approach earlier.
Week five or six. Switch to timed practice without your IDE. Open CoderPad's sandbox, set a 17-minute timer per problem, and write code you cannot run. Then read every line, trace through a small example, and find your own bugs. This is the actual skill. Not solving problems. Solving problems while blind.
Throughout. Practice narrating out loud while you solve. It feels deeply awkward. Your dog will stare at you. Do it anyway. You cannot train spoken communication through silent grinding, and silent grinding is exactly what most candidates spend their prep time doing.
If you want to practice that verbal component under real pressure, SpaceComplexity runs voice-based mock interviews with DSA problems and rubric-based feedback on your communication, not just whether your solution is correct.
How Long Will Prep Actually Take?
Most candidates need four to six weeks of focused preparation to be phone-screen-ready for Meta. If you're coming from a recent job with daily coding, four weeks may be enough. If your DSA is rusty, six weeks is safer.
Meta does not publish a phone screen pass rate. The widely shared benchmark from interviewing.io's anonymized data puts the average technical phone screen pass rate around 40% across companies. That 40% is among people who already cleared a recruiter screen, so the effective difficulty is higher than the number suggests. Treat it as an order of magnitude, not a forecast.
Meta schedules onsites for candidates who pass. The onsite is four rounds, typically two DSA, one behavioral, and one system design for E4+ or one additional DSA at E3. Passing the phone screen is a meaningful milestone, not the finish line.
What to Read Next
For the full Meta onsite loop, the Meta Software Engineer Interview guide covers all five rounds and how the hiring committee reads your packet. For the communication skills this round tests, Coding Interview Communication and Clarifying Questions in Coding Interviews are worth reading before you practice.
The scoring model isn't unique to Meta. Hidden Coding Interview Rubric explains the five signals every interviewer is watching, wherever the interview is.