I've been lurking for a long time, and this time I picked up a lot of good material from the forum before my own interview, so I'm posting this to give back. I'm using the forum's usual numeric code-names for the problems, so bear with me.
Google's pacing is very different from Meta's. Each round is 45 minutes with basically one main question, and the rest of the time is all follow-ups — the interviewer won't let you just finish writing and be done with it, they will keep pushing with "what if the input becomes X" and "can you lower the complexity further." Code is written in a Google Doc, with no syntax highlighting and no way to run it, so mentally walking through your own test cases becomes even more important. Also, the interviewer types notes the entire time, which felt a little uncomfortable at first, but you get used to it.
Round 1: Coding
The interviewer's English was easy to follow.
The problem was in the "1891" family, going by the number people use for it on the forum: given several pieces of wood of different lengths, cut out at least K pieces of equal length, and find the maximum possible length for those pieces.
I spent the first couple of minutes thinking along greedy/sorting lines and realized that was wrong. The interviewer didn't interrupt — only after I said out loud, "I don't think this direction is working," did they offer a hint: "what if I gave you a candidate length." That's when it clicked — directly finding the max length is hard, but given a length L, checking whether you can cut out K pieces is trivial: it's just sum(w // L for w in woods) >= K, one pass. So you binary search over [1, max(woods)], going higher when it's feasible and lower when it isn't.
After I finished, the interviewer asked three follow-ups:
- Why is the binary search's upper bound max(woods) instead of sum(woods)? Because each cut piece has to come from a single piece of wood — you can't join pieces together.
- What if the length is allowed to be a float? Switch to binary searching over reals, and cap either the iteration count or the precision threshold.
- What's the complexity? O(n log(max)). He pushed further on why it isn't O(n log n), wanting me to clearly explain that the log term is over the value range, not over the number of elements.
There was a post on the forum a while back about this kind of problem — "the answer is hard to find directly but easy to verify" — which at its core is rewriting max_x f(x) as min_t t, s.t. t >= f(x). It wasn't until after the interview that I realized the classic problem about walking from the top-left to the bottom-right of a matrix while minimizing the maximum value along the path is the exact same pattern. Worth bundling the two together when you practice.
Round 2: Coding
The interviewer didn't talk much, took notes the entire time, and gave very little feedback — partway through I actually thought I'd blown it.
The main question was a variant of the classic interval-list-intersection problem: given two interval lists, each already sorted with no internal overlaps, find their union instead (the original problem asks for the intersection — this one flips it).
The approach is two pointers: each time, take whichever interval has the smaller start and try to merge it into the result. While writing it I merged the "result is empty" case and the "new interval doesn't overlap with the last one in the result" case into a single branch, then explained afterward why that merge is valid.
The follow-ups kept escalating:
- What if there are K lists instead of two? I said switch to a heap — push each list's current interval keyed by start, pop the minimum each time, complexity O(N log K).
- What if the lists are too large to fit in memory and you can only read a chunk at a time? That turns into an external-sort / streaming-merge approach — the heap only ever holds one element per list, and you read in a new element right after consuming the last one.
- Last, he asked: what if intervals within a single list are allowed to overlap? Then it degrades into the standard approach — sort by start and sweep-merge, i.e. the regular merge-intervals problem.
This round felt closest to Google's style to me — the problem itself isn't hard, but they keep layering on constraints to see whether you can keep up.
Round 3: Coding
The interviewer was very warm, and proactively said, "no rush, walk through your approach first."
The first question was the nested-list weighted-sum problem (referred to by the number 339 on the forum): given a nested list, compute a weighted sum where deeper nesting carries a larger weight. I gave two approaches, DFS and BFS — DFS passes the depth down through the recursion; BFS traverses level by level, with one weight per level. The interviewer had me write pseudocode for both, then asked when one is better than the other. I said if the nesting gets very deep, BFS is safer since it won't blow the stack.
The follow-up switched to a string input instead of an already-parsed nested structure:
Input: "[3, 8, [2, 14], [2, [91]]]"
Output: 3*1 + 8*1 + 2*2 + 14*2 + 2*2 + 91*3 = 320
Now I had to parse it myself. I used a depth variable: increment on "[", decrement on "]", and whenever I hit a digit, add num * depth to the running total, being careful to accumulate multi-digit numbers correctly. While writing it I got stuck for a moment on "when exactly do I finalize a number" — in the end I settled on finalizing it whenever I hit a comma, a closing bracket, or the end of the string.
The interviewer had me manually trace through the case [2, [91]], and partway through I noticed on my own that I'd missed finalizing the last number at the end of the string, and fixed it on the spot. Catching your own bug feels a lot better than having it pointed out to you.
Round 4: System Design
The prompt was to design a web crawler.
I laid it out in this order:
Clarify — what scale (how many domains, how many pages, how long should one full pass take), whether incremental crawling is needed, who consumes the crawled data (a search index? offline analysis?), and whether JS rendering matters. The interviewer said: assume billions-of-pages scale, periodic re-crawling is needed, the downstream consumer is a search index, and don't worry about JS rendering for now.
High-level architecture — URL frontier → fetcher → parser → dedup → storage, with new URLs the parser extracts feeding back into the frontier, forming a closed loop.
A few points he dug into:
- How to balance politeness and priority. The frontier can't just be a plain queue — I described a two-tier design: a front layer split by priority, a back layer split by host, so requests to the same host stay serialized and spaced out, while high-priority URLs still get scheduled faster. Here the interviewer pushed on how long to cache robots.txt for.
- Dedup. URL-level dedup uses hash + bloom filter; content-level dedup has to account for the same page being reachable through multiple URLs, so I proposed checksums and SimHash for approximate matching. The interviewer asked what happens when the bloom filter gives a false positive — you end up missing a crawl, so you need to control the false-positive rate, or fall back to exact matching for important domains.
- How to avoid traps. Infinite calendar pages, dynamically generated URLs, crawler black holes — I said cap the crawl depth and total volume per domain, plus detect suspicious URL patterns.
- Distribution and fault tolerance. Shard by host with consistent hashing across crawler nodes, so the politeness constraint for a given host naturally lives on one node; if a node dies, recover from checkpoints, and the frontier's state needs to be persisted.
With a few minutes left, the interviewer asked, "if I need the whole site re-crawled within 24 hours, where's your bottleneck?" I said probably bandwidth and DNS resolution, so you'd want to build your own DNS cache.
This round was a genuinely enjoyable conversation. My take is that Google's system design rounds care a lot about whether you can push the discussion deeper yourself, rather than waiting for the interviewer to ask.
Round 5: Googleyness & Leadership
This one was with a manager. The questions were softer than I expected, but each one got dug into further.
- Tell me about the project you're most proud of, specifically what you did
- Tell me about a failure, and what you changed afterward
- Was there a project where you had to push forward despite requirements and information both being very vague
- What's the harshest feedback you've ever received, and how did you react at the time
- An experience working with a difficult colleague
- If you could do it again, what would you do differently
I'd prepped six or seven stories, each written out as a half-page STAR outline. My sense is that the key to this round isn't how dramatic the stories are — it's that the results need numbers and the decisions need reasons. When I told the failure story, I covered both "why I thought this approach would work at the time" and "what signals I realized in retrospect I'd missed," and the manager visibly took extra notes right there.
While practicing I noticed a bad habit of my own: I'd rush through the Result part because I was too focused on narrating the process. I'd suggest recording yourself and playing it back — the problem becomes obvious the moment you hear it.
Some closing thoughts
Follow-ups really do decide the outcome at Google. The main questions are mostly ones you'll already have seen on the forum, but just finishing the main question probably isn't enough on its own. My gut feel is that "finishing the main question" is the passing bar, and being able to hold up under two or three layers of follow-ups is what actually gets you the hire. So when you're grinding problems, don't just flip to the solution the moment you finish — ask yourself one more question: "what if the input gets bigger / becomes a stream / doesn't fit in memory?"
Really internalize the binary-search-on-the-answer pattern. I ran into it once across my five rounds, and it keeps showing up in forum posts too. It's easy to spot: you're looking for the max or min of some quantity, it's hard to find directly, but easy to verify given a candidate value.
Get used to writing code in a Doc ahead of time. There's no auto-indent and no error highlighting — I switched to practicing in a plain text editor a week ahead of time, and it made a noticeable difference. Also use slightly longer variable names; it's easier on the interviewer when they're reading your code.
Talk while you write, and say it out loud the moment you're stuck. In round one I went down the wrong path for two minutes, and the interviewer only gave a hint after I said out loud, "this direction doesn't seem to be working." If I'd just silently struggled through it, those two minutes would have been wasted.
Don't treat Googleyness as a throwaway round. I assumed at first it was just a formality, but once I started preparing I realized you need to tell six or seven stories clearly, with numbers to back them up — it's a real amount of work.
Wishing everyone the offer they're hoping for!
Discussion
Loading comments…