Google Software Engineer Interview Process

Google interviewers do not make the hiring decision. Each writes a rated assessment, a committee reads the whole packet, and a team is usually chosen only afterward, so the loop tests general problem solving rather than any team's stack. Base coding problems are mostly medium. What separates candidates is the second and third follow-up (K inputs instead of two, data that no longer fits in memory, a stream instead of a list), coded in a shared document that cannot run code. Most rejections come on problems the candidate understood but did not finish cleanly in 45 minutes.

This guide breaks down each stage of the Google Software Engineer interview, what interviewers evaluate in each round, and how to prepare, with questions candidates were actually asked.

Verified: Based on 115 candidate-reported interview experiences, primarily from 2025 Q4 through 2026 Q3, cross-checked against recent public accounts.

Google Software Engineer interview process

Google runs one standardized Software Engineer loop across the company and sets a target level (L3 to L6 in most reports) before it starts. Interviewers come from any team and office; candidates in London were interviewed by engineers in Poland and Brazil. The onsite is often split, with one or two virtual rounds first and the rest weeks later, sometimes in person with reimbursed travel.

The shape changes with level. L3 and L4 loops are almost entirely coding plus one behavioral round; one L4 candidate had no design round at all. L5 adds a system design round. L6 loops reported two design rounds (a distributed rate limiter and a notification fan-out to 100 million users), one coding round, a leadership round and a deep dive into a system the candidate built.

Here's what the interview process can look like:

• Recruiter screen: A 15- to 30-minute call on background, target level, location and team interests, with a separate visa check for candidates who need sponsorship and transcripts for new graduates.
• Online assessment (many candidates, most early-career): Either a no-code work-style and judgment assessment or a 90-minute, two-problem coding test.
• Technical phone screens (one to three): 45 minutes of coding in a shared document with no code execution, sometimes after eight or nine behavioral questions.
• Coding interviews (two to four): Rounds of 45 to 60 minutes, each a medium problem with stacked follow-ups.
• Low-level design interview (often one coding round): A class built up one requirement at a time.
• System design interview (L5 and above, occasionally earlier): A product-specific distributed design written in a text document.
• Googleyness and leadership interview: A behavioral round, often also a standalone phone screen, that becomes a single-project deep dive at senior levels.

Tip: Budget each 45-minute round as 5 minutes of clarification, 20 minutes to a working solution, 5 minutes of hand-tracing and 15 minutes of follow-ups. One rejected candidate spent most of a round negotiating a vague placeholder-substitution spec with an interviewer who kept answering "up to you", and started coding with about 12 minutes left. State an interpretation and start writing.

Online assessment

Two different tests share this name. The hiring assessment has no code. Its first part presents sets of three positive work-style statements: pick the one most like you and the one least like you, a forced-choice format that replaced a plain agree/disagree scale in 2026. A shorter Likert section follows, then workplace scenarios where you pick your most and least likely response: a client's expensive gift card, a friend's startup bidding for a contract, a manager who wants to discuss a confidential project in a crowded café. Finishing in about an hour is fine.

The coding assessment gives two problems in 90 minutes, with two visible sample cases and your own tests allowed. One late-2025 pair appeared in at least four reports: tokens on a one-dimensional board that move exactly three cells right to collect coins, and grouping two-digit numbers that share a digit. Candidates remembered the second as either connected components or one common digit, so read it carefully. Early-career versions added a difference-array warm-up and a long feature-rollout task with deliberately buggy dependency parsing, where the built-in AI assistant refused most questions. One candidate passed the same night and had a first interview within a week.

Interviewers evaluate:

• Consistency (hiring assessment): Many items are near-duplicates, and contradictory answers about independence versus needing instructions stand out.
• Policy-first judgment: When a policy exists, upholding it beats meeting a deadline, keeping a friendship or keeping credit you did not earn.
• Edge-case reading (coding): Occupied cells, board limits and exactly what "shares a digit" means decide the hidden tests.
• Distrust of provided code: Assuming the given parser is wrong and proving it with the tests.

Practice timed medium problems without autocomplete, and fix your ranking of three or four genuine work-style traits before the forced-choice section.

Note: Candidates who prepared from older descriptions were caught off guard by the 2026 forced-choice format, where every option is desirable. The approach that worked was one fixed personal ranking of traits applied the same way to every trio.

Sample questions for the online assessment

Here are some questions reported by recent candidates:

• Tokens on a one-dimensional board move exactly three cells right and cannot land on another token; maximize the coins collected.

• From a list of two-digit numbers, find the largest group connected by shared digits.

• Fix the dependency parser in a feature-rollout system, then detect circular dependencies between features.

• Collect Coins on 1D Board

• Largest Group Sharing a Digit

• Feature Rollout with Dependency Cycle Detection

• Google Hiring Assessment (GHA / Work Styles)

Technical phone screens

A Google engineer runs each 45-minute screen in a shared document with no syntax highlighting, auto-indentation or code execution; one candidate had to define the tree node class from scratch. Most candidates get one or two coding screens, some three. Some screens open with eight or nine behavioral questions before the coding half. One candidate who passed heard back in about three days.

The problem is usually a medium whose follow-ups pile on: top-k users from chat logs (merge sort versus heap versus quickselect), intersecting two log files and then doing it when they no longer fit in memory, finding every bad pair with an expensive black-box test, or tokenizing text with a trie under longest-match priority. A few screens are discussion-only design, such as a store for lexicographic range queries or taxis going online and offline.

Interviewers evaluate:

• Brute force first: One interviewer wanted the naive pairwise version of a radius-clustering problem implemented, not the spatial index the candidate offered.
• Exact complexity: Each alternative compared out loud, including why a bound is O(n log max) rather than O(n log n).
• Adapting to new constraints: Changing the data structure when memory runs out or input becomes a stream, without starting over.
• Hand-tracing: Dry-running your own code on a small input, since nothing can be executed.

Practice in a plain-text editor for at least a week before the screen, saying each complexity out loud.

Note: A precise verbal plan can rescue the last minutes. One candidate who could not code a shortest-match follow-up described the exact change to the inner loop and the interviewer accepted it, while a candidate who left a game simulation half-built despite hints was rejected.

Sample questions for the technical phone screens

Here are some questions reported by recent candidates:

• Find users present in two days of logs, then repeat it when neither file fits in memory.

• Identify every bad pair among n items with an expensive pair-testing oracle, using as few calls as possible.

• Tokenize text against a key:id dictionary with longest-match priority, passing unmatched characters through, then handle a huge dictionary.

• Two-Day Log Intersection under Memory Limit

• Find All Bad Pairs Using runTest Oracle

• String Tokenization

• 2D Points Connected Components by Radius

Coding interviews

The onsite has two to four coding rounds of 45 to 60 minutes. Some contain two problems (Two Sum then Three Sum, two Dijkstra variants), and some interviewers spend 15 minutes on your résumé first. Candidates often found the base problem easier than expected; one who prepared mainly hard problems over-engineered a simple interval-conflict check with sorting and special cases when a linear scan would do.

Families recur. The minimum-cars problem for rental requests, with an assignment record per order, appeared in at least four reports. Others are meeting-room variants, flipping each leaf of a boolean expression tree, union-find over friend timelines, grid BFS where you may remove one blocker, and deducing which players' ranks are fixed by match results. Follow-ups escalate: a union of two sorted interval lists became K lists with a heap, then lists streamed from disk. A snake_case converter became a 30-minute discussion of safely renaming identifiers across a huge repository, and that round's feedback was negative.

Interviewers evaluate:

• Finished, clean code: Unwritten final conditionals and off-by-one bounds appear in feedback even when the approach was right.
• Optimal choices: One round was rated only "okay" because the candidate used DFS where BFS gave the shortest path.
• Depth on follow-ups: O(1) extra space, K inputs, streamed data, and negative weights that break a greedy recurrence.
• Self-testing: Catching your own bug while tracing, such as a final number left unsettled at the end of a parsed string.
• Composure with silent interviewers: Some arrive late, have you type the problem yourself, take notes silently or give no hints.

Practice intervals, union-find, BFS with extra state, heaps, tries and parsing until each base problem takes under 20 minutes, then drill two follow-ups for each.

Tip: Treat a passive interviewer as neutral. Candidates who read silence as failure lost composure, while one who said aloud that a greedy idea seemed infeasible got a nudge toward binary search on the answer and recovered the round.

Sample questions for the coding interviews

Here are some questions reported by recent candidates:

• Assign rental orders to the fewest cars so no car's bookings overlap, and return which car serves each order.

• For a boolean expression tree of AND, OR and XOR nodes, report the root value after flipping each leaf in turn, in linear total time.

• Merge two sorted, internally disjoint interval lists into their union, then K lists, then lists too large for memory.

• Minimum Cars to Satisfy Rental Requests + Assignment Records

• Expression Tree Single-Leaf Mutation

• Merge Two Interval Lists

• Friend Graph with Timeline (Friend / Unfriend Events)

Low-level design interview

Google rarely labels a round as object-oriented design, but about one coding round per loop is one in practice: a class from a short prompt, with constraints added one at a time. Reported prompts include an employee hierarchy where deleting a manager promotes the most senior direct report (ties go to the earliest hire date), a restaurant waitlist with first-fit seating, a run-length encoded vector with a dot product, a bookshelf whose bookmark survives edits, and a temperature monitor with an O(1) maximum over the last N readings.

Language depth is tested here. A Java engineer interviewing in Python could not finish a version of itertools.tee that splits one iterator into n independent ones, and another candidate was quizzed on attribute lookup order, recursion limits and inconsistent __hash__ and __eq__.

Interviewers evaluate:

• Invariants under change: Whether the class survives cycles, root deletion and duplicate names without a rewrite.
• Edge cases listed first: Orphaned reports, empty waitlists, vectors of different lengths.
• Metadata that avoids scans: A cached maximum or ordered set of direct reports so a successor is found quickly.
• Command of your language: Iterators, hashing and memory overhead in the language you chose.

Practice building one small class a day from a two-line prompt, then add two constraints that force a data-structure change.

Sample questions for the low-level design interview

Here are some questions reported by recent candidates:

• Support add and delete in an employee hierarchy, promoting the most senior direct report when a manager leaves and rejecting changes that create a cycle.

• Build a waitlist that seats the earliest party no larger than a free table, with removal by name.

• Store a vector with long runs of repeated values compactly, then compute the dot product of two such vectors.

• Employee Hierarchy Add / Delete

• Restaurant Waitlist: join / delete / find_first_match

• Run-Length Vector Storage + Dot Product

• Design a Bookshelf with Book CRUD and a Stable Bookmark

System design interview

L5 loops include one design round and L6 loops two, and design occasionally appears earlier, such as an anomaly-detection system in a phone screen. Prompts are tied to concrete products: an entry counter enforcing capacity across many mall gates, menu updates pushed to thousands of restaurants that must work offline, Street View uploads from taxis including a compromised upload token, a crawler for billions of pages, and a rate limiter for Drive quotas or an AI agent's billing tokens.

Requirements are vague on purpose and shift mid-round. The crawler interviewer probed per-host politeness queues, how long to cache robots.txt, what Bloom-filter false positives cost (pages never crawled) and the bottleneck for a 24-hour refresh. Senior candidates were pushed on fail-open versus fail-closed, hot keys and multi-region replication.

Interviewers evaluate:

• Scoping: Scale, latency and consistency targets clarified before any component appears.
• Failure modes you raise: Partitions between gates, double counting, retries and dead-letter queues, token revocation.
• Reasoned trade-offs: Token bucket versus sliding window, push versus pull, exact versus probabilistic deduplication.
• Driving the discussion: Steering into deeper areas without waiting for prompts.

Prepare six to eight designs from Google's own products, each written as a structured text outline.

Note: Design rounds happen in a shared text document with no drawing tool. An L6 candidate rejected after a Drive-quota rate limiter round singled out this limit and the shifting requirements; lay out components, data flow and APIs as indented lists or simple ASCII.

Sample questions for the system design interview

Here are some questions reported by recent candidates:

• Design a mall entrance system across several gates that never exceeds capacity and recovers the right count after a network partition.

• Push menu changes to thousands of restaurants worldwide, keeping each usable offline and reconciling on reconnect.

• Design a crawler for billions of pages feeding a search index, with re-crawls, politeness and trap detection.

• Design a global restaurant menu update system

• Web Crawler at Search Scale

• Design Quota Service

• L6 System Design (Staff Loop)

Googleyness and leadership interview

Behavior is scored in a dedicated 45-minute round, often both as a standalone phone screen and onsite, and behavioral questions are added to many coding rounds. Interviewers work from five to nine prompts and ask for a second and third example when an answer sounds rehearsed. Common prompts: conflict with a teammate, a colleague who took credit for your work, disagreeing with a manager or product manager, helping someone who is struggling, feeling overwhelmed. Less expected: a personal goal outside work, a bug in code your team owns versus code it does not, AI ethics, technical debt under a deadline, and something Google could do better.

At L5 and above the round can spend all 45 minutes on the trade-offs of one past project, and L6 adds a separate deep dive into a system you designed. Reporting on Google's 2026 process update says this technical conversation about past work is being added to the round more broadly. One manager-run round rewarded concrete numbers and the reasoning behind each decision, and note-taking picked up when a failure story explained why the plan had seemed sound.

Interviewers evaluate:

• Range of examples: A distinct second story for conflict and collaboration, not a variation on the first.
• Ownership that scales: Fixing what you own while still caring about customer impact in code you do not.
• Seeking other views: A design that improved because of someone else's input, and how that input surfaced.
• Constructive critique: Criticizing Google like a system, with a constraint and a fix, never venting.
• Measurable results: Endings with numbers, which practiced answers often rush.

Prepare 8 to 10 stories, at least two each for conflict and failure, and record yourself to tighten the endings.

Sample questions for the Googleyness and leadership interview

Here are some questions reported by recent candidates:

• You find a bug in a codebase your team does not own, then one in a codebase you do own; walk through what you do in each case.

• Tell me about a time a teammate claimed more credit than they deserved.

• What could Google do better, and how would you fix it if you were on that team?

• Behavioral Round (Googliness Themes)

• Answer Google Behavioral Questions

• Describe Helping an Underperforming Peer

How Google levels and evaluates Software Engineer candidates

Each interviewer submits a written rating with reasoning, and a hiring committee decides from the full packet. Ratings in one loop can diverge: a candidate with one "okay" (DFS where BFS was optimal, small bugs noted) and one "strong" still moved to team match, while others with friendly interviewers and good behavioral rounds were rejected on a single coding round. Feedback typically arrives about a week after the last round and the committee decision about a week later.

The committee can approve below the target level; one L4 candidate was approved at L3 and went straight to team matching. Recruiters then share the packet with teams that have headcount, sometimes placing a candidate without a matching call. Matching is slower in Europe and when headcount is tight. A visa check or transcript request after the onsite is routine paperwork: one New York candidate had a visa check in late December and a rejection in mid-January.

How to prepare for the Google Software Engineer interview

1. Practice in a plain document: Solve problems with no highlighting, completion or execution, and hand-trace every solution before calling it done.
2. Drill follow-ups, not just base problems: For each problem, add K inputs, a memory limit, streaming input and an O(1)-space variant.
3. Cover Google's recurring families: Interval scheduling with assignment records, union-find over timelines, BFS with extra state, expression-tree updates and binary search on the answer.
4. Commit to an interpretation early: When a spec stays vague, state your assumption and start coding within about ten minutes.
5. Size the problem honestly: Write the simplest correct solution to an easy question before reaching for sorting or clever structures.
6. Know your interview language deeply: Iterators, hashing rules and recursion limits are asked directly, especially in Python.
7. Write designs as text: At L5 and above, rehearse product-specific designs as outlines with failure modes stated early.
8. Prepare two stories per behavioral theme: Include numbers, the reasoning behind each decision, and a constructive critique of Google.

About the Google Software Engineer role

Google Software Engineers work in a very large shared codebase where nearly every change needs review, plus approval from an engineer certified in that language's style ("readability"), so first changes often take several review rounds. Engineers write design documents, own services in production and usually join a team only after the hiring decision. Many engineers stay at L5 long term, and the step to L6 is widely described as the hardest promotion.

Google hires Software Engineers across the company. Teams include:

• Google Cloud: Compute, storage, networking, security and AI infrastructure.
• Search: Ranking, indexing and search platforms.
• YouTube: Video serving, mobile apps and recommendation systems.
• Platforms and Devices: Android, Chrome and Pixel.
• Core: Shared infrastructure, developer tools and machine learning platforms.
• Google Workspace: Gmail, Docs, Drive and their identity and security systems.
• Google DeepMind: Research engineering and Gemini infrastructure and evaluation.

Software Engineer experience and education requirements

Postings require a bachelor's degree or equivalent practical experience. Software Engineer III (L4) postings typically ask for two years of development in a language such as C++, Python or Java (one year with an advanced degree) and prefer a master's or PhD in computer science, data structures and algorithms experience, and large-scale systems or debugging work. Any mainstream language is accepted in interviews, but expect questions on its internals.

FAQs about the Google Software Engineer interview

How long does the Google Software Engineer interview process take?

Usually two to four months from first contact to a decision, plus team matching. One New York candidate went from application to rejection in about ten weeks; an early-career candidate took about four months to reach the onsite; and one applicant waited ten months before any contact. Recruiters can take one to two weeks to reply, so follow up at each stage.

What is the hardest round of the Google Software Engineer interview?

For L3 to L5, the onsite coding rounds, where layered follow-ups and the 45-minute limit decide most rejections. At L6, the two system design rounds and the deep dive into a system you built carry the most weight.

Can you get down-leveled?

Yes. The hiring committee sets the final level from the whole packet, and a candidate interviewed at L4 was approved at L3 without further interviews.

Is AI allowed during the interview?

Not in standard live rounds. In 2026 Google began piloting a code-comprehension round for junior and mid-level candidates on selected US teams, where candidates read, debug and improve an existing codebase with Gemini available and are judged on how well they validate its output.

How much does a Google Software Engineer make?

Approximate total annual compensation in the United States:

• L3 (Software Engineer II): ~$200K
• L4 (Software Engineer III): ~$300K
• L5 (Senior Software Engineer): ~$410K
• L6 (Staff Software Engineer): ~$600K

Packages combine base salary, an annual bonus and Google stock units that vest over four years with more of the grant in the early years; stock becomes the largest component from L5 up.

---

Other Tracks at Google

• Google Machine Learning Engineer Interview Process