Meta Phone Screen: What It Tests and How to Pass It

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 distinct 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. It's the recruiter confirming that what's on your resume matches reality and figuring out whether you're targeting E4, E5, or higher. 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 roughly three to four weeks later, onsite another four to five weeks after that.

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 problem is a weak signal. Two clean-enough solutions, with complexity analysis and working logic, is what interviewers are looking for.

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.

Read that again. You write code. Nobody runs it. You find bugs by staring at the screen and thinking, which is roughly the opposite of how you've spent your entire career. 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." If your debugging workflow is "run it and see," you are not ready for this interview.

The Difficulty Level

Both problems are LeetCode medium, sometimes leaning medium-hard. You won't get a classic two-sum. 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.

The Topic Coverage

Meta's phone screens draw heavily from these categories:

Arrays and strings: sliding window, two pointers, prefix sums
Hash maps: frequency tables, grouping, O(1) lookup tradeoffs
Trees: DFS/BFS traversal, diameter, path problems, BST properties
Graphs: connected components, islands, BFS on grids
Linked lists: reversal, cycle detection, merge
Intervals: merge, insert, count overlaps
Stacks: parentheses, monotonic patterns
Binary search: both classic and binary-search-on-the-answer variants

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 reasonable proxy for what appears. The specific questions rotate, but the topic mix stays consistent.

How the Interviewer Scores You

Meta's rubric has four dimensions.

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.

Testing and 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.

After the interview, the interviewer submits a hire/no-hire decision plus a confidence rating. Meta is unusual in capturing confidence explicitly: a low-confidence "hire" carries less weight than a high-confidence one. A failed round with low confidence also lands differently than a hard no-hire. The scoring is more nuanced than a simple pass/fail.

What Interviewers Are Trained to Do

Meta is the only major tech company that requires interviewers to give hints before they can become certified. This matters in practice.

If your interviewer offers a hint, take it and run. This isn't a crutch. It's a designed part of the process. 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.

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.

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 to Prepare for the Meta Phone Screen

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.

A Realistic Timeline

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.

The pass rate at the phone screen stage is roughly 50%, and that's a filtered population. These are candidates who already cleared the recruiter screen. Half of those people don't make it through. The effective difficulty is higher than the number implies.

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.

Key Takeaways

The technical phone screen is 45 minutes: 5 intro, 35 coding, 5 questions
Two medium-difficulty problems, no code execution
Budget 17 minutes per problem, not 35 for one
Four scored dimensions: problem-solving, coding, communication, testing
Meta interviewers are trained to give hints. Use them.
Practice writing and reading code without a compiler
Talk throughout the entire interview
Trace through an example before saying you're done

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.