Google interview questions for software engineers

Google's interview loop is the most public-domain-documented process in tech. Algorithms-first, structured rubric, hiring committee review, and a separate team-match step that can stretch the process to two months. This guide breaks down what each round actually tests, the question patterns you'll see, and where most candidates lose points — based on public Glassdoor patterns, Google's own published values, and the Hiring Committee framework Lazlo Bock wrote about in Work Rules.

The Google interview process

Standard SWE loops have five phases. Phase 1: recruiter screen (30 minutes, basic background, salary anchor). Phase 2: phone screen (45 minutes with an engineer, one coding question on a shared doc — no IDE, no autocomplete). Phase 3: onsite (4-5 rounds: two coding, one system design at L4+, one Googleyness/behavioral, optionally one domain deep-dive). Phase 4: hiring committee (a separate group of engineers reviews packets, no one on this committee interviewed you). Phase 5: team match (you pass the loop into a candidate pool, teams pick you for their open headcount).

Total timeline: 6-10 weeks if everything moves smoothly. Team match is the unpredictable step — strong candidates have waited 6+ weeks for a team to claim them, especially during hiring freezes or in less popular orgs. If you have a referral to a specific team, ask the recruiter to fast-track team match conditionally.

Top 10 technical questions to prepare

These are the question patterns Google interviewers reliably draw from, based on Glassdoor reports across the last several years. The exact wording will differ; recognize the shape.

1. Two-pointer on a sorted array — find pairs, find triplets, find the closest sum. Hint: practice the pivot moment where you switch between expanding and contracting.
2. Sliding window with character frequency — longest substring with at most K distinct chars, minimum window substring. Hint: a hashmap + two pointers solves 90% of these.
3. Tree traversal with state — binary tree max path sum, lowest common ancestor variants. Hint: post-order recursion where you return both an answer and a contribution to the parent.
4. Graph BFS with constraints — word ladder, shortest path in a grid with obstacles or fuel limits. Hint: state in your visited set must include all dimensions of constraint, not just position.
5. Dynamic programming on intervals or grids — edit distance, regex matching, paths in a grid. Hint: define the state in plain English before writing the recurrence.
6. Backtracking with pruning — N-queens, Sudoku, permutations with constraints. Hint: pruning early is what separates a working answer from a timed-out one.
7. Design a data structure — LRU cache, time-bound key/value store, autocomplete with trie. Hint: clarify the API before implementing; ask which operations must be O(1) vs O(log n).
8. Heap / priority queue scheduling — meeting rooms II, top K elements in a stream, merge K sorted lists. Hint: a max-heap of fixed size K is the right answer to half of streaming problems.
9. String parsing under pressure — basic calculator, valid number, decode string. Hint: an explicit stack beats a hairy regex every time in an interview.
10. Bit manipulation edge case — single number variations, counting bits, missing number with XOR. Hint: rehearse XOR identities until they're reflexive.

Top 5 system design topics (L4 and above)

1. Distributed key-value store / cache — partitioning, replication, consistency tradeoffs, hot key handling. Practice Dynamo and Bigtable patterns.
2. News feed or ranked timeline — fanout-on-write vs fanout-on-read, ranking signals, freshness vs personalization tradeoff.
3. URL shortener at Google scale — ID generation strategies, redirect latency, abuse detection.
4. Web crawler — politeness, deduplication, URL frontier prioritization, distributed coordination.
5. Real-time analytics pipeline — event ingestion, windowed aggregation, late-arriving data, exactly-once semantics.

For each, walk in with: a 60-second problem clarification template, a back-of-envelope capacity calculation (QPS, storage, bandwidth), a baseline architecture diagram in your head, and 2-3 specific tradeoffs to surface when the interviewer pushes. The number-one failure mode is jumping to a diagram before asking what scale matters.

Top 5 behavioral questions (Googleyness round)

1. Tell me about a time you disagreed with a teammate. They're looking for intellectual humility, not winning the disagreement.
2. Describe a project that failed and what you learned. Owning the failure cleanly is the test — vague answers signal blame-shifting.
3. Tell me about a time you had to learn something new under pressure. Comfort with ambiguity is a core Googleyness signal.
4. Walk me through a technical decision you regret. Self-awareness, not perfection. Senior candidates who can't name a regret look unreflective.
5. How do you handle being assigned work outside your area of expertise? Bias-for-action and curiosity, with concrete steps and outcomes.

Tips specific to Google's culture

Google interviewers grade against a public rubric. The rubric weights problem-solving process as heavily as final answer. This means thinking out loud is not optional — silent solvers get marked down even if they reach the correct answer. Narrate: state your assumptions, name your data structure choice, explain why you rejected the alternative, then code. When you hit a stuck point, say so out loud and describe what you're trying. Interviewers can hint within the rubric, but only if they understand where you are.

The hiring committee never met you. Your interviewer writes a packet that gets read like a court filing — direct quotes, time-stamped milestones, signal/no-signal calls. The committee bias is to reject when uncertain. Your job in every round is to give your interviewer enough concrete evidence to write a confident packet. Vague hand-waves help no one.

One specific failure mode: candidates over-optimize. Don't prematurely write a hashmap solution when the brute-force is fine for clarification. Walk through brute-force, name its complexity out loud, then optimize. Skipping the brute-force step reads as 'pattern-matched a memorized solution', which is a red flag at L5+.

Frequently asked questions