Interview Experience

My Google L4 Interview Experience

A round-by-round account of my Google L4 software engineer loop, from recruiter screen to team match, ending in an offer.

My Google L4 Interview Experience

A round-by-round account of my Google L4 software engineer loop, from recruiter screen to team match, ending in an offer.

google
interview-prep
coding-interview
system-design
behavioral
ezb1981

By @ezb1981

March 23, 2026

·

Updated May 18, 2026

574 views

4

4.3 (15)

I applied to Google through a referral in early autumn and signed an L4 offer about ten weeks later. This is the round-by-round version, not the highlight reel. I am writing it down because every Google account I read before my loop felt either smug or too vague to act on.

Timeline

Week-by-week breakdown
  Week 0    Referral submitted, recruiter email two days later
  Week 1    Recruiter screen, 20 minutes
  Week 3    Phone screen, 45 minutes coding
  Week 6    Onsite, four interviews in one day
  Week 8    Hiring committee approval
  Week 10   Team match, offer signed

I had about three weeks between the recruiter screen and the phone screen, and another three between the phone screen and the onsite. That cadence is what made the loop survivable. I asked the recruiter for the extra time, twice, and both times they said yes without pushback.

The phone screen, sliding window in a shared Doc

One 45-minute coding round over a shared Google Doc. The interviewer was an L5 from an infra team. They opened with about five minutes of background, then went straight to the problem.

The question was a string-manipulation problem with a twist that made the obvious O(n^2) solution too slow on the follow-up. I wrote a working brute force in about eight minutes, called out the complexity myself, and then walked through a sliding-window refactor.

def longest_valid_window(s: str, k: int) -> int:
    # Longest substring with at most k distinct characters.
    counts = {}
    left = 0
    best = 0
    for right, ch in enumerate(s):
        counts[ch] = counts.get(ch, 0) + 1
        while len(counts) > k:
            counts[s[left]] -= 1
            if counts[s[left]] == 0:
                del counts[s[left]]
            left += 1
        best = max(best, right - left + 1)
    return best

I did not get clean code on the first pass. I had an off-by-one on the del branch and the interviewer let me run a small example mentally before pointing it out. We finished with about four minutes left, which I used to talk through edge cases (empty string, k larger than the alphabet, k of zero).

What I think tipped this round positive was naming the brute force and its complexity out loud before writing it. The interviewer told my recruiter that I had clear narration, which I now believe matters more than getting the optimal solution on the first try.

The four-round virtual onsite

Four back-to-back virtual rounds, 45 minutes each, with a 30-minute lunch in the middle. Two coding, one system design (light, since L4 is the bar for IC4), and one behavioral / Googleyness.

  • Coding 1: Tree problem with a non-obvious recursion shape. I solved it but spent too long on the base case.
  • Coding 2: Graph problem disguised as a simulation. I caught the graph framing in the second minute and that round felt like the strongest one.
  • System design (light): Design a URL shortener, but the interviewer pushed hard on the read path and on what happens when the cache is cold. I had not rehearsed the cold-cache failure mode and it showed.
  • Googleyness / behavioral: Three stories, each prompted by a generic question (a conflict, a project I would do differently, a time I changed my mind). I had four stories prepared and used the strongest three.

The coding rounds both ended with an extension question. In the loops I sat through, the extension was where the L4-versus-L3 calibration happened: the base solution was the gate, the extension was the lever.

What I Got Wrong

I under-prepared for the system design round. L4 is mostly coding, but Google's L4 design round is real and graded. I treated it as a freebie based on advice in random forum threads and walked in with no framework. Next time, even for an IC4 loop, I will spend at least two weeks on system design fundamentals (load balancing, caching layers, what a CDN actually does).

I also over-rehearsed the behavioral round. By the third practice run my answers sounded like a script. The interviewer noticed, in a polite way, and asked a follow-up that broke the rehearsed shape. Lesson: practice the structure (situation, action, what changed), not the words.

Outcome

Offer signed. The hiring committee approved on the first pass, and team match took two weeks because I was holding out for a team in a specific area. The recruiter told me, after I signed, that the system design round was the lowest of the four and that the behavioral and second coding round carried the loop.

A note on the team-match phase, since it is rarely covered honestly. After the hiring committee approves, you talk to managers from teams with open headcount. The first manager I spoke to was running an internal-tools team, which I declined politely, and the recruiter asked me to write down what I wanted instead so they could match better. I wrote: backend, infra-flavored, no front-end work, and a team that ships to external developers. The next two calls were both reasonable matches and I picked the one whose tech lead asked the sharpest questions in the call.

If you are prepping for an L4 loop right now, the thing I would actually change about my prep is to stop treating the design round as optional and to add one mock onsite where you get tired in the middle. Nothing trains you for round-three fatigue the way a real four-hour block does.