The Meta Coding Interview: Format, Pads, and Practice
By Aaron Cao · Updated
A Meta coding round is roughly forty-five minutes in a plain shared coding pad, frequently with two problems. The editor typically has no execution or autocomplete, cameras stay on, and interviewers grade correctness, speed, code quality, and how clearly you narrate your reasoning while writing.
What exactly happens in the 45 minutes?
The rhythm is consistent across Meta's phone screen and loop coding rounds: brief introductions, a problem statement pasted into a shared pad, and the clock effectively starts. You clarify constraints, talk through an approach, write code while narrating, and dry-run it against cases by hand. With two problems in a session, a strong candidate lands the first inside twenty minutes to leave the second real room.
The pads are deliberately plain: frequently no execution, no autocomplete, minimal highlighting. That is not stinginess; the graded object is your reasoning, and a run button would blur whose reasoning produced the fix. Expect to be your own interpreter, stepping through indices and edge cases out loud.
Where these rounds sit inside Meta's full pipeline is laid out on the company interview processes hub.
What are interviewers actually listening for?
The fear here is usually silence: what happens in the interviewer's notes while you think. The honest answer is that the notes track signals, and silence starves them. Correctness and speed are the visible half. The other half is communication: whether you scoped the problem before coding, stated the trade-off that picked your approach, and tested your own code without prompting.
That is why narrated practice beats silent grinding. A candidate who solves slightly fewer problems but thinks audibly, names complexity, and self-corrects produces a fuller signal profile than a silent solver. Meta's own preparation guidance says as much; the format is built to reward visible reasoning.
The mock interview tool runs timed, two-problem, narrate-as-you-go sessions, which is the closest rehearsal to the real pad.
How should you prepare in the last two weeks?
Late-stage preparation is about format fidelity, not new theory. Solve in a plain editor with syntax highlighting off or minimal, speak every solution aloud even alone, and cap sessions at forty-five minutes with two problems to make the density normal. Rebuild the habit of hand-tracing code, because the pad will not run it for you.
An infrastructure engineer with a loop ten days out is a typical case. She spent evenings on timed pairs, recorded herself to catch silent stretches, and used her final weekend on one full loop simulation. In the real rounds the pad, the pacing, and the narration were all familiar, so her attention went to the problems; the transcript on her own machine simply kept the interviewer's constraints pinned while she worked.
Honest boundaries still apply: a live pad is a shared surface, recorded or monitored rounds are out of scope for any assist tool, and dense timing means fluency is the only thing that truly scales. The boundaries are collected on the detectability topic.