Google asks a different kind of question
You have ground through the Blind 75. You are comfortable with Two Sum, Number of Islands and Course Schedule. Then the Google interviewer opens with Text Justification, or Robot Room Cleaner, or Guess the Word — and none of your preparation touches it.
This is not bad luck. Google's problem set genuinely skews away from the standard list: harder, stranger, frequently LeetCode Premium, and often requiring you to reason about an environment you cannot see. Preparing for Google coding interview questions with a generic top-75 list is preparing for a different exam.
What Google actually scores
Google evaluates four attributes, and only one of them is about knowing algorithms:
- General Cognitive Ability (GCA) — how you reason through a problem you have never seen. Scored while you talk, not after you finish.
- Role-Related Knowledge (RRK) — the technical depth the role actually needs.
- Leadership — emergent leadership: do you step up, do you step back.
- Googleyness — comfort with ambiguity, intellectual humility, how you handle being wrong.
GCA is the one that surprises people. It means a candidate who reaches a working solution in silence can score below a candidate who does not quite finish but narrates a clear, correct line of reasoning the whole way. The thinking is the artefact being assessed. The code is evidence of it.
This is why Google leans on unusual problems. A problem you have memorised produces no signal about how you think. A problem you have never seen produces plenty.
The problems that actually show up
Google-tagged questions cluster into a recognisable set of pattern families. A representative spread:
- Strings and parsing — Text Justification, Sentence Screen Fitting, Find And Replace in String, Number of Matching Subsequences. Greedy line-packing and in-place text surgery are a Google favourite warm-up.
- Graphs and grids with state — Shortest Path in a Grid with Obstacles Elimination, Swim in Rising Water, Longest Increasing Path in a Matrix. Note the twist: BFS where a node is not just a cell but a cell plus remaining budget.
- Heaps, intervals and scheduling — Meeting Rooms II and III, Find Servers That Handled Most Number of Requests, My Calendar I, Range Module.
- Design, meaning implement-a-class — Random Pick with Weight, Snapshot Array, Detect Squares, Stock Price Fluctuation, RLE Iterator.
- Dynamic programming with unusual state — Maximum Number of Points with Cost, Student Attendance Record II, Race Car, Maximum AND Sum of Array.
- Interactive and backtracking — Robot Room Cleaner and Guess the Word, where you query a hidden world through an API rather than reading an input array.
Two things stand out. First, the design bucket is large: Google asks you to implement a class with a few methods and sensible performance far more often than the standard lists suggest. Second, several problems are interactive, which almost no other company does.
The mess: preparing by memorising answers
The instinct after reading a list like the one above is to grind exactly those fifty problems and memorise the solutions. It does not work, for a specific reason.
Google rotates its question bank and explicitly tries to avoid questions that leak. If you happen to get a question you memorised, you will produce a fast, confident, slightly too-smooth answer — and a good interviewer will simply ask a follow-up variation, which you cannot answer, because you learned an answer rather than a method. That gap is very visible.
Worse, memorisation gives you nothing to say during the first five minutes, which is precisely where GCA is scored.
The fix: intuition first, pattern second
Work every problem in the same four layers, and practise saying each one out loud:
- Intuition. What is your first instinct, and what is wrong with it? Where does the naive idea start to hurt? What is the reframe that makes the problem tractable? This is the part interviewers actually listen to.
- Brute force. Write it, state its complexity, and say why it times out at the given constraints.
- Optimised. Name the pattern underneath — "this is a shortest path where the state is position plus remaining eliminations, so BFS over that state space" — and apply it.
- Space optimisation. Can you drop the extra array, roll two variables instead of a table, mutate in place? If the solution is already optimal on space, say so. Naming the absence of a trick is as strong as finding one.
Then add the step most candidates skip: state time and space complexity out loud, in the interviewer's language, before they ask. "This is O(m × n × k) time because every cell can be visited once per remaining-elimination value, and O(m × n × k) space for the visited set."
The constraints in the problem statement are a hint, not decoration. If n is 10⁵, an O(n²) solution is being explicitly ruled out. If n is 20, the problem is quietly telling you that exponential is fine and you should be thinking bitmask or backtracking.
Want to master this with video lessons and real case studies? This topic is covered in depth in my Udemy course System Design Fundamentals for Interviews — 5.5 hours, rated 4.8★, built from real interview questions.
A realistic preparation plan
Assume eight weeks and an hour or two on weekdays.
- Weeks 1–2: the pattern base. Do not start on Google-specific problems. Get fluent in the common LeetCode patterns first — the Google set assumes them and then adds a twist. Starting with Race Car before you are comfortable with basic DP wastes two weeks.
- Weeks 3–5: the Google set, by family. Strings and parsing, then graphs and grids, then heaps and intervals, then design. One family at a time, so the connections form.
- Weeks 6–7: the hard tail. Dynamic programming with unusual state, the interactive problems, and geometry. These are the ones that separate offers, and they are also the ones you cannot fake.
- Week 8: narration under pressure. Solve out loud, on a timer, with no IDE autocomplete. Record yourself. The gap between "I understood it" and "I explained it clearly" is usually larger than you expect.
Throughout, keep a note of every problem where your first instinct was wrong, and what the correct reframe was. That list is worth more in week eight than the solutions are.
Googleyness and behavioural rounds
Google's behavioural questions are not a formality, and they are scored against the same four attributes. Prepare six STAR stories that between them cover: a time you were wrong and changed your mind, a conflict you resolved, an ambiguous problem you scoped yourself, a time you helped someone else succeed, a failure and what you changed after it, and something you built end to end.
Intellectual humility carries unusual weight here. Saying "my first approach was wrong because I misread the constraint, and here is what I did next" scores better than a story where you were right from the start.
How to talk about this in an interview
If you are asked how you approach an unfamiliar problem, a thirty-second answer:
"I start by clarifying the constraints, because the input size usually tells me which complexity class is acceptable. Then I work a small example by hand until I can see the structure. I state the brute force and why it fails, then name the pattern that removes the repeated work, then code it and give time and space complexity. If I get stuck, I say what I have ruled out and why, so you can see where I am."
That last sentence matters more than the rest. Getting stuck is normal; going silent is what damages the score.
Key Takeaways
- Google's problem set is harder and stranger than the standard lists, with a large design bucket and a few genuinely interactive problems.
- General Cognitive Ability is scored while you talk, so narrating your reasoning is not optional polish — it is the assessment.
- Memorising a fixed list backfires: follow-up variations expose it, and it gives you nothing to say in the first five minutes.
- Work every problem as intuition, brute force, optimised, space optimisation — and state complexity before being asked.
- Constraints are hints. n = 10⁵ rules out O(n²); n = 20 is inviting exponential.
Next Steps
The next articles go pattern by pattern, starting with the two highest-payoff ones: the sliding window and two pointers. Until those land, work from the 15 LeetCode patterns guide, which ranks every pattern by payoff. If your loop also includes an architecture round, the system design interview preparation guide is the place to start on that half, and the step-by-step framework gives you a structure for the 45 minutes. The full 50-problem breakdown is published on the Google coding interview course page, which is currently in production.