Interview experience
Google Interview Questions and Answers (2026)
Overview
Section titled “Overview”Google’s loop runs a recruiter screen, a phone screen, and a 4-5 round onsite (coding, system design at L5+, and a Googleyness/Leadership round) - then a Hiring Committee outside your team, not your interviewers, makes the actual decision.
Google interview process at a glance
Section titled “Google interview process at a glance”| Stage | Duration | What it tests |
|---|---|---|
| Recruiter screen | 20-30 min | Background, logistics, timeline, initial fit |
| Online Assessment (new grad/L3) | ~90 min | ~2 coding problems; L4+ often skips this stage |
| Phone screen | 45-60 min | 1 live coding problem in a shared Google Doc |
| Onsite - Coding (2-3 rounds) | 45-60 min each | DSA, often phrased non-standardly to test clarifying questions |
| Onsite - System design (L5+) | 45-60 min | Distributed systems fundamentals |
| Onsite - Googleyness/Leadership | 45-60 min | Ambiguity, learning agility, influence without authority |
| Hiring Committee | 1-2 weeks | Independent packet review; committee decides, not interviewers |
| Team matching | Varies | Hiring managers with open headcount review your packet |
Recruiter screen and Online Assessment
Section titled “Recruiter screen and Online Assessment”A short call covering background, location/visa logistics, and timeline - no coding. New grad and L3 candidates then typically get an Online Assessment (roughly 2 coding problems); L4+ candidates often skip straight to the phone screen.
Common questions
- Array/string manipulation problems at LeetCode-medium difficulty
- A second problem testing a different pattern (graphs, DP, or intervals)
Phone screen
Section titled “Phone screen”A single 45-60 minute live coding round with a Google engineer, done in a shared Google Doc - no IDE, no autocomplete, no ability to compile or run your code. Google is explicitly evaluating whether you can write syntactically clean code while narrating your reasoning, not just whether the final answer is correct.
Common questions
- Interval problems with a deliberately unusual phrasing that requires clarifying questions first
- Topological sort or graph traversal variants not found verbatim on LeetCode
- Sliding window / two-pointer array problems
Full round-by-round breakdowns are on the Google interview experience page.
Onsite: coding rounds
Section titled “Onsite: coding rounds”2-3 back-to-back 45-60 minute rounds, similar format to the phone screen. Google reuses fewer “standard” LeetCode problems than some peers - expect a familiar pattern wrapped in an unfamiliar problem statement.
Common questions
- Implement a rate limiter (fixed window, sliding window, token bucket)
- Find the median of two sorted arrays
- Design a data structure for range-sum queries (segment tree)
- Longest palindromic substring
Onsite: system design (L5+)
Section titled “Onsite: system design (L5+)”Mainly weighted at L5 and above, though some L3/L4 loops include a lighter design discussion. Google is checking whether you can reason about scale, trade-offs, and failure modes, not just recite a memorized architecture.
Common questions
- Design a URL shortener
- Design a distributed cache or rate limiter
- Design a distributed logging/metrics pipeline
Onsite: Googleyness and Leadership
Section titled “Onsite: Googleyness and Leadership”A behavioural round distinct from a generic “culture fit” chat. Google explicitly evaluates four signals across the loop - General Cognitive Ability, Role-Related Knowledge, Leadership, and Googleyness - and this round leans hardest on the last two: comfort with ambiguity, intellectual humility, and leading through influence rather than authority.
Common questions
- Tell me about a time you had to work through ambiguity with little direction
- Describe a situation where you influenced a decision without formal authority over the people involved
- Tell me about a time you disagreed with a teammate’s approach
- Tell me about a time you learned a new technology or domain quickly
Sample STAR frameworks for these are on the Google HR interview questions page.
The Hiring Committee
Section titled “The Hiring Committee”This is Google’s most distinctive step: your interviewers don’t decide whether you’re hired. Each writes independent feedback and a vote (Strong Hire, Hire, Leaning Hire, Leaning No-Hire, No-Hire, Strong No-Hire) without seeing anyone else’s score, specifically to avoid anchoring bias. A separate committee of senior Googlers from outside your target team then reviews the full packet and makes the actual call - which is why one weak round can be outweighed by strong, consistent signal across the rest of the loop, but one round that flatly contradicts the others is a real risk.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: How do you merge overlapping intervals?
Sort the intervals by start time, then sweep left to right keeping one active interval. For each next interval, if its start is less than or equal to the end of the active interval, they overlap, so extend the active interval’s end to the maximum of the two ends; otherwise push the active interval to the result and make the current one active. Sorting dominates the cost, so the algorithm is O(n log n) time and O(n) space for the output. The classic follow-up is inserting a single interval into an already-sorted list, which drops to O(n) because no sort is needed.
Q: How do you find the longest substring without repeating characters?
Use a sliding window with two pointers and a hash map from character to its last seen index. Expand the right pointer one character at a time; when you hit a character already inside the window, jump the left pointer to one past that character’s last index so the window is valid again, then update the best length. Each character is visited at most twice, giving O(n) time, and space is O(k) where k is the size of the character set. The key detail interviewers probe is that you must move the left pointer forward only, never backward, or the window can become invalid.
Q: How does topological sort work, and how do you detect a cycle in a directed graph?
Kahn’s algorithm computes the in-degree of every node, pushes all zero in-degree nodes into a queue, and repeatedly pops a node, appends it to the ordering, and decrements the in-degree of each neighbour, enqueueing any that reach zero. It runs in O(V + E) time and O(V) space. If the final ordering contains fewer than V nodes, the remaining nodes are stuck in a cycle, so the graph is not a DAG and no topological order exists. The DFS variant instead colours nodes white, grey, and black, and reports a cycle the moment a DFS edge points at a grey node still on the recursion stack.
Q: Explain dynamic programming using the coin change problem.
Dynamic programming solves a problem by combining answers to overlapping subproblems and storing each answer once. For coin change with target amount A and coin denominations, define dp of i as the fewest coins that make amount i, with dp of 0 equal to 0 and every other entry starting at infinity. For each amount i, try every coin c with value at most i and set dp of i to the minimum of itself and dp of i minus c plus one. That is O(A times number of coins) time and O(A) space, and dp of A being still infinity at the end means the amount is unreachable.
Q: How do you find the median of two sorted arrays in logarithmic time?
Binary search on the partition point of the smaller array rather than on values. Pick a cut in array A, derive the matching cut in array B so the left halves together hold exactly half the total elements, then check the boundary condition that the largest element left of the cut in A is not greater than the smallest element right of the cut in B, and symmetrically for B. If the condition fails, move the binary search in A left or right accordingly. When it holds, the median is the maximum of the two left boundary values for odd total length, or the average of that maximum and the minimum of the two right boundary values for even length. This gives O(log(min(m, n))) time and O(1) space.
Q: How would you answer range-sum queries efficiently?
If the array never changes, a prefix-sum array is enough: precompute prefix of i as the sum of the first i elements in O(n), then any range sum from l to r is prefix of r plus one minus prefix of l in O(1). If updates are interleaved with queries, use a segment tree, a binary tree where each node stores the sum of a contiguous range, leaves are single elements, and each internal node is the sum of its two children. Building it is O(n), and both a point update and a range query are O(log n) because they touch at most a couple of nodes per level. A Fenwick (binary indexed) tree does the same job with less memory when you only need prefix sums.
Q: How do you find the longest palindromic substring?
The expand-around-centre approach treats every index as a potential palindrome centre. Because a palindrome can have odd length (centred on a character) or even length (centred between two characters), there are 2n minus 1 centres; from each one, expand outward while the characters on both sides match, and track the longest span seen. That is O(n squared) time and O(1) extra space, which is the answer most interviewers want. A dynamic-programming table of is-palindrome flags has the same time bound but O(n squared) space, and Manacher’s algorithm solves it in O(n) if you are asked to do better.
Q: How would you design a rate limiter?
A fixed-window counter keeps a count per key per time bucket and is trivial to implement, but it allows a burst of up to two times the limit at a window boundary. A sliding-window log stores request timestamps and evicts anything older than the window, which is exact but memory-heavy; a sliding-window counter approximates it by weighting the previous window’s count. A token bucket refills tokens at a steady rate up to a capacity and lets a request through only if a token is available, which is usually the best answer because it smooths traffic while still permitting controlled bursts. Distributed, you would keep the counters in Redis with atomic increment-and-expire so multiple servers share one limit.
Frequently asked questions about Google interviews
Section titled “Frequently asked questions about Google interviews”What is the Google interview process?
Google’s loop usually runs: 1. Recruiter screen (20-30 min) - background, logistics, timeline. 2. Online Assessment (new grad/L3 only - roughly 2 coding problems; L4+ often skips this). 3. Phone screen (45-60 min) - one live coding problem in a shared Google Doc, no IDE or autocomplete. 4. Onsite loop (4-5 rounds, 45-60 min each) - 2-3 coding rounds, one system design round (mainly L5+), and one Googleyness/Leadership behavioural round. 5. Hiring Committee review (1-2 weeks) - a panel outside your team reviews written feedback and votes, not your interviewers. 6. Team matching. Total timeline: 6-8 weeks.
What questions are asked in Google interviews?
Coding rounds cover arrays/strings, trees and graphs, dynamic programming, and interval problems - often phrased in a non-standard way that requires clarifying questions rather than pattern-matching to a memorized LeetCode problem. System design (L5+) covers distributed systems basics: URL shorteners, rate limiters, distributed caches, logging pipelines. The Googleyness round asks about ambiguity, learning agility, and collaborative leadership without formal authority.
What is the Google Hiring Committee?
A panel of senior Googlers (typically L6+) from outside your interviewing team who make the actual hire/no-hire decision - not your interviewers. Each interviewer writes independent feedback and a vote (Strong Hire to Strong No-Hire) without seeing others’ scores, to avoid anchoring. The committee reviews the full packet, which is why consistency across rounds matters more here than performing well in just one interview.
How many rounds are there in the Google interview?
Typically 6-7 touchpoints: recruiter screen, an online assessment (new grad/L3), a phone screen, a 4-5 round onsite loop, Hiring Committee review, and team matching. Experienced (L4+) candidates often skip the online assessment and go straight to the phone screen.
How should I prepare for Google interviews?
Practice explaining your approach out loud before writing code - Google’s Google-Docs format has no autocomplete or compiler, so clarity matters as much as correctness. Prepare system design fundamentals if you’re L5+, and prepare STAR stories specifically about ambiguity, learning agility, and driving a decision without formal authority for the Googleyness round.