general

Google's Software Engineer Interview: A Complete Guide

Google's software engineer interview is one of the most standardized hiring processes in tech, and one of the most misunderstood. Unlike Amazon's interview, where behavioral principles dominate, Google's loop leans hard on raw problem-solving, with a committee model that means nobody you meet actually makes the hiring decision. Understanding that structure changes how you prepare.

This guide walks the loop stage by stage, explains what each round is grading, lists the question types you will meet, shows how the bar moves with level, and ends with a preparation plan that fits the committee model rather than fighting it.

The process stage by stage

Recruiter screen. Logistics, background, target level, and a check that your experience fits the role family. Ask about level here, not later.
Technical phone screen (one or two, about 45 minutes). A coding problem in a shared editor with an engineer. Expect to write real code, not to talk about code.
Onsite loop, now usually run over video. Typically four or five rounds: three coding, one system design (L5 and above; lighter or absent for early-career), and one behavioral round called Googleyness and Leadership.
Hiring committee. A panel of engineers who never met you reads every interviewer's written feedback and votes. The committee can approve, reject, or ask for an extra round when the packet is split.
Team matching, often after approval. You talk to hiring managers with open headcount, and an offer follows a match. Some organizations run team matching before the committee; your recruiter will tell you which order applies.
Offer review. Compensation is set against the approved level and reviewed separately from the interviewers. Negotiation happens here, within the level's band.

End to end, the process commonly takes several weeks and sometimes a few months, mostly waiting on scheduling and committee slots rather than on you.

The committee model has a practical consequence: your interviewers are writing evidence, not making decisions. Narrate your thinking clearly enough to be quoted. A scribbled-silence-then-answer performance produces weak feedback packets even when the answer is right, because the interviewer has nothing to write about how you got there.

What each round grades

Every interviewer scores you on the same handful of attributes, which Google has described publicly in broad terms: general cognitive ability (how you reason through a problem), role-related knowledge (can you code and design at the level), leadership (do you take charge of ambiguity, with or without a title), and Googleyness (how you work with others). The weighting shifts by round. A coding interviewer writes mostly about cognitive ability and coding; the behavioral interviewer writes mostly about leadership and Googleyness. The packet that reaches the committee is the sum of those notes, each with a score and a rationale.

Two things follow. First, consistency across rounds matters more than one brilliant round, because the committee is looking for a pattern. Second, every round is partly a communication test, since the only thing that reaches the committee is what your interviewer managed to write down.

Coding rounds

Google coding questions are algorithm-and-data-structure problems pitched at "medium to hard", with a heavy emphasis on how you get there:

Expect follow-ups. The first solution is the entry ticket; interviewers escalate constraints ("now the input doesn't fit in memory", "now make it concurrent") to find your ceiling.
Complexity is not optional. State time and space costs unprompted, and know why your structure choice beats the alternatives.
Code quality counts. Working beats elegant, but naming, decomposition and edge-case handling are all in the rubric.
Test before "done". Walk your code against a normal case, an edge case, and an empty or degenerate case out loud.
Clarify first. Input size, value ranges, duplicates, sorted or not, what to return on bad input. Thirty seconds of questions prevents ten minutes of solving the wrong problem.

A strong 45 minutes usually splits into roughly five minutes of clarifying, ten of designing the approach out loud, twenty of writing code, and ten of testing and follow-ups. If you are still designing at the twenty-minute mark, say so and propose a simpler version you can finish. A complete brute-force solution with a stated path to the optimal one reads better in the packet than an unfinished clever one.

Preparation that works: depth over volume. A few hundred problems skimmed teaches less than fifty problems where you can explain every trade-off, re-derive the solution cold, and code it cleanly in your language of choice in under 25 minutes. Practice without autocomplete and without running the code, because that is close to the conditions in the room.

System design

For L5 and above, one round covers designing a real system at scale. The bar is the reasoning, not the boxes: requirements and numbers first, then an architecture you can defend under "why not X?" pressure. Interviewers typically want to see you scope the problem, estimate load, define the data model and the main APIs, pick storage and caching deliberately, and talk through failure modes and how the design evolves when traffic grows tenfold.

At L6 the expectation shifts from answering well to driving the conversation: you choose where to go deep, you name the trade-off you are rejecting and why, and you can discuss operational concerns (rollouts, monitoring, data migration) without being prompted.

Our system design framework covers the method, and the case studies (WhatsApp, Uber, Netflix) are the practice reps. If the fundamentals are shaky, start with the prerequisites.

Googleyness and Leadership

The behavioral round looks for comfort with ambiguity, intellectual humility, collaboration, and leading without authority, evidenced by real stories, not adjectives. Structure answers with the STAR method and build a story bank before the loop: conflict, failure, ambiguity, mentorship, disagreement-then-commitment.

Google's flavor rewards showing your update (the moment you changed your mind for a good reason) more than Amazon's does. A story where you were right all along is weaker here than a story where you were partly wrong, noticed, and changed course in the open. Interviewers also listen for how you treat people with less power than you: interns, new joiners, a partner team that depends on you.

The questions you will actually get

Coding problems are not shared in advance and change often, but the archetypes are stable. Expect problems in these families:

Running statistics over a stream (median, top-k, sliding window maximum), which test heaps and deques.
A cache or rate limiter with constant-time operations, which tests hash maps combined with linked structures.
Shortest path or reachability on a grid or an implicit graph, followed by "the grid does not fit in memory".
Interval merging and scheduling, which test sorting plus careful edge handling.
Tree serialization, lowest common ancestor and path problems, which test recursion you can write cleanly.
String parsing with a twist (expression evaluation, decoding), which tests stacks and state machines.

Googleyness and Leadership questions sound like these:

Tell me about a time you had to make progress with incomplete information.
Describe a technical decision you disagreed with. What did you do, and how did it end?
Tell me about a project that failed. What changed in how you work afterwards?
Tell me about a time you helped someone else succeed when it was not your job.
How did you handle a teammate who was not pulling their weight?
Tell me about a time someone changed your mind.

Expect follow-ups on your personal role. "What did you do, specifically?" separates your contribution from your team's, and an answer full of "we" reads as inflated scope in the packet.

How levels change the bar

Google offers are level-bound (L3 new grad, L4 industry, L5 senior, L6 staff), and the loop calibrates against the target level. The coding problems look similar across levels; what changes is the expected speed, cleanliness, and the depth of follow-ups you are expected to handle. System design appears at L5 and carries more weight at L6. In the behavioral round, scope is the signal: L4 evidence is owning your own work well, L5 evidence is owning a project and influencing a team, L6 evidence is setting direction that other teams followed.

Two implications: push the recruiter early on which level you are being assessed for, and know that level, not negotiation within the band, is the biggest compensation lever. Downlevel offers happen when the packet is strong but the scope evidence is thin, so choose stories whose blast radius matches the level you want. See our salary negotiation playbook for how to handle the offer once it lands, and the staff engineer interview guide if you are targeting L6.

A preparation plan

8 to 10 weeks out. Pick one language; rebuild fundamentals (arrays and strings, hash maps, trees, graphs, heaps, dynamic programming). Quality reps, spaced repetition on the ones you miss.
4 to 6 weeks out. Timed mocks: 45 minutes, talking aloud, no IDE autocomplete. Add system design reps if L5 or above.
2 weeks out. Story bank polished into STAR form; two mock behavioral rounds; redo every problem you previously failed.
Throughout. Practice narrating. The committee reads what interviewers heard, and interviewers can only write down what you said out loud.

If you only have four weeks, keep the same order and cut volume, not stages: twenty problems you fully own, three timed mocks, one design rep a week, and a story bank of six stories rather than ten. A mock interview with someone who has sat on a Google panel is the fastest way to find out which stage is weakest.

Common mistakes

Thinking in silence. The interviewer cannot write down what you did not say.
Coding before clarifying, then solving a different problem from the one asked.
Skipping complexity analysis until asked, which reads as not knowing it.
Declaring "done" without testing, and letting the interviewer find the off-by-one.
Answering behavioral questions with adjectives ("I'm very collaborative") instead of a story with a result.
Treating level as the recruiter's problem. It is your problem, and it is decided before the offer.
Treating team matching as a formality. A weak match conversation can stall an approved packet for weeks.

Related guides

The Googleyness and Leadership interview guide goes deeper on that round, with questions and a sample answer. If Google is one of several loops, the Amazon software engineer interview guide covers the contrasting behavioral-heavy process, the engineering manager interview guide covers the management track, and handling competing offers covers what to do when more than one lands at once.

Want calibrated practice? Get matched with a coach who has interviewed at Google, then rehearse with the STAR guide and a mock interview.