L4 at Google is Software Engineer II — the rung where you're expected to own a feature end-to-end, not just complete tickets. It's the most common entry rung for industry hires with 2-5 years of experience, and it's the level where Google's interview loop transitions from "can you code" to "can we trust you with a small project." This guide walks the loop round-by-round, names what each round actually tests, and ends with a 4-week prep plan calibrated for someone who already passes mid-tier company coding rounds.
Most public guides to Google interviewing are either (a) too generic ("study LeetCode!") or (b) written about pre-2022 loops that no longer match what candidates see. The L4 loop changed materially in 2024 when Google made system design a standard L4 round and re-weighted the behavioral signal. This post reflects the current 2026 loop.
The L4 loop overview
The current L4 process has four stages. Numbers in brackets are average pass rates from candidates who shared their loop on Blind, Levels.fyi, and Reddit in 2025-2026 (these are self-reported so treat them as directional rather than precise):
- Recruiter screen — 30 minutes, verifies resume and current compensation. [~70% pass to phone screen]
- Phone screen — 45 minutes, 1 coding question on Google Docs (no IDE). [~45% pass to on-site]
- On-site loop — 4-5 rounds in one day (virtual or in-person):
- 2 coding rounds (45 min each)
- 1 system design round (45 min)
- 1 Googleyness & Leadership round (45 min)
- Sometimes a 5th tie-breaker round if the loop is mixed
- Hiring committee — you don't attend; your interviewers and a separate hiring committee review packets. Adds about 1-3 weeks. [~85% of recommended candidates clear the committee]
Hidden filter: the recruiter screen weighs your current compensation against what the team can offer. If your numbers come in 30%+ above the expected L4 band ($180-220k base + RSU for US tech hubs in 2026), some recruiters will quietly slow-walk your loop rather than reject you. If you sense this, ask directly: "Is my comp expectation within the L4 band for this team?"
Round 1: Phone screen coding (45 min)
What they test
The phone screen is a single coding problem from one of 5-6 canonical patterns: two pointers, sliding window, hash-table tricks, BFS/DFS on a small graph, intervals, or a heap problem. The question is usually a slight twist on a textbook problem — it's calibrated to confirm you can code fluently, not to test depth.
You'll be coding in Google Docs (no auto-complete, no syntax highlighting, no test runner). The interviewer can see what you type in real time. This is intentional — they want to watch your process, not just see the final answer.
What good looks like
- Clarify in 60 seconds. Restate the problem in your own words and confirm at least one edge case (empty input, negatives, duplicates) before writing anything.
- Talk through the approach before coding. Even if you've seen the problem, simulate "noticing the pattern" out loud. Interviewers grade on signal, and a silent candidate who instantly writes the optimal solution looks like memorization.
- Type carefully. Syntax errors in Docs cost real points. Use Python (lowest syntax overhead) unless the role requires a specific language.
- Run through one test case at the end by manually tracing variables. This catches off-by-one errors and signals quality.
Common phone-screen patterns at L4 in 2025-2026: longest substring without repeats, two-pointer dedupe, valid parentheses, merge intervals, top-K elements via heap, level-order traversal. Our 15 LeetCode Patterns guide covers all of these with templates.
Round 2 & 3: On-site coding rounds (45 min each)
What they test
These are the rounds candidates fail most often. The bar is higher than the phone screen in three ways:
- Problem difficulty is LeetCode medium to medium-hard. Expect: graph problems beyond simple BFS, trees with parent pointers, dynamic programming (1D or 2D), or string problems with two operations stacked (e.g., "longest substring with at most k distinct characters AND no repeating characters").
- Code quality is graded. Variable naming, function decomposition, early returns, edge case handling — all count. Working code with terrible style is a "lean-no-hire" at L4.
- Follow-up questions always come. Plan for 25 minutes of coding + 15 minutes of follow-ups in your time budgeting. Common follow-ups: "what if the input is streamed and doesn't fit in memory", "what if we want the k-th result instead of the optimal", "what if duplicates can appear", "what's the complexity, and can you do it in O(log n) space".
What good looks like
- Solve the main problem with optimal time complexity in 20-25 minutes.
- Have working code (not pseudo-code) you can trace through a test case.
- Engage the follow-up genuinely — don't say "I haven't seen that." Instead, "I haven't, let me think about it... if we changed the constraint to X, the bottleneck becomes Y, so we'd need to..."
- Handle one tricky edge case the interviewer doesn't bring up first (empty input, single element, all-negatives, all-duplicates).
Round 4: System design (45 min)
What they test
L4 system design is calibrated lower than L5. The interviewer is looking for sound reasoning, not novel architecture. Typical L4 prompts:
- "Design a URL shortener that handles 100M URLs per day"
- "Design a real-time chat application for 10 million users"
- "Design a rate limiter for an API"
- "Design a notification service (push + email + SMS)"
- "Design a movie ticket booking system"
These are intentionally familiar problems. At L4, Google is testing whether you can:
- Translate fuzzy requirements into a concrete capacity estimate
- Choose between 2-3 reasonable architectures and articulate the trade-off
- Identify the one or two failure modes that matter (the unsexy ones like idempotency, cache invalidation, write amplification)
- Stay calm when the interviewer pushes back on your first design
You're not being tested on knowledge of every Google paper. Cite one or two well-known patterns (consistent hashing, leader election, log-structured merge trees) where they're genuinely relevant, but the round is about reasoning, not vocabulary.
For the canonical patterns and trade-off tables, see our System Design Cheat Sheet.
Round 5: Googleyness & Leadership (45 min)
What they test
This round is misunderstood. It is not a "soft" round — failing it kills the loop just as surely as failing a coding round. But it's also not a panel grilling you on Googley platitudes. It's a structured conversation that mixes behavioral questions with hypotheticals. Typical questions:
- "Tell me about a time you disagreed with a teammate. How did you resolve it?"
- "What's an engineering decision you made that turned out wrong? What did you learn?"
- "You're asked to ship a feature you think is bad for users. What do you do?"
- "How do you handle being the only senior on a team of new-grads?"
- "How do you prioritize when product, design, and your tech lead all want something different?"
What they're scoring:
- Specificity. Vague answers like "I always try to communicate openly" get a hard fail. Use STAR+ structure with named projects, real stakes, and quantified outcomes.
- Self-awareness. Stories with a failure or mistake you owned are graded higher than perfect-hero stories. The interviewer is checking that you can be honest about your own limits.
- Ambiguity comfort. Google specifically looks for candidates who don't need to be told what to do. "I asked my manager what to prioritize" is a yellow flag at L4; "I prioritized X based on customer impact and ran the trade-off by my TL" is a green flag.
- Absence of red flags. Blaming previous teammates, complaining about previous management, dismissive comments about other engineering disciplines — instant downgrade.
For story templates and a worked example of STAR+, see our Amazon behavioral interview guide — the same framework works for Google's Googleyness round, just without the Leadership Principles framing.
The hiring committee — what you should know
Your interviewers each write a detailed packet (called "feedback") and a recommendation: Strong Hire, Hire, Lean Hire, Lean No-Hire, No-Hire, Strong No-Hire. These packets go to a hiring committee that includes 3-5 senior Google engineers who never met you.
The committee's job is to calibrate across interviewers and protect against unconscious bias. They read your packet, your interviewers' feedback, sometimes your resume, and decide: hire or no-hire at this level.
Two non-obvious things about the committee:
- Mixed packets favor no-hire. If you have 2 Strong Hires and 2 Lean No-Hires, you will almost certainly be no-hired. Google's culture is "high bar, ambiguity goes to no-hire." Consistency matters more than peak performance.
- One Strong No-Hire ends the loop. Doesn't matter how good your other rounds were — one interviewer flagging you as Strong No-Hire usually leads to rejection at committee.
A focused 4-week prep plan
This plan assumes you can already pass a mid-tier coding round (Series B startup, well-funded scaleup) and just need to lift your game to Google's bar. If you're rusty on data structures, double everything.
Week 1: Pattern audit and warm-up
- Read or re-read the 15 canonical patterns. Self-assess: which 5 can you implement from scratch in <3 min? Which 5 do you struggle on?
- Do 3 problems per day from your weak patterns. Force yourself to type in Google Docs (no IDE, no auto-complete) for at least 1 of the 3.
- Read 1 system design problem per day. Don't write anything — just read and form an opinion before checking the solution.
- Write rough drafts of 4-5 STAR stories from your career. One per day.
Week 2: Depth
- 3 LeetCode medium problems per day in Google Docs. Time-box to 25 minutes each. Whatever you can't solve in 25 min, study the solution, then re-solve from scratch the next day.
- 2 deep system design sessions this week (2 hours each). Pick one of: URL shortener, chat system, rate limiter. Write your design out in your own words and grade it against a reference.
- Verbally rehearse 2 of your STAR stories with a friend or with our interview copilot.
Week 3: Mock interviews
- Schedule 3 paid mock coding interviews with senior engineers (interviewing.io, Pramp, or via your network). Don't skip this. The feedback is worth 10x the cost.
- 1 mock system design interview. Have the interviewer push back on your design.
- 2 mock behavioral sessions with a peer who can grade for STAR specificity.
- Reduce LeetCode volume — 1-2 problems/day to stay sharp, not to learn new patterns.
Week 4: Tapering and recovery
- Reduce volume by 50%. The goal is to arrive sharp, not exhausted.
- Re-read your STAR stories every other day. Get them tight enough that you can deliver them in under 4 minutes each.
- 1 final mock per discipline (coding, system design, behavioral) 3-4 days before your loop.
- Two days before the loop: don't do new problems. Sleep 8 hours each of the last two nights.
- Day-of: eat protein, hydrate, walk before each round, treat the bathroom break between rounds as sacred. Most candidates lose 1-2 rounds purely to fatigue and cognitive load — small optimizations here have big payoff.
Common L4 failure modes (and how to avoid them)
| Failure mode | How it shows up | Fix |
|---|---|---|
| Memorization | You solve the problem in 5 minutes but can't explain the trade-offs or do follow-ups | Stop drilling problems. Drill variations of problems you already solved. |
| Silent thinking | Long pauses (10+ seconds) where the interviewer has no signal on your reasoning | Narrate even uncertainty: "I'm trying to decide between approach A and B" |
| Skipping clarification | You code the wrong problem because you assumed something the interviewer left ambiguous | First 60 seconds: restate the problem, ask 2-3 clarifying questions, confirm 1 edge case |
| System design overreach | You jump to "we'd use Spanner" without justifying why | Always lead with the requirement that demands the choice, then introduce the technology |
| STAR fluff | You talk for 6 minutes about the "S" and "T" and 30 seconds about the "A" | Time-box: 30 sec Situation, 30 sec Task, 2 min Action, 30 sec Result |
| Tool blindness | You don't know Python's collections, Java's TreeMap, or C++'s priority_queue off the top of your head | Spend 2 hours making a cheat sheet of every standard library data structure you might need |
Practice the Google L4 loop with AI feedback
CoPilot Interview gives you real-time AI assistance during practice runs and live interviews. Free for Windows and macOS.
Download freeFAQ
What's the difference between L3 and L4 at Google?
L3 is the new-grad rung; loops are slightly easier coding-wise but you're expected to learn fast. L4 is for industry hires with 2-5 years experience and is the lowest level where you're expected to own features end-to-end. The system design bar is meaningfully higher at L4, and behavioral signals carry more weight.
How many coding rounds are in an L4 loop?
Typically 2 coding rounds on-site, plus 1 in the phone screen, for a total of 3 coding exposures. Some teams swap one on-site coding round for an extra system design round depending on team composition.
Is system design always required at L4?
Yes since 2024 — Google made it a standard L4 round. Before then, it was optional and team-dependent. The bar is lower than L5 (you're expected to design a mid-scale system, not a planet-scale one).
What's the Googleyness round actually testing?
Collaboration signals, comfort with ambiguity, ability to make decisions without being told what to do, and absence of red flags. It's roughly a 45-minute structured conversation that mixes behavioral and hypothetical questions. It's a screening round — you can fail it independently of the technical rounds and the loop will reject.
How long should I prepare for Google L4?
If you can already pass mid-tier company coding rounds: 4-6 weeks of focused prep. If you're rusty on DSA fundamentals: 10-14 weeks. Don't try to cram in under 3 weeks — Google's coding problems reward pattern fluency that takes time to build.
What's the offer rate for L4 on-sites?
Roughly 20-30% of candidates who reach on-site receive an offer. The biggest filter is the coding rounds (about 50% of candidates fail one or both). The behavioral and system design rounds are usually pass/fail rather than gradient gatekeepers, but a hard fail in either kills the loop.