Here’s a pattern I’ve noticed talking to people who’ve done Meta’s loop: the ones who fail the coding round usually failed on time, not on knowledge. They knew the algorithm. They just ran out of clock.
Meta’s coding format is two problems in 45 minutes. That’s not 45 minutes per problem. It’s 45 minutes total for both. After the initial 3-4 minutes of introductions and clarifications, you’re looking at about 19 minutes per problem. That changes how you need to practice.
What the coding round actually measures
Meta wants to see working code, fast. They’re not grading your solution on style points or how clever your variable names are. A correct brute-force solution is better than an incomplete optimized one.
The problem types that show up most often:
- Graph traversal (BFS, DFS, shortest paths)
- Dynamic programming (mostly 1D and 2D)
- Arrays and two-pointer problems
- Binary search variations
- Tree problems (less common than at Google, but still present)
The difficulty is mostly LeetCode medium. Occasionally a hard problem shows up, usually in the second slot if you blazed through the first one. I’ve heard from people who got hard problems in both slots at E5+. That’s not the norm.
One thing worth knowing: Meta uses CoderPad, not LeetCode’s own editor. The autocomplete behavior is different. Practice in CoderPad at least a few sessions before your screen.
How to actually prepare (not the standard advice)
Most coding prep advice tells you to solve 75-150 problems organized by topic. That’s fine advice. It’s also not sufficient for Meta specifically, because topic knowledge isn’t what kills you. Time kills you.
The practice method that works better for Meta: set a 20-minute timer for every problem you attempt. When it goes off, stop whether you’re done or not. Evaluate what happened. Did you get stuck on the approach? Did you know the approach but code slowly? Did you get a working solution but run out of time to optimize? Those are three different problems requiring three different fixes.
If you’re getting stuck on the approach: you need more exposure to problem patterns. The LeetCode DP patterns thread is genuinely useful here. It’s not a perfect resource but it’s real and it categorizes things in a way that makes pattern recognition faster.
If you know the approach but code slowly: that’s a muscle you build by typing. Do problems you’ve already solved, fast. Rebuild the solution from scratch in 10 minutes. Fluency comes from repetition, not from novelty.
If you get the solution but can’t optimize in time: practice talking out your complexity analysis before you optimize. “This is O(n²) because of the nested loop. I think I can bring it down to O(n) with a hashmap.” Stating the path before you walk it often makes it faster to walk.
System design: the thing that surprises people
System design at Meta is not like system design at Amazon or Google. At Amazon, the questions focus heavily on availability, durability, and distributed systems tradeoffs. At Google, there’s more emphasis on scale math and capacity planning. At Meta, the question almost always starts from a product angle.
Design a real-time notification system. Design the “people you may know” feature. Design a photo upload and storage pipeline. The problem is product-adjacent because Meta builds products and they want to know you can think like someone who ships to a billion users, not just someone who can pass a whiteboard exam.
What that means practically:
- Start with the user experience before you touch architecture. What does the user actually do? What does latency feel like to them?
- State your scale assumptions early and out loud. “I’m assuming 1 billion DAU, write-heavy workload, 100ms target for feed rendering.” Numbers give you something to design to.
- Make explicit tradeoffs. Don’t just say “I’ll use Cassandra.” Say “I’m choosing eventual consistency here because the read latency tradeoff is worth it for this use case, and strong consistency would require coordination overhead we can’t afford at this scale.”
The system design round is 45 minutes. You need to drive it. Meta interviewers are not going to pepper you with questions if you go quiet. They’ll let you drift. Some people find this freeing. Others find it disorienting. Know which you are before you’re in the room.
A concrete 3-week prep schedule
This assumes you have about 2 hours per day to prep. Adjust proportionally.
Week 1. Graph and DP problems, 20-minute clock on every session. Do 3-4 problems per day. Read the LeetCode discussions only after you’ve attempted the problem cold. By end of week 1 you want to be able to reliably start BFS/DFS from scratch in under 3 minutes.
Week 2. Mix in arrays, two-pointer, binary search. Start doing mock full rounds: 2 problems, 45 minutes, then debrief on what happened. Begin system design reading. The System Design Primer on GitHub is the standard reference and it’s legitimately good. Cover the foundational chapters (load balancing, caching, databases, consistency models) before you practice full designs.
Week 3. Full mock rounds for both coding and system design. Get a friend or colleague to play interviewer if you can. Doing system design alone is hard because the interviewer interaction is a big part of what you’re practicing. If you can’t find a human, record yourself doing it out loud and watch it back. It’s uncomfortable but useful.
The part nobody talks about
There’s a real cost to practicing wrong. If you spend 4 weeks doing LeetCode without time pressure and then sit down in a 45-minute Meta coding round, the gap between your practice environment and the real environment will hurt you. This is honestly the most common failure mode I hear about, and it’s the most preventable one.
Practice in conditions that match the test. That’s not a complicated idea. It’s just harder than practicing at your own pace, which is why most people don’t do it.
Some candidates use tools like Craqly during live mock sessions or actual interviews for real-time hints and guidance. Whether that’s useful depends on the person. But the mechanical prep, the timed sessions and the system design drills, nobody can do for you.