Google software engineer interview preparation

A human recruiter triages your application against open roles — Google has no keyword ATS to game. Level calibration starts here: your scope of ownership on the resume sets the L3/L4/L5 hypothesis the loop will test.

Where people get stuck: Most candidates never get past this stage. A resume built around responsibilities instead of scope reads as junior regardless of years.

Background, motivation, level targeting, logistics, and which org is hiring. No coding. This is where you learn whether team matching happens before or after the hiring committee for your loop — ask directly.

Where people get stuck: Targeting the wrong level. Borderline L4/L5 candidates should target L5: the committee down-levels far more readily than it up-levels.

Live coding in a shared editor — historically Google Docs, increasingly an internal platform with syntax highlighting but no autocomplete and no run button. One to two data-structure problems at onsite-level difficulty.

Where people get stuck: Coding without execution. Candidates who rely on running code to find bugs collapse here; dry-run your code on paper before calling it done.

Two or three coding rounds, one system design round at senior levels, one Googleyness behavioral round. Each interviewer is a different Googler who was not involved in earlier stages.

Where people get stuck: Follow-up depth on the second coding problem, and treating the behavioral round as a formality. Both produce real rejections.

Four to five senior Googlers from unrelated teams review the written packet — feedback, scores, resume — and vote hire or no-hire, including level. They never met you, so thin interviewer write-ups hurt more than thin answers.

Where people get stuck: Mixed scores with no strong hire, or a packet with strong coding but no evidence of scope. The committee can request one or two extra interviews.

Approved candidates meet hiring managers with open headcount in short conversations until one claims them. Approval is commonly reported valid for around a year, but recruiter attention drops off after roughly eight unmatched weeks.

Where people get stuck: No team bites — candidates call it hired but homeless. Treat match calls as interviews, stay flexible on product, and keep momentum between calls.

A compensation committee sets the package against your level, not your previous salary. Level drives comp far more than the company name — the gap between adjacent levels is commonly six figures a year in total comp.

Where people get stuck: Accepting the first number. Google expects negotiation and responds to competing offers; anchor with market data for your level.

Two DSA problems you have seen the shape of before. Arrays, hashmaps, strings, basic trees. The bar is correct code with clear reasoning, not exotic algorithms.

Still two problems, but at least one is unfamiliar. Dynamic programming, graph traversal and heap trade-offs start appearing. You are expected to ask clarifying questions before coding.

One hard problem plus depth. Partition search, amortised-cost arguments, and being able to defend why your approach is optimal rather than merely working.

Two pointers, sliding window, prefix sums. Two Sum, 3Sum, longest substring without repeats, subarray sum equals K.

BFS/DFS, topological sort, union-find. Number of Islands, Course Schedule, Clone Graph, Word Ladder. Reported in roughly three of four onsite loops at L4+.

State definition first, then bottom-up vs top-down. Word Break, Coin Change, longest increasing subsequence. Fewer questions, but each one eats 20+ minutes.

LRU Cache, Tries, autocomplete. These are data-structure design questions scored on clean code and trade-off discussion, not cleverness.

Rotated arrays, search on the answer, median of two sorted arrays. The classic "unfamiliar second problem" at senior loops.

Approach: One pass with a hashmap from value to index. Before the complement lookup, check whether the value already seen is the complement — that ordering is the whole trick and is what interviewers listen for.

Complexity: O(n) time, O(n) space. Say "n is the length of the input array" once, then move on.

Follow-up: Ask what happens if the array has duplicates, then what if you needed all unique pairs. The second turns it into a counting problem, and the hashmap answers it in one pass.

Approach: Prefix sums plus a hashmap of previously seen prefix frequencies. The non-obvious part is that the map holds counts rather than presence, which is what makes duplicates correct.

Complexity: O(n) time, O(n) space.

Follow-up: Ask about all-negative input, then about the longest subarray summing to k. The second is a different problem and the honest answer is that you would keep a parallel map of earliest indices.

Approach: Sliding window with a last-seen index map. State the window invariant before coding: the window is always valid, and you only move the left boundary forward.

Complexity: O(n) time, O(k) space where k is the alphabet size.

Follow-up: Ask for the longest substring with at most k distinct characters — generalise the condition — then for the substring itself rather than its length. The invariant you just stated is the whole answer to both.

Approach: Two viable routes: a size-k heap, or bucketing by frequency to stay O(n). Naming both and picking the one that matches the constraints you were given is the signal, not the code.

Complexity: Heap route is O(n log k). Bucketing is O(n). Say which one you are writing and why.

Follow-up: Ask what happens when k approaches n, and then how this differs from finding the k most common words across a large corpus, which is where a trie or a distributed count starts to matter.

Approach: Hashmap plus doubly linked list, O(1) get and put. The thing being tested is whether you reach for it unprompted — this question is usually a disguised design question.

Complexity: O(1) average for both operations.

Follow-up: Ask about thread safety, then about what you would change at scale: sharding the cache, or LFU versus LRU under a skewed distribution. Most candidates can implement it; far fewer can talk about when it stops being the right structure.

Approach: Topological sort over a prerequisite graph, with in-degree counting and a queue. Frame it as a dependency ordering problem before naming the algorithm.

Complexity: O(V + E) time and space.

Follow-up: Ask what happens with a cycle, then ask for the ordering itself rather than whether one exists. The cycle case is the common follow-up and the ordering case is what separates a strong hire from a hire.

Approach: A size-k heap holding the current head of each list. The trade-off worth naming: heap is O(N log k) with k lists, repeated pairwise merge is O(kN) but with no auxiliary structure.

Complexity: O(N log k) time, O(k) space.

Follow-up: Ask to return just the k smallest elements rather than a full merge. That reframes it as a partial selection problem, and noticing the reframing without being told is the point of the follow-up.

Approach: Sort, then two pointers with a single skip rule when duplicates produce the same triple. Sorting first is not optional — say why before coding it.

Complexity: O(n²) time after an O(n log n) sort, O(1) auxiliary beyond the sort.

Follow-up: Ask about 4Sum. The answer is the same structure one level up, and saying so unprompted is what the question is looking for.

What does the system do, who uses it, what are the read and write paths, and what is the scale? Get on the board an agreed scope before anything else. This is the phase interviewers are scoring hardest, and it is the one candidates skip.

Components and their responsibilities, with the data flow between them. Cover the main tiers — clients, API layer, service or two, storage, cache, and the async path — before going deep on any of them. Breadth first, because depth without breadth reads as tunnel vision.

Go one or two levels down on two areas you choose. Scaling the read path, the write path, and the storage model are the usual picks. For each, state the requirement, what is hard about it, the options, and the trade-off — then defend the choice against the alternatives.

Name the bottleneck you expect first, what you would monitor, and how the design degrades under a spike. Finishing by volunteering the weaknesses of your own design is one of the cheapest signals you can send.

The single most common failure, and the easiest to fix. An interviewer cannot score reasoning they cannot hear. Narrate the requirement, the approach, the complexity and the edge cases as you work, before you type.

Drawing boxes in the first two minutes reads as skipping the interview. Ask what the system must do, who uses it, and what the scale is before proposing anything. That scoping is the part being scored.

Writing a clever solution before confirming you understood the problem is the most expensive habit on this list. Get a correct, simple solution first, then improve it in the open. You are not timed on elegance.

"We would use Kafka" is not a design decision. Say what the requirement is, what is hard about it, and what the options trade off. Naming the tool last, if at all, is what reads as senior.

Interviewers add constraints deliberately, to see how you adapt. Modify in place and explain what changed. Starting over reads as panic.

Saying "this is O(n)" is a claim. Say what the input size is and what the bound is relative to, once, as you go. It takes seconds and it is the difference between a code sample and an engineering sample.

A slightly slower solution that you can explain beats an optimal one you cannot. If you are out of time, spend it verbalising what the solution does rather than micro-optimising.

Hashmaps, two pointers, sliding window, trees, heaps. Drill until you recognise the pattern in under two minutes — pattern recognition is the actual skill being tested, and it only comes from volume at medium difficulty.

BFS/DFS, topological sort, union-find; then DP state definition with bottom-up and top-down. These are the second-problem topics that decide levels. Time every session at 45 minutes with no run button.

Run the 45-minute design structure end to end on five familiar products. In parallel, write out 8–10 STAR stories covering conflict, ambiguity, leadership without authority, failure, and data-driven decisions — with numbers in every result.

Timed mock interviews back-to-back, including one full day if you can. Narrate everything out loud, confirm your format with the recruiter (virtual vs in-person, standard vs the Gemini-assisted pilot), and rest the day before.