Google Software Engineer Interview Questions (2026)

How many rounds are in the Google software engineer interview loop?

Most candidates go through five stages: a recruiter screen, an online coding assessment, one or two technical phone screens, a virtual onsite loop of four to five rounds (coding, system design, Googleyness), and a hiring committee review. The full process typically takes eight to twelve weeks.

What coding topics does Google focus on in interviews?

Google coding rounds test arrays and strings, hash maps, trees and graphs (DFS/BFS), dynamic programming, heaps and priority queues, and recursion and backtracking. Questions are typically medium-to-hard LeetCode difficulty with follow-up optimizations.

Does Google ask system design questions for all levels?

Not always. L3 candidates (new grad) usually skip system design. L4 may get one light design round. L5 and above get one or two full system design rounds covering scale, trade-offs, and distributed systems concepts.

What is Googleyness and how is it evaluated?

Googleyness is Google's term for cultural fit. The behavioral round assesses intellectual humility, comfort with ambiguity, bias toward action, collaborative mindset, and prioritizing the user. A strong negative signal here can override excellent technical scores.

What happens in the Google hiring committee review?

After the onsite, a committee of engineers and managers who did not interview you reads all scorecards independently and votes. Google uses consensus rather than majority vote — one strong 'no hire' can block an offer. The committee's recommendation then goes to an executive review before an offer is extended.

What is the Google software engineer acceptance rate?

Estimates put Google's overall application-to-offer rate at roughly 0.2% to 0.5%. Of candidates who make it to the onsite loop, approximately 15–20% receive an offer.

How does Google level software engineers at hire?

Google levels run L3 (new grad) through L8 and above. L4 is a typical hire for engineers with two to five years of experience; L5 is senior. Leveling is set during the loop, not at offer, and the difference between L4 and L5 at hire can exceed $100,000 in annual total compensation.

What total compensation can I expect as a Google software engineer?

Based on Levels.fyi data, median total compensation is approximately $212K at L3, $309K at L4, $414K at L5, and $611K at L6. These figures include base salary, RSU grants, and target bonus.

How should I prepare for Google system design at L5?

For L5, interviewers evaluate whether you can break down an ambiguous problem, discuss API design, data storage trade-offs, caching, sharding, and fault tolerance. They often add constraints mid-interview ('traffic doubles overnight') to test adaptability. Practice designing systems end-to-end in 45 minutes with explicit trade-off narration.

What is the best way to structure behavioral answers at Google?

Use the STAR framework (Situation, Task, Action, Result) and make the result measurable. Google interviewers specifically look for intellectual humility — include what you would do differently — and for evidence of collaboration and ambiguity tolerance, not just solo wins.

Getting a software engineering role at Google is a multi-month process with clearly defined stages, its own scoring rubric, and a culture-fit dimension that carries as much weight as your algorithm performance. This guide covers how the 2026 loop actually runs, what each round is looking for, level-specific expectations, real question types with sample approaches, and a concrete prep plan.

The Google interview loop from start to offer

The process has five stages, and skipping any mental preparation for the ones that feel administrative is a common mistake.

1. Recruiter screen (20–30 minutes) The recruiter checks basic fit: current role, timeline, compensation expectations, and whether you meet minimum qualifications. Be direct about your target level. If you aim for L5 but let the recruiter assume L4, you may be evaluated against a lower bar and offered less — and the leveling is set during the loop, not at negotiation.

2. Online assessment (60–90 minutes) Usually two LeetCode-style problems in a timed environment. Google uses its own platform (not HackerRank or CoderPad). Problems are medium to hard difficulty. Edge case handling and clean code matter even here, because the assessment outputs are shown to your eventual phone screen interviewer.

3. Technical phone screen (45–60 minutes) One or two rounds via Google Meet with a shared coding environment. Each round is one algorithm problem with follow-up questions. The interviewer pushes for time/space complexity analysis and often asks you to optimize after your initial solution. Speaking your reasoning out loud is graded — silence while coding reads as poor communication.

4. Virtual onsite loop (four to five rounds, each 45 minutes) This is the core of the process. Rounds are distributed across interviewers who score independently. A typical L5 loop looks like this:

• Two coding rounds
• One system design round
• One Googleyness (behavioral) round
• One additional round that can be coding or a second design, depending on the role

L3 loops often drop the system design round. L6 loops add a second design and expect staff-level scope.

5. Hiring committee review + executive review Your packet — every scorecard, interviewer note, and your resume — goes to a committee of engineers and managers who were not in your loop. They read independently, then convene. Google does not use majority vote; consensus is required. A single strong “no hire” with solid reasoning can block an offer. After the committee approves, an executive review occurs before the offer is formally extended. This step adds one to three weeks to the timeline.

Total time from application to offer: eight to twelve weeks is typical; some candidates report sixteen weeks for specialized or senior roles.

What Google uniquely evaluates

Most tech companies run coding and system design interviews. Google has two dimensions that distinguish its process.

The four-attribute rubric

Every round is scored on four axes, not just technical correctness:

1. General cognitive ability — can you solve novel problems under pressure, and can you explain your reasoning at each step?
2. Role-related knowledge — do you understand the relevant algorithms, data structures, or systems concepts at the depth the role requires?
3. Leadership — not management experience; Google defines this as taking ownership, influencing without authority, and moving work forward in ambiguous situations.
4. Googleyness — intellectual humility, comfort with ambiguity, bias toward action, and genuine prioritization of the user.

Score cards use a 1–4 scale. A score of 3 (“hire”) is the threshold, but the committee weighs all four axes together — a 4 on coding and a 1 on Googleyness produces a complex packet, not an obvious offer.

Googleyness is not soft

Google’s behavioral round is often underestimated by engineers who spend all their prep time on algorithms. The Googleyness interview has blocked candidates with strong technical scores. Google’s careers documentation describes what it is looking for as people who are “motivated by things other than personal success or recognition,” who “challenge the status quo” but do so “constructively,” and who “put the user’s interests first.”

What that means in practice: interviewers listen for moments where you ceded credit, changed your mind based on data, or kept a project moving when requirements were unclear. Stories where you were the only hero often score poorly.

Coding rounds: what they actually ask

Google coding interviews use medium-to-hard LeetCode-style problems. Topic distribution across a typical loop:

• Arrays and strings: sliding window, two-pointer, prefix sums
• Hash maps and sets: frequency counting, anagram detection, two-sum variants
• Trees and graphs: DFS, BFS, topological sort, shortest path (Dijkstra, Bellman-Ford)
• Dynamic programming: longest common subsequence, coin change, matrix path problems
• Heaps and priority queues: K-th largest element, median of a data stream
• Recursion and backtracking: N-queens, permutations, word search on a grid

A common pattern: the interviewer gives you a problem that has a brute-force O(n²) solution and then asks you to optimize. The optimization often introduces a new data structure (heap, monotone stack, trie). If you get to a working solution quickly, expect a follow-up: “How would this change if the input was sorted?” or “What if the array doesn’t fit in memory?”

Sample problem and approach

Problem: Given an integer array, return the indices of two numbers that add up to a target. You cannot use the same element twice.

Brute-force: Nested loop, O(n²) time, O(1) space.

Optimized approach: Single pass with a hash map. For each element, check whether target - current is already in the map. If yes, return both indices. If no, store current → index. Time O(n), space O(n).

Follow-up Google asks: “What if there are multiple pairs?” or “What if the array is sorted — can you do it in O(1) space?” (Two-pointer from both ends.) Prepare to handle both variants.

System design rounds (L4 and above)

System design at Google is not about drawing boxes. The interviewer is evaluating whether you think like someone who has operated systems at scale.

L4 expectations

You should be able to clarify requirements, sketch a basic architecture with a load balancer, one or two services, and a database, and discuss one or two trade-offs (e.g., SQL vs. NoSQL for this use case). Volume estimation is expected but can be rough.

L5 expectations

At L5, interviewers expect you to proactively address API contracts, data model design, caching strategy (write-through vs. write-back, eviction policy), sharding or partitioning rationale, and fault tolerance. You should drive the conversation — the interviewer asks clarifying questions, not the other way around. They often inject new constraints mid-design: “Now assume traffic doubles in 24 hours.” Candidates who pause, acknowledge the constraint explicitly, and reason through it calmly score better than those who rattle off infrastructure buzzwords.

L6 expectations

L6 design rounds expect multi-datacenter thinking: consistency models (strong vs. eventual), cross-region replication strategies, and operational concerns like observability and graceful degradation. You are expected to identify hidden trade-offs proactively, not in response to prompts.

Sample system design question (L5)

Prompt: Design a URL shortener.

Strong L5 approach:

• Clarify scale: “Are we targeting 100M shortened URLs per day, or more like 1M? Read-heavy or write-heavy?” (Google interviewers reward this.)
• API: POST /shorten → returns short code; GET /{code} → 301/302 redirect.
• Storage: a key-value store (e.g., Cassandra or DynamoDB) maps code → original URL. Short code generated via base62 encoding of an auto-incrementing ID or a hash with collision handling.
• Caching: serve redirects from a CDN or in-memory cache (Redis) to reduce DB reads on popular links.
• Analytics: use an async event stream (Kafka) for click tracking so it doesn’t add latency to the redirect path.
• Trade-off narration: “I’m choosing eventual consistency on analytics because a slightly stale click count is acceptable; for the actual redirect, I need strong consistency so the short code always resolves correctly.”

Behavioral round: Googleyness questions and answers

The behavioral round uses structured questions that require specific past examples, not hypothetical answers. “I would…” answers consistently score lower than “I did…” answers.

Common question types:

• Tell me about a time you disagreed with a technical decision but the team went forward anyway. What did you do?
• Describe a project where the requirements changed mid-execution. How did you handle it?
• Give me an example of a time you received critical feedback that you initially disagreed with. What happened next?
• Tell me about a time you had to influence a decision without having direct authority over the people involved.

What good answers include:

A tight STAR structure (Situation → Task → Action → Result) where the Result includes a specific outcome (latency reduced by 40%, shipped two weeks ahead of schedule, retention improved). The Action component should show collaboration or intellectual humility, not solo heroics. End with what you learned or would do differently — this is where intellectual humility lands.

Sample answer structure (question: critical feedback you disagreed with):

“On a previous team, an engineering manager told me my code review comments were too technical and were slowing down junior engineers. My initial reaction was that thorough reviews were part of quality engineering. I asked for specific examples, and when I read the comments back, I realized they read as corrections, not guidance — I was right about the code but unhelpful about the person. I adjusted my format to explain the ‘why’ behind each comment and added a summary at the top of each review. Three months later two junior engineers told me my reviews were the most useful feedback they got. The manager noted the change in my next check-in without me prompting it.”

That answer is specific, shows a moment of being wrong, and has a measurable (if qualitative) outcome.

Leveling and compensation context

Google’s leveling system runs from L3 to L9+, though L9 is reserved for Fellows and L8+ roles are effectively internal promotions.

The L4→L5 transition is the most consequential leveling decision at hire — the median gap is roughly $105K in annual total compensation. If you have senior-level experience, explicitly discuss leveling expectations with your recruiter before the onsite. Your loop can be re-scoped to include a second system design round to evaluate you at L5.

Sign-on bonuses range from $20K at L3 to $100K or more at L6. Google’s RSUs vest quarterly after a one-year cliff, and refreshers begin at L5.

Six-week prep plan

Google’s hiring rate from application to offer is approximately 0.2–0.5%. Reaching the onsite requires clearing an online assessment and phone screens; reaching the offer requires consistency across four to five rounds. Six weeks of focused preparation is a reasonable minimum for a mid-level candidate.

Weeks 1–2: Algorithm fundamentals Work through arrays, strings, hash maps, linked lists, trees, and graphs. For each topic, solve five medium problems and one hard. Practice narrating your approach out loud. Use a timer — you have 45 minutes including problem clarification, coding, and complexity analysis.

Weeks 3–4: Advanced topics + optimization Cover dynamic programming (bottom-up and top-down), heaps, tries, and graphs (Dijkstra, union-find). After each solution, practice the “can you do better?” follow-up — optimize time, then space.

Week 5: System design Study distributed system fundamentals: consistent hashing, CAP theorem, leader election, cache eviction policies, message queues. Practice the URL shortener, Twitter feed, and rate limiter design problems. Time yourself to 45 minutes and record your narration to identify gaps.

Week 6: Behavioral + mock loop Write out five to seven STAR stories covering ambiguity, conflict, feedback, ownership, and failure. Do one full mock loop (coding + design + behavioral) with a peer or service like Pramp. The goal is to simulate the pacing and cognitive load of a real onsite day.

Throughout prep, track every problem you solve, the approach that worked, and the concepts you misidentified. A spreadsheet or a job tracker helps surface the gaps you keep re-encountering before they surface in the actual loop.

One thing most candidates miss

Google’s interviewers are not just evaluating whether you get the right answer. They are evaluating whether they would want to debug a production incident with you at 2am. That means they watch for how you react when you are stuck, how you incorporate hints, and whether you stay methodical under pressure. Practicing on easy problems until you never get stuck will not prepare you for this. Practicing with hard problems and explicitly rehearsing what you say when you are stuck — “I’m not sure of the optimal approach yet, so let me start with a brute-force solution and reason from there” — is the preparation that translates.