Google — Interview Playbook (Senior SWE / L5+ orientation)

This is framework and public-signal guidance, not insider knowledge. Real loops vary by role, product area, and level.

Typical loop structure (conceptual)

• Phone or recruiter screen: resume, basic fit, sometimes a short technical screen.
• Onsite (or virtual equivalent): multiple rounds, often mixing coding, system design (for appropriate levels), and behavioral / leadership signals. ML or specialized roles add domain rounds.
• Hiring committee style decision: packet quality across rounds matters; weak coding rarely offsets weak design at senior levels, and vice versa.

Confirm your exact schedule with your recruiter.

What interviewers tend to optimize for

Coding

• Correctness and proof: clear invariant reasoning, handling edge cases, testing mentally or with small examples.
• Complexity clarity: state time and space; compare alternatives when the problem has multiple approaches.
• Communication: think aloud; incorporate hints without defensiveness.
• Depth: follow-ups that extend the problem (variants, streaming, large inputs) are common; partial credit comes from structured thinking.

System design (where applicable)

• Clarity of requirements and explicit tradeoffs (latency, consistency, cost, operability).
• Familiar building blocks used for a reason, not a laundry list.
• Failure modes and evolution: backpressure, partial failures, rollouts, and how the design matures from a focused v1.

Behavioral / Googleyness (label varies)

• Collaboration, intellectual honesty, handling ambiguity, and impact at scale—map your real stories to those signals (see Behavioral STAR guide).

System design bar (short)

You are expected to drive the discussion: requirements, API shape, data model, read/write paths, scaling levers, and how you would validate the design. Senior candidates should show judgment when the problem is under-specified.

Use the repo’s structured walkthrough as a personal checklist: System design interview framework (RESHADED)

“Don’t” list (common pitfalls)

• Vague scaling without any order-of-magnitude or concrete reasoning (QPS, payload size, fan-out). You do not need perfect numbers; you need defensible ballparks and what would change the answer.
• Name-dropping technologies with no connection to the problem’s constraints.
• Monologue: not pausing for questions or constraints; not treating the session as a collaboration.
• Hiding uncertainty: better to label assumptions explicitly than to fake precision.

Preparation alignment with this repo

• Coding: follow the roadmap topics; emphasize graph, DP, and string / interval patterns that support follow-up depth.
• Design: practice one end-to-end design per session with time limits; end each session with “what I’d verify next” (load test, dark launch, SLO).
• Behavioral: prepare stories with measurable or clearly described impact; avoid exaggeration.

Day-before mindset

• Sleep and a light review beat cramming new patterns.
• For each round type, have one opening sentence for how you structure the session (e.g., “I’ll clarify constraints, then outline approaches, then pick one and implement with tests in mind”).

Coding follow-ups you should rehearse

Interviewers often stretch the same core problem. Practice recognizing these pivots without panic:

• Input scale: streaming input, disk-backed iteration, or “too large for memory” with external sort / merge style thinking when appropriate.
• Mutability: immutable structures, functional alternatives, or copy cost when the problem changes.
• Correctness under concurrency: when the prompt introduces threads or parallel readers—state consistency model assumptions explicitly or ask what is guaranteed.
• Optimization: can you beat naive time with a better structure (heap, tree map, prefix structure)? Name preprocessing budget vs query budget.

If stuck, reduce scope: solve the smaller version correctly, then say what you would add next.

System design: collaboration signals

Google design interviews reward interactive problem shaping:

• Offer two candidate architectures when tradeoffs diverge (e.g., push vs pull for notifications), compare briefly, then commit for depth.
• Ask one clarifying question at a time; incorporate answers before drawing more boxes.
• End with validation: load testing plan, shadow traffic, or staged rollout—pick what fits the domain.

Structured checklist: System design interview framework (RESHADED)

Hiring packet mindset (conceptual)

Feedback is often synthesized across rounds. Weakness in one area can be mitigated by strength elsewhere, but two weak coding rounds or shallow design is hard to recover in many loops. Behave as if every round is independently scored: bring fresh energy and structure each time.

Level calibration (rough)

• Mid-level: solid implementation, clean complexity, good edge-case hygiene.
• Senior: tradeoff narration, extension handling, design ownership with explicit assumptions.
• Staff+: multi-team constraints, long-horizon evolution, organizational alignment—when the loop includes those signals.

Match prep depth to the job level on your requisition; ask your recruiter if unsure.

Note on materials

Internal guides and leaked questions change and may violate terms of service. Prefer public curricula, this repo’s roadmap, and past problems you can discuss ethically.