SpaceComplexity

New Grad FAANG Interview Prep: The 12-Week Roadmap

June 1, 20269 min read
interview-prepcareerdsaalgorithms
New Grad FAANG Interview Prep: The 12-Week Roadmap
TL;DR
  • Fall recruiting has hard deadlines: Google opens in October, most slots are gone by December — prep must start by July or you miss your shot.
  • Phase 1 (weeks 1-4) builds primitives: arrays, strings, hash tables, trees, graphs, and binary search. Skip DP until the foundation is solid.
  • Phase 2 (weeks 5-8) maps patterns to signals: two pointers, sliding window, BFS/DFS, binary search on the answer, heaps, and DP fundamentals.
  • Phase 3 (weeks 9-12) is simulation: mock interviews with real interviewers, 6+ STAR stories, timed practice sets, and light system design.
  • Readiness is a checklist, not a feeling: easy problems under 10 minutes, mediums under 25, 3+ mocks with written feedback, 4/5 on unseen mediums.
  • Communication is the real gap: most new grads fail on narration and testing, not the algorithm — train all four rubric dimensions explicitly.

You've decided you want Google, Meta, Amazon, or one of the other big ones right out of school. Great news: the internet will now offer you a 300-problem LeetCode list, a YouTube rabbit hole on system design, and seventeen conflicting opinions about which data structure to study first.

None of that tells you how to structure four months, what to actually do in each phase, or how to know when you're ready to apply. This does.

The Calendar Is a Constraint, Not a Suggestion

New grad recruiting runs on a real schedule. Big tech opens applications in August through October. Google's window opens around mid-October and closes within two to four weeks. Meta and Amazon open slightly earlier, in September. By December, most slots are gone.

If you're graduating in May or June, you need to be applying in October, which means prep starts no later than July. Work backward from that date, not forward from "whenever I feel ready."

There's also a failure mode the prep guides skip. Every major company has a cooldown period after rejection. Google's is up to a year after an onsite. Apply in October before you're ready, bomb the onsite, and you're locked out until the following fall cycle. That's a year of your life to get back one shot. Don't apply because you're anxious. Apply when the milestones below are actually met.

Phase 1: Foundations (Weeks 1 to 4)

The mistake most new grads make is starting on the wrong material. Graph algorithms before they can implement a hash map cleanly. Dynamic programming before they understand recursion. The instinct is to jump to the hard stuff because the hard stuff feels like progress. It isn't.

Your only job in weeks one and two is arrays, strings, and hash tables. These three structures show up in over half of all coding rounds at every company. Learn their operations cold. Solve a dozen easy problems for each, not to discover new ideas, but to confirm you can implement each structure from scratch in under ten minutes.

Week three: trees and graphs. Implement DFS and BFS from understanding, not from memory. A binary tree traversal should feel as natural as a for loop. Understand why iterative BFS with a queue maps directly to BFS on a graph.

Week four: binary search, sorting, and a first look at heaps. Binary search is the most underestimated topic in prep. It shows up not just in search problems but as the backbone of "binary search on the answer" patterns. Get the invariant right before you move on.

Skip dynamic programming in phase one. DP before the other patterns are solid is just recursion with extra suffering.

Phase 2: Pattern Depth (Weeks 5 to 8)

You have the primitives. This phase is about mapping patterns to problem signals. You're not trying to see as many problems as possible. You're trying to see each pattern enough times that you recognize it in a novel problem within sixty seconds.

The patterns worth your time, in order of frequency:

Two pointers and sliding window. These account for a huge chunk of array and string problems. Two pointers is a converging scan from both ends. Sliding window is expanding and contracting a range with a clear invariant. They look different but share the same instinct: don't scan O(n²), hold state as you move forward.

BFS/DFS on trees and graphs. Almost everything recursive in an interview is one of these. BFS for shortest path on unweighted graphs. DFS for connectivity, cycle detection, and subtree properties. Practice until the implementation is automatic.

Binary search variants. After the classic, learn binary search on the answer. "Minimize the maximum" and "maximize the minimum" problems both have the same shape: a monotone feasibility function you binary search over a range. This shows up at Amazon, Google, and Meta constantly.

Heap and top-K patterns. A heap lets you maintain a running extreme without sorting the whole thing. The signal: "you need the k-th largest/smallest thing" or "you need to merge k sorted streams."

Dynamic programming. Start late, go deep. The two families that show up in new grad rounds are 1D linear DP (coin change, LIS) and 2D grid/sequence DP (unique paths, LCS). Learn to identify overlapping subproblems, define state, and write the recurrence before you touch code.

Backtracking, interval merging, and union-find round out the list. Don't skip them, but don't over-index either.

By the end of week eight, your benchmark: given a random medium from any of these patterns, identify the approach within two minutes and produce a correct solution in under twenty-five.

A four-panel American Chopper meme: "I have strong projects" / "We need DSA" / "I have solved 1000 LeetCode" / "We need experience" / "I have done internships" / "We need open source" / "I have open source and everything you asked for" / "We are moving forward with other candidates"

The full FAANG hiring cycle, summarized. The roadmap in this post exists specifically to break out of that last panel.

Phase 3: Integration and Simulation (Weeks 9 to 12)

This is where most candidates are underprepared. They spend twelve weeks grinding LeetCode solo, then discover that coding in silence is a completely different skill from coding while explaining yourself to another person. Those are not the same muscle.

The interviewing.io data on this is striking. Candidates who had completed five or more real technical interviews passed at dramatically higher rates: 65 percent to 81 percent at Amazon, 40 percent to 71 percent at Meta. That gap isn't explained by problem-solving ability. It's explained by communication under pressure.

In weeks nine through twelve, book three to five mock interviews with real interviewers, not peer swaps where your friend is also nervous. Platforms like interviewing.io connect you with engineers at the companies you're targeting. The goal isn't to perform well. It's to get written feedback you can act on before the real thing.

Run the mocks in full simulation: no IDE, timed at 45 minutes, talking through your approach before writing a single line. Practice saying "I'm going to start with a brute force O(n²) scan and then improve it" before you have any idea how to improve it. That sentence buys you time, signals structured thinking, and shows you know what good problem-solving looks like.

For behavioral prep, you need six to eight reusable STAR stories. A hard technical decision, a conflict you navigated, something you built end-to-end, a time you learned something difficult fast. If you're targeting Amazon specifically, prepare more. Amazon asks two to four LP-linked questions per round, and you can run out of examples faster than you'd expect.

One thing new grads consistently skip: light system design. At most companies, new grads don't get a system design round at all. At Google and Meta, where they occasionally do, the bar isn't "design YouTube." It's structured thinking. Ask clarifying questions. Sketch a reasonable architecture. Justify your database choice. State the trade-offs. Spend two hours reading about caching, load balancing, and database trade-offs, then talk through a simple design out loud. That's the entire ask.

How to Know You're Ready

"Ready" isn't a feeling. It's a checklist.

Technical readiness: Easy problems in under ten minutes. Mediums from known patterns in under twenty-five. Correctly identify the pattern on new mediums within two minutes, at least seventy percent of the time.

Communication readiness: At least three mocks with real interviewers, written feedback on at least one. You can narrate your reasoning while coding without losing your place in the solution.

Behavioral readiness: Six or more STAR stories rehearsed, each in two to three minutes without rambling. For Amazon, mapped to the leadership principles.

Process readiness: Your first-five-minutes routine is automatic: clarify constraints, state a brute force, announce your optimization before implementing, walk through an example before coding. Boring is the goal.

One concrete test: take five unseen mediums from company-tagged lists, 30-minute timer each. Four out of five means you're ready. Two or three means more deliberate pattern practice, not more total problems.

The Bottleneck Is Not What You Think

Almost every new grad who fails a FAANG interview failed on communication, not the algorithm. They knew the pattern but couldn't explain why they chose it. They solved the problem but declared done without testing. They got stuck and went silent instead of narrating their dead end.

A four-panel meme: a cartoon character happily celebrates "Goodbye, compiler errors! I will never suffer again!" then immediately gets beaten by figures labeled "LINKER ERRORS" and "RUNTIME ERRORS"

Every candidate who cracked the algorithm, said "I'm done," and forgot to test for edge cases.

The rubric has four dimensions: algorithms, coding, communication, and problem-solving. Interviewers weight them differently than you expect. A 4-4-2 scorecard (strong technical, weak communication) advances far more often than a 3-3-4 (weak technical, strong communication). But the 4-4-4 candidate who narrated their reasoning, tested their code, and asked smart clarifying questions is the one who gets "strong hire." That's what you're training for.

The goal isn't to memorize more solutions. It's to build the interview-specific behaviors (narration, testing, clarification, structured approach) until they're automatic under pressure.

SpaceComplexity does this specifically. It's a voice-based mock interview platform that scores you on all four rubric dimensions, not just whether you got the right answer. If you've been grinding LeetCode in silence, a few sessions with live feedback will show you exactly what phase three practice is supposed to feel like.

The Short Version

  • Start prep in July or early August if you're targeting fall applications.
  • Weeks 1 to 4: Arrays, strings, hash tables, trees, graphs, binary search. Implement from scratch. No DP yet.
  • Weeks 5 to 8: Two pointers, sliding window, BFS/DFS variants, binary search on the answer, heaps, DP fundamentals, backtracking.
  • Weeks 9 to 12: Mock interviews with real interviewers, behavioral stories, light system design, timed practice sets.
  • Readiness check: Easy < 10 min, medium < 25 min, 3+ mocks done, 6+ stories ready.
  • Don't apply before you're ready. The cooldown is a year at Google after an onsite. Use your shot.
  • The algorithm is 60% of the game. Communication, testing, and structured process are the other 40%. Train them explicitly, not as an afterthought.

Further Reading