Primary 12-Week Plan
Prepare for strong L4 coding performance while developing L5-level design and leadership evidence. Use Python for DSA, and plan around 18 hours per week. Your backend experience gives you relevant design material; the preparation challenge is making your reasoning, ownership, and judgment visible under interview time pressure.
I’ll use a senior-interviewer coaching lens. The level distinctions and readiness targets below are practical preparation guidance, not Google’s confidential scoring rubric.
1. Level calibration and interview expectations#
Five years of experience makes L5 worth discussing with your recruiter, but years alone do not establish senior-level scope. Google’s public Senior SWE postings include examples requiring five years of development experience alongside design and product-delivery experience. That establishes eligibility for those postings, not an interview-level guarantee. Google Senior SWE posting
For planning purposes, prepare for the following structure. Exact rounds vary by role, location, and recruiting process.
| Component | Preparation assumption | What to demonstrate |
|---|---|---|
| Recruiter conversation | Level, role fit, background, logistics | Clear account of your scope and interests |
| Technical screening, if still required | One or more coding assessments/interviews | Problem solving, implementation, complexity, communication |
| Main-loop coding | Budget for approximately 3 coding interviews | Consistent performance on unfamiliar problems and follow-ups |
| System design | Prepare for a dedicated round for L5; confirm whether included for L4 | Requirements, architecture, data modeling, tradeoffs, failure handling |
| Googleyness and leadership | Prepare for a dedicated behavioral interview or questions integrated into other rounds | Collaboration, judgment, ownership, learning |
Use 45-minute practice rounds, adjusting to your confirmed schedule. Do not assume that every L4 interview omits design or that behavioral evaluation always has a separate slot.
Your first recruiter clarification should cover: target level, round types and durations, coding language/runtime, whether code can execute, and the design tool. Google provides a Google Drawings guide for some virtual design interviews, but your invitation should determine your setup. Google candidate guide
The useful L4/L5 distinction is the scope of problems you can independently own:
| Dimension | Strong L4 evidence | Strong L5 evidence |
|---|---|---|
| Coding | Independently develops, implements, and tests an efficient solution | Equally strong fundamentals; handles ambiguity and changing constraints with clear judgment |
| Design | Designs a coherent service or component and explains its choices | Drives an ambiguous system design, identifies the hardest constraints, and explores consequences deeply |
| Ownership | Delivers substantial work within an established direction | Helps define direction and carries a project through delivery and operation |
| Collaboration | Works effectively with peers and partner teams | Resolves cross-team dependencies and influences decisions without formal authority |
| Leadership | Supports teammates and improves execution | Raises others’ effectiveness through mentoring, standards, or technical direction |
| Impact | Explains what they built and why it mattered | Connects decisions to outcomes, alternatives, and broader team effects |
My calibration recommendation: pursue L5 if you can substantiate at least two projects where you shaped the design, coordinated contributors or partner teams, and owned operational results. Otherwise, L4 may fit your demonstrated scope better. Do not treat L5 preparation as simply solving harder algorithms.
Choose Python for DSA. You already use it professionally, and its concise syntax should preserve time for reasoning and testing.
| Consideration | Python | Java |
|---|---|---|
| Implementation speed | Concise maps, sets, loops, and sorting | More typing and type declarations |
| Useful standard tools | deque, Counter, defaultdict, heapq, bisect | ArrayDeque, HashMap, HashSet, PriorityQueue, TreeMap |
| Main risks | Hidden copying, recursion depth, aliasing, heap tie comparisons | Comparator bugs, integer overflow, verbosity |
| Best reason to choose it | You can think and implement fluently | Your actual algorithmic fluency is materially stronger |
During week one, solve two comparable unfamiliar problems in each language. Compare correctness, completion time, and debugging effort; then lock your choice for the remaining weeks.
For Python, practise queue operations with deque, heap operations, sorting keys, and explicit iterative traversals. Know which operations copy data or cost linear time. Confirm runtime support before relying on newer library APIs. Python collections, Python heap documentation
2. Your 12-week roadmap#
The baseline is 208 preparation hours: 18 hours in weeks 1–11 and a 10-hour taper in week 12.
| Phase | Coding/week | Design/week | Behavioral/week | Tracking/logistics | Total |
|---|---|---|---|---|---|
| Weeks 1–4: foundations and patterns | 11 h | 4 h | 2 h | 1 h | 18 h |
| Weeks 5–8: advanced reasoning and design | 9 h | 6 h | 2 h | 1 h | 18 h |
| Weeks 9–11: interviews and repair | 9 h | 5 h | 3 h | 1 h | 18 h |
| Week 12: taper | 4 h | 3 h | 2 h | 1 h | 10 h |
Mocks and their debriefs are included in the relevant category. Reading also comes out of that category’s budget.
Target 80 distinct Medium/Hard problems, plus 40–50 selected re-solves. These are workload guides; the milestones determine progress.
| Week | Coding goals | Design and behavioral goals | Completion milestone |
|---|---|---|---|
| 1 | 8 new: baseline assessments; arrays, hashing, two pointers; language comparison | Explain one actual backend service end to end. Inventory 8 potential stories. Confirm interview format. | Baseline scorecard, chosen language, and three specific weaknesses |
| 2 | 8 new: sliding windows, prefix sums, binary search, intervals | APIs, access patterns, indexes, transactions, rough capacity estimates. Draft ambiguity and disagreement stories. | Explain the invariant behind each pattern; justify one schema and index choice |
| 3 | 8 new: trees, BSTs, recursion, BFS/DFS, basic backtracking | Caching, replication, consistency. Reconstruct one production incident and its recovery. | Implement tree and graph traversals from blank; distinguish a cache failure from a database failure |
| 4 | 8 new: graphs, heaps, mixed review; 1 coding mock | First complete design: rate limiter. Prepare four STAR stories. | Solve 3 of 4 fresh, representative Mediums within 40 minutes each, including testing |
| 5 | 8 new: topological sort, union-find, shortest paths | Sharding, hot partitions, rebalancing, consistent hashing. Design a crawler. | Explain when to use BFS, Dijkstra, topological sort, or union-find |
| 6 | 8 new: 1D/2D DP, subsequences, knapsack-style state choices; 1 coding mock | Queues, retries, idempotency, backpressure. Design an event analytics pipeline. Draft failure and pushback stories. | Derive DP state, recurrence, and base cases before coding; explain duplicate-event handling |
| 7 | 8 new: tries, pruning, monotonic stacks, harder intervals | Design autocomplete; 1 design mock. Practise an LLD component. Draft mentorship story. | Produce a complete 45-minute design with one substantial technical deep dive |
| 8 | 8 new: mixed graph/DP problems; 1 coding + 1 design mock | Design file storage/sync. Review isolation, failover, concurrency. Complete eight story cards. | Meet the phase-two readiness gate below |
| 9 | 6 new: unfamiliar mixed problems; 1 coding mock | 1 behavioral mock. Revisit weakest design and rehearse two project deep dives. | Handle follow-up questions without reverting to a memorized explanation |
| 10 | 6 new: target the two weakest patterns; 2 coding mocks | 1 design mock; rehearse disagreements, tradeoffs, and quantified outcomes | Complete a three-round practice block with breaks, then identify only the top two repairs |
| 11 | 4 new: transfer exercises from recurring mistakes; 2 coding mocks | 1 design + 1 behavioral mock; simulate the confirmed loop as closely as practical | Meet the final readiness gate; finish major remediation |
| 12 | No new problems required: familiar representative problems and light recall | Two short design walkthroughs, story refresh, equipment check, sleep consistency | Enter the interview rested, with a repeatable process |
That gives you 8 coding, 4 design, and 2 behavioral mocks. Most can be with a capable peer; use experienced external interviewers for calibration where practical.
Phase-two gate, end of week eight:#
- Solve at least 4 of 5 fresh, representative Mediums within 35–40 minutes without substantive hints.
- Explain correctness and complexity, including auxiliary space.
- Complete two coherent designs with explicit data models, failure handling, and justified tradeoffs.
- Tell eight truthful stories without reading a script.
Final readiness gate, end of week eleven:#
- Across your last five coding mocks, at least four show a sound approach, implementation, and testing with no major rescue.
- Your last two design mocks reach both an end-to-end architecture and a meaningful deep dive.
- Behavioral answers clearly distinguish your decisions from the team’s work and withstand probing.
These are coaching targets, not Google pass thresholds.
If you miss a gate, replace the next week’s new problems with focused repair. Do not respond by adding hours indiscriminately.
A sustainable 18-hour weekly template for the first phase:
| Day | Session |
|---|---|
| Monday, 2 h | 90 min coding; 30 min retrieval practice |
| Tuesday, 2 h | 60 min coding; 60 min design |
| Wednesday, 2 h | 90 min coding; 30 min behavioral |
| Thursday, 2 h | 60 min coding; 60 min design |
| Friday, 2 h | 60 min coding; 30 min behavioral; 30 min tracking |
| Saturday, 4 h | 3 h coding/mock and debrief; 1 h design |
| Sunday, 4 h | 90 min coding review; 1 h design; 1 h behavioral; 30 min planning |
In phase two, transfer two coding hours to design. In phase three, transfer one design hour to behavioral practice.
On 15-hour weeks, remove three hours of new-problem work while preserving mocks and review. On 20-hour weeks, spend the extra two hours repairing a measured weakness.
3. DSA: prepare by reasoning pattern#
There is no reliable public Google question-frequency distribution. The allocation below is my preparation weighting: substantial graphs and DP, with enough breadth to avoid major gaps. Google-authored preparation material emphasizes conceptual understanding, algorithm selection, graphs, and complexity. The linked guide is older, so use it for fundamentals rather than current interview logistics. Google SWE preparation guide
| Pattern family | Distinct problems | What you should be able to explain |
|---|---|---|
| Arrays, hashing, two pointers, sliding windows, prefix sums | 12 | What information the maintained state summarizes |
| Trees and BSTs | 8 | What each recursive call returns; traversal and ancestor relationships |
| Graph BFS/DFS and shortest paths | 12 | How to model the graph; what “visited” means; why the traversal is valid |
| Topological sort and union-find | 8 | Dependency ordering versus connectivity; cycle handling |
| Dynamic programming | 14 | State sufficiency, recurrence, base cases, evaluation order |
| Binary search and heaps | 10 | Monotone predicates, search boundaries, top-k and merge invariants |
| Intervals, greedy methods, sweep lines | 6 | Endpoint conventions and why a local decision is safe |
| Tries and backtracking | 6 | Prefix representation, pruning, restoring state |
| Linked lists, stacks, queues, basic bit manipulation | 4 | Pointer/state discipline and boundary conditions |
| Total | 80 |
Use an 80% Medium / 20% Hard mix: 64 Mediums and 16 Hards.
- Weeks 1–4: 28 Medium, 4 Hard.
- Weeks 5–8: 24 Medium, 8 Hard.
- Weeks 9–11: 12 Medium, 4 Hard.
Choose Hards that deepen reusable reasoning—such as minimum-window problems, word-ladder variants, tree serialization, or DP state design. Avoid making obscure tricks your primary study material.
For each problem, follow this learning cycle:
- Attempt independently: usually 30–40 minutes for a Medium; cap a Hard learning session around 60 minutes before seeking help.
- Locate the exact gap: modeling, invariant, algorithm choice, implementation, or testing.
- Study only what resolves that gap.
- Close the solution and reconstruct it.
- Revisit selected misses after roughly 2, 7, and 21 days. Prioritize consequential weaknesses rather than repeating everything.
- Change one constraint: weighted edges, streaming input, duplicates, limited memory, or dynamic updates.
Mark a solution as independent, hinted, or editorial-assisted. An accepted submission after reading the editorial is a learning event, not an independent solve.
For a typical 45-minute live coding round, practise this pacing:
| Time | Action |
|---|---|
| 0–4 min | Clarify input/output, constraints, duplicates, ordering, mutation, and one example |
| 4–8 min | State a baseline and its bottleneck; explain it without necessarily coding it |
| 8–13 min | Propose the improved approach, invariant, and complexity |
| 13–30 min | Implement readable code while explaining significant decisions |
| 30–38 min | Trace normal and adversarial cases; fix mistakes |
| 38–45 min | Address follow-ups, tradeoffs, or remaining discussion |
Adapt to the interviewer’s pacing; this is a rehearsal framework.
Useful language during the interview:
“The baseline repeats this work for every starting position. I can preserve that information in a map. The invariant is that…”
Test empty or minimum input, duplicates, boundaries, disconnected/cyclic cases where relevant, and one adversarial shape. If stuck, state the precise uncertainty and work a small example rather than going silent.
4. System design: turn your experience into evidence#
Your strongest preparation move is to reconstruct two real projects. For each, write one page covering requirements, traffic/data scale, architecture, your decisions, rejected alternatives, an operational problem, and measured results.
Use your database experience as follows:
| Technology | Interview value | Depth to prepare |
|---|---|---|
| PostgreSQL | Transactional source of truth; relational modeling and invariants | Composite indexes, query plans, isolation, locking, replica lag, pagination, migrations |
| Bigtable | High-throughput key/range access with deliberate key design | Row keys, hotspots, access-pattern tradeoffs, single-row atomicity, replication/routing choices |
| BigQuery | Analytical processing and separation of analytical workloads from serving | Partitioning, clustering, ingestion freshness, scan cost, aggregation, backfills |
For PostgreSQL, explain an actual concurrency scenario—such as two requests attempting the same reservation—and which database mechanism preserves correctness. Know that isolation levels permit different anomalies. PostgreSQL isolation documentation
For Bigtable, explain why a timestamp-leading row key can hotspot, and how spreading writes can increase read fan-out. Its transactions are scoped to a single row. Be precise about consistency: single-cluster and replicated routing configurations have different implications. Bigtable schema design, Bigtable replication
For BigQuery, explain why an analytical warehouse belongs in an event-analysis path, and evaluate latency requirements before placing it behind an interactive serving API. BigQuery overview
A particularly useful practice scenario is a transactional service whose events feed analytics: PostgreSQL stores business state, an outbox/CDC mechanism publishes changes, consumers handle duplicates and replay, and BigQuery supports analysis. Introduce Bigtable only when a concrete serving access pattern justifies it.
Master these distributed-system topics through scenarios:
- Scale: average/peak QPS, storage growth, bandwidth, concurrency, p95/p99 latency.
- Partitioning: range versus hash sharding, consistent hashing, hot keys, rebalancing.
- Replication: lag, leader failure, quorum intuition, read-your-writes.
- Consistency: linearizability versus serializability, eventual consistency, conflict handling; explain CAP specifically during a network partition.
- Caching: cache-aside, invalidation, TTLs, stampedes, eviction, hot objects.
- Asynchronous processing: ordering scope, at-least-once delivery, idempotency, retries with jitter, dead-letter handling, backpressure.
- Reliability: SLOs, timeouts, load shedding, disaster recovery, observability, safe rollouts.
- Concurrency and coordination: locks, leases, fencing tokens, races, deadlocks.
- API and data lifecycle: authentication, authorization, pagination, schema evolution, deletion and retention.
Practise these five canonical designs, each at least twice:
| Problem | Main learning objectives | Follow-up to rehearse |
|---|---|---|
| Distributed rate limiter | Token buckets, atomic updates, per-user/tenant state | Multi-region limits; fail-open versus fail-closed |
| Web crawler | Frontier queues, deduplication, scheduling, partitioning | Worker crashes, retries, per-host politeness |
| Event analytics platform | Durable ingestion, stream/batch paths, aggregation | Duplicate and late events; replay without corrupting results |
| Search autocomplete | Prefix retrieval, ranking, caching, offline builds | Hot prefixes, freshness, personalization |
| File storage and sync | Metadata versus blobs, chunking, versioning | Concurrent edits, resumable upload, permissions |
These are practice vehicles, not predictions of Google questions.
For LLD, reserve 30–45 minutes of your design budget weekly from week three. Practise a rate-limiter interface, bounded worker queue, or cache component. Cover API contracts, state transitions, concurrency, errors, and testability. Your Django/Spring experience should help, but avoid spending the session on framework wiring.
Use this 45-minute design structure:
5 min requirements → 5 min scale and APIs → 10 min data model and architecture → 15 min deep dive → 7 min failures/tradeoffs → 3 min recap.
For L5, practise choosing the deep dive yourself and explaining why it is the system’s main risk.
5. Googleyness and leadership: build eight reusable stories#
Prepare these five themes. They are useful coaching categories, not an official ranked list.
| Theme | Evidence to surface | Possible story from your background |
|---|---|---|
| Ambiguity | You clarified an uncertain goal and made progress with incomplete information | An underspecified backend capability or migration |
| Cross-functional disagreement | You understood competing incentives and reached a workable decision | Product freshness expectations versus pipeline cost |
| Constructive pushback | You challenged a proposal with evidence and offered an alternative | An unsafe deadline, unnecessary rewrite, or risky rollout |
| Failure and learning | You owned your contribution, recovered, and changed the system | Incident, incorrect estimate, or failed migration |
| Mentorship and team impact | You helped others become more effective independently | Onboarding, reviews, incident coaching, engineering standards |
Choose eight distinct episodes: two major deliveries, one ambiguity story, one disagreement, one pushback, one failure, one mentorship example, and one initiative beyond assigned work. Stories can cover several themes, but avoid answering every question with the same project.
Use STAR plus reflection:
- Situation, 20–30 seconds: context and stakes.
- Task, 15–20 seconds: your responsibility.
- Action, 60–90 seconds: your decisions, alternatives, and collaboration.
- Result, 20–30 seconds: outcome, with defensible metrics where available.
- Reflection, 15–20 seconds: what you would repeat or change.
Give a two- to three-minute initial answer, then leave room for probing.
Each story card should contain:
Theme | Stakes | My role | Alternatives | My actions | Result | Lesson | Likely follow-ups
Prepare for: “Why that option?”, “What did you personally do?”, “Who disagreed?”, “How did you measure impact?”, and “What would have happened without your intervention?”
Use approximate figures only when you can explain the estimate. Avoid inventing precision. For L5, especially highlight how your work improved other people’s decisions or execution.
6. Keep the resource stack small#
| Resource | How to use it |
|---|---|
| LeetCode Top Interview 150 | Source problems from the pattern allocation; you do not need to finish the entire list |
| Hello Interview: System Design in a Hurry | Learn a delivery structure, then attempt prompts before viewing walkthroughs |
| Designing Data-Intensive Applications | Read selectively on storage, replication, partitioning, transactions, and distributed-system failures |
| Google SRE books | Selected reading on SLOs, overload, monitoring, and incident response |
| IGotAnOffer mock interviews | Optional external calibration; choose someone with relevant SWE interviewing experience and request written feedback |
Use peers for most mocks. If paying for help, prioritize one early calibration session and one later validation session over accumulating more courses.
Finally, working code alone does not demonstrate the full interview skill set. These are the five failure modes I would actively coach against; they are not a published ranking of hiring-committee rejection reasons:
-
Solving the wrong problem. Unchecked assumptions produce correct code for different requirements.
Repair: restate the contract and verify a small example before committing. -
Making reasoning invisible. The interviewer sees code but cannot assess why the approach works.
Repair: explain the invariant, complexity, and decisive tradeoff. -
Showing brittle understanding. A memorized solution collapses under a small follow-up.
Repair: change constraints during practice and derive the modified approach. -
Skipping validation. The main example works, but boundaries, state transitions, or complexity claims fail scrutiny.
Repair: reserve explicit time for tracing and adversarial cases. -
Leaving the target-level evidence unclear. Good coding cannot establish ownership, architectural judgment, or collaborative leadership by itself.
Repair: prepare concrete design decisions and stories showing your individual contribution, alternatives, and outcomes.
Start this week: confirm the loop, complete the coding baseline, choose your language, reconstruct one production system, and list eight real stories. Your first checkpoint is evidence of where you need practice—not a problem-count streak.