Google L4 Interview Prep ​
Read my intro — background, experience, and what I've worked on.
Role Context ​
L4 = Software Engineer II (SWE II / SWE III in India) at Google. Entry point for autonomous mid-level engineers (3-6 YOE). Maps to Meta E4, Amazon SDE II, Uber L5 (lower end). Your ~3 years at Pixis maps cleanly to L4.
Google is coding-dominant at L4. Hiring committees weigh coding heavily. System design is NOT typically asked at L4 unless the role is backend-heavy (Cloud, Ads, Search Infra, YouTube backend). Googleyness is one round — low-signal to pass, high-signal to fail.
Interview Loop ​
Typical loop: GHA → Recruiter Screen → 1 Phone Screen → Onsite (4 rounds) → Team Match → Hiring Committee.
Onsite has two common variants:
| Variant | Structure | When |
|---|---|---|
| A (most common) | 3 Coding + 1 Googleyness | Default L4 |
| B (backend-heavy) | 2 Coding + 1 System Design + 1 Googleyness | Cloud, Ads, Search Infra, YouTube backend, with scaling signal on resume |
Each round = 45 min. Google Doc environment (no syntax highlighting, no autocomplete, no execution). 2025-2026 update: expect at least one in-person coding round.
Prep Notes ​
Core ​
| File | Focus |
|---|---|
| 01-interview-loop | Round-by-round breakdown, HC process, rubric, rejection reasons |
| 02-coding-strategy | Google Doc environment, code cleanliness, complexity narration, test-writing |
| 03-backend-fundamentals | DB / caching / concurrency / messaging (for scoped HLD + coding follow-ups) |
| 04-behavioral-googleyness | STAR bank mapped to 6 Googleyness attributes |
DSA Problems (25) ​
Google's signature: graphs + DP + binary-search-on-answer + heap + trie + line sweep. 76% of L4 onsites include a graph problem; arrays/DP/graphs cover ~83% of problem space.
| # | Problem | Pattern |
|---|---|---|
| 10 | Two Sum variants (LC 1) | Hash map |
| 11 | Merge Intervals (LC 56) | Sort + merge |
| 12 | LRU Cache (LC 146) | HashMap + DLL |
| 13 | Longest Substring Without Repeating (LC 3) | Sliding window |
| 14 | Word Break I & II (LC 139/140) | DP + backtracking |
| 15 | Coin Change (LC 322) | DP |
| 16 | Trapping Rain Water (LC 42) | Two pointer / stack |
| 17 | Valid Parentheses (LC 20) | Stack |
| 18 | Container With Most Water (LC 11) | Two pointer |
| 19 | Binary Tree Max Path Sum (LC 124) | Tree DP |
| 20 | Longest Increasing Subsequence (LC 300) | DP / binary search |
| 21 | Number of Islands (LC 200) | Grid BFS/DFS |
| 22 | Median of Two Sorted Arrays (LC 4) | Binary search |
| 23 | Word Ladder (LC 127) | BFS |
| 24 | Meeting Rooms II (LC 253) | Heap / sweep |
| 25 | Longest Increasing Path in Matrix (LC 329) | DP + DFS memo |
| 26 | Stretchy Words (LC 809) | Two pointer |
| 27 | Robot Clean Room (LC 489) | DFS with backtracking |
| 28 | Lex Smallest Subsequence of K (LC 1673) | Monotonic stack |
| 29 | Longest String Chain (LC 1048) | DP |
| 30 | Decode String (LC 394) | Stack / recursion |
| 31 | Russian Doll Envelopes (LC 354) | LIS in 2D |
| 32 | Burst Balloons (LC 312) | Interval DP |
| 33 | Detect Squares (LC 2013) | HashMap |
| 34 | Car Fleet (LC 853) | Sort + stack |
LLD / OOP (4) ​
Google rarely has dedicated LLD rounds, but OOP quality is evaluated inside coding rounds. Practice these to internalize the refactoring instinct.
| # | Problem | Focus |
|---|---|---|
| 40 | Parking Lot with Billing | Strategy for billing per vehicle type |
| 41 | LRU + GetRandom Cache | InsertDeleteGetRandom + LRU combined |
| 42 | Chat Log Top-K Parser | File parser + heap |
| 43 | Decode String Class | OOP extensibility |
System Design — HLD (6) ​
Only asked in backend-heavy loops. Scoped L4 level — not planet-scale.
| # | Problem | Focus |
|---|---|---|
| 50 | URL Shortener with Analytics | Base62, sharding, caching, expiration |
| 51 | Rate Limiter for API Gateway | Token bucket / sliding window variants |
| 52 | Top-K Unique Searches | Count-min sketch / heap / batching |
| 53 | Search Autocomplete | Trie + freq + distributed index + ranking |
| 54 | Mini-Drive (File Storage) | Metadata service, chunking, resumable uploads |
| 55 | Basic Message Queue | Durability, retries, DLQ |
Revision Checklist ​
Before Phone Screen ​
- [ ] Practice in Google Docs (no syntax highlighting) to simulate environment
- [ ] Drill 30-40 Google-tagged LC problems, emphasis on graph + DP
- [ ] Write complexity analysis BEFORE coding, not after
Before Onsite Coding (R1-R3) ​
- [ ] Practice narrating trade-offs WHILE coding
- [ ] Handle corner cases proactively — Google grades heavily on thoroughness
- [ ] Prepare clean OOP refactors for any coding problem ("how would you extend this for X?")
- [ ] Target: 2 problems per round, both clean and complete
Before System Design (R4, if applicable) ​
- [ ] Master 8-step framework: requirements → API → components → data model → architecture → scaling → reliability → tradeoffs
- [ ] Do NOT over-engineer — L4 = scoped design for thousands to millions, not billions
- [ ] URL shortener, rate limiter, top-K streams, autocomplete, mini-Drive
Before Googleyness ​
- [ ] 4-5 STAR stories mapped to: ambiguity, feedback, challenge status quo, user-first, conscientiousness, team
- [ ] "I" not "we"; quantify outcomes
- [ ] Know what you'd do differently in past projects (growth mindset)
The Hiring Committee (HC) ​
- 4-5 engineers/EMs who did NOT interview you review your packet
- Rubric: 7-point scale (Strong No-Hire → Strong Hire)
- 4 dimensions scored 1-4: Algorithms, Coding, Communication, Problem-Solving
- Critical insight: 5× "Leaning Hire" often = No Hire. Need at least one strong advocate.
- Aim for ONE round where you clearly exceed expectations — that's your advocate.
Cross-References ​
| Topic | Where |
|---|---|
| Design Patterns | Paytm 02 |
| SOLID principles | Glomopay 03 |
| HLD fundamentals (CAP, sharding, caching) | Paytm 04 |
| Backend fundamentals (deeper) | Uber Backend Fundamentals |
| C++ interview reference | C++ Guide |
| Amazon LP behavioral (overlapping themes) | Amazon LP Part 1 |