Most "Google interview prep" advice is just generic LeetCode advice with a logo on top. That's a mistake. Google's loop has a recognisable shape, and it is not the same shape as Amazon's. The companies sample overlapping data structures, but they reward different things — and at Google, the thing they reward most is something a silent grinder never practises: thinking out loud while you model a fuzzy problem cleanly. If your entire prep is "solve more problems," you are training the wrong muscle for this specific company.

At Google, a working brute force you explained clearly often outscores a silent optimal solution. They are interviewing the engineer they'd have to sit next to for two years, not a solver.

This is the deep, Google-specific version of our broader Google, Amazon & Microsoft question breakdown. If you only have time for one company, here's what to actually drill.

What Google actually leans on

Google rotates its real questions aggressively, so chasing "leaked Google questions" is a waste. What's stable is the pattern distribution and the scoring philosophy. The technical lean is less about exotic data structures and more about whether you can take an underspecified, real-world-flavoured prompt and turn it into a clean model.

• Intervals — merge intervals, insert interval, meeting rooms, "can a person attend all meetings," interval scheduling. Google loves these because they force you to sort, reason about ordering, and handle overlap edge cases cleanly.
• Greedy — activity selection, jump game, gas station, task scheduling. Greedy questions test whether you can justify why the local choice is globally optimal, which is exactly the "reason out loud" signal they grade.
• Binary search — including "search on the answer." Not just "find the element in a sorted array," but the harder variant: binary-searching over a range of possible answers (min/max feasible value). Think "minimum capacity to ship packages in D days," "split array largest sum." This pattern shows up at Google more than people expect.
• Arrays and strings with a twist — prefix sums, sliding window, two pointers, in-place transforms. Rarely vanilla; usually one modelling decision away from being clean.
• Graphs and BFS/DFS — present, but Google leans less on heavy graph trivia (no one's asking you to recite max-flow) and more on whether you correctly recognise that a problem is a graph.

What you'll see less of: niche data-structure trivia, segment trees, and "do you have this one obscure algorithm memorised" puzzles. Google has been deliberately moving away from gotcha riddles for years. Depth of reasoning beats breadth of memorised structures here.

The part everyone underrates: communication is scored

This is the single biggest reason strong solvers fail Google loops. At many companies the interviewer mostly watches whether the code works. At Google, your interviewer is filling out a rubric with an explicit communication axis, and a clean structured walkthrough genuinely moves your score, not just the interviewer's mood.

Concretely, the candidates who pass do this:

• Clarify before coding. Restate the problem, ask about input size, duplicates, empty input, negative numbers, and what "valid" means. This isn't stalling — it's the modelling step they're grading.
• State the brute force first, out loud. "The naive approach is O(n²) because I'd check every pair. Let me see if I can do better." Now the interviewer knows you see the whole space.
• Narrate the optimisation. "If I sort first, the overlap check becomes linear." Say why the better approach works before you type it.
• Talk through edge cases unprompted. Empty array, single element, all-duplicates, integer overflow.
• Dry-run your own code. Walk a small input through the finished solution out loud. Catching your own bug scores higher than the interviewer catching it.

A blunt way to internalise it: if the interviewer can't follow your thinking, the correct code barely counts. The job is collaborative; the interview simulates that.

Googleyness — what it actually means

"Googleyness" gets thrown around like a vibe, and candidates either dismiss it or panic about it. Based on Google's own public hiring write-ups, it's a real, somewhat concrete bucket — roughly: comfort with ambiguity, intellectual humility, collaboration, and bias toward the user. I can't give you an exact internal definition (it has been reworded over the years and you should treat any single phrasing as directional, not gospel), but the behaviours that read as "Googley" in a coding loop are consistent:

• Comfort with ambiguity. When the prompt is vague, you ask good questions and propose a reasonable interpretation instead of freezing or assuming. Google deliberately under-specifies problems to watch this.
• Intellectual humility. When the interviewer hints your approach is flawed, you engage with it instead of defending a sinking solution. "Good point — that breaks on duplicates, let me rethink" is a green flag.
• Collaboration over performance. You treat the interviewer as a teammate, not a judge. You think with them.
• User/impact orientation. In behavioural rounds, framing decisions around the person affected lands better than pure technical heroics.

You don't fake this with a script. You build it by practising out loud so that clarifying, conceding a flaw, and adapting are reflexes, not panic responses.

The follow-up that changes the constraints

This is Google's signature move, and it catches template-memorisers every time. You solve the problem, it works — and then the interviewer changes one constraint:

• "Now the input doesn't fit in memory. What changes?"
• "What if the array is streaming and you can't store it all?"
• "Now there are millions of queries on the same data. Optimise for repeated lookups."
• "What if it has to run across many machines?"
• "Make it work if the values can be negative / duplicated / unsorted."

The point is to test whether you actually understand your solution or just pattern-matched a memorised template. The candidates who do well treat the follow-up as the real interview — they say "okay, that breaks my hash-map approach because memory is gone, so I'd sort externally or use a heap of size k," and they reason from first principles. Drilling 500 problems shallowly leaves you defenceless here. Drilling 150 problems deeply enough to mutate them is what passes.

How to practise for follow-ups

After you solve any problem cleanly, ask yourself the Google questions before moving on: What if the input were 1000× bigger? Streaming? Negative? Queried a million times? If you can't answer in a sentence, you don't own that solution yet. That self-interrogation is worth more than the next ten fresh problems.

How Google differs from Amazon — concretely

If you've been prepping the generic "FAANG" way, you've probably been prepping for Amazon by accident, because most online question dumps are Amazon-flavoured. Here's the honest side-by-side.

Dimension	Google	Amazon
Technical lean	Intervals, greedy, binary search (incl. search-on-answer), clean modelling	Grids, graphs, trees, grid-DP — very pattern-predictable
What's scored hardest	Communication + reasoning, almost as much as correctness	Working solution + Leadership Principles (behavioural)
Problem style	Under-specified on purpose; you must model it	Often dressed as warehouse/delivery stories, but well-specified
Signature curveball	Follow-ups that change the constraints mid-problem	OA debug / code-completion section
Behavioural weight	"Googleyness" — ambiguity, humility, collaboration	Leadership Principles, STAR stories, heavily weighted even at SDE-1
What to skip	Exotic structures, segment trees, riddles	Advanced math; not the focus

The practical upshot: an Amazon-bound fresher should grind grid/graph flooding and rehearse Leadership Principle stories. A Google-bound fresher should grind intervals and binary-search-on-answer, and spend equal time practising the narration. Same sheet, very different emphasis. Prepping for one as if it were the other is a quiet way to lose.

A Google-specific drill plan

Assuming you already have the universal foundation (arrays, strings, hash maps, recursion — if not, start with the 21 most important DSA topics first), here's where to concentrate for Google specifically:

1. Intervals to autopilot. Merge, insert, non-overlapping, meeting rooms I and II. You should recognise an interval problem in under 30 seconds and know "sort by start, then sweep" is your default.
2. Binary search beyond the basics. Do the standard ones, then deliberately drill "search on the answer": ship-within-D-days, split-array-largest-sum, koko-eating-bananas. This pattern is high-signal and under-practised.
3. Greedy with justification. For every greedy problem, force yourself to say one sentence on why the greedy choice is safe. If you can't justify it, you don't understand it — and Google will probe exactly there.
4. Two pointers and sliding window. The workhorses for the array/string-with-a-twist bucket.
5. Mock out loud, weekly. Solve at least one problem a week narrating to a webcam, a friend, or even an empty room. The discomfort is the training. Then hit yourself with one constraint-change follow-up and answer it.

Notice depth over volume. A Google candidate who has 120 problems they can mutate, narrate, and defend beats one who silently grinded 400. While you're at it, audit yourself against the common coding interview mistakes — jumping to code, ignoring edge cases, and going silent are all disqualifiers Google weights heavily. And the patterns cheat sheet is the fastest way to drill the intervals, two-pointer, and binary-search shapes that dominate this loop.

The India-specific reality check

If you're going for Google through campus or off-campus in India, a few honest notes. The bar is genuinely high and the rounds are real DSA, not aptitude — this is the opposite end of the spectrum from a TCS NQT. But "high bar" doesn't mean "memorise 800 problems." It means the patterns above, deep enough to survive follow-ups, plus the communication discipline that most Indian college prep skips entirely because it's done silently in a notebook. The candidates who break through are usually not the ones who solved the most — they're the ones who practised talking while solving. That's a free edge most people leave on the table.

Drill the Google lean, not the generic 370

The whole problem with generic prep is that the intervals, greedy, and binary-search-on-answer questions Google over-weights are scattered across a sheet, buried between problems that barely matter for this loop. That's exactly what SUITS fixes: it reorders the curated 370 problems around the role and company lean you're targeting, so your Google-relevant patterns float to the top instead of sitting at step 14 — and tracks your weak spots so you know which solutions you can't yet mutate. Set your target, then go practise them out loud.