Google L3 Software Engineer Onsite: Behavioral, Design, and Three Coding Rounds

GoogleL3 Software Engineer·Not specified·Interviewed October 2019Offer

Updated July 17, 2026

This account comes from a candidate who completed a Google onsite loop and received an offer, though at a level below the one they were targeting. The loop consisted of five rounds in a single day: a behavioral round, a system design round focused on Android architecture, a lunch break, and three separate coding rounds.

The candidate later reflected that fatigue set in partway through the day, which they felt affected their performance in one of the coding rounds more than the others. They also shared the preparation routine that led up to the interview, along with their own guesses about why the offer came in at a lower level than expected.

How the process went

Behavioral round
Opened the loop with a behavioral interview covering team leadership and how the candidate handles pressure and setbacks.
System design round
A domain-focused design discussion centered on an existing Android chat application, where the candidate was asked to critique and improve the architecture.
Lunch break
A break between the design round and the three coding rounds; the candidate described feeling unusually tired during this window.
Three coding rounds
Three separate 30-minute technical interviews, each with its own interviewer and problem set.
Outcome
The candidate received an offer, but at L3 rather than the L4 level they had been targeting.

Behavioral round

Team leadership, incident response, and personal resilience

How would you handle organizing a team building event for your team?
If you planned to ship a product and did a full demo right before the shipment, but then found a crash just hours before, how would you handle it?
Describe one of the hardest challenges you've faced in your life, whether or not it was software related.

System design (domain-focused)

Critiquing and redesigning the architecture of an existing Android chat application

Given an existing chat application, identify architectural weaknesses and propose an improved design, without relying on popular third-party libraries such as RxJava or Retrofit.

The candidate proposed an MVVM-based approach and referenced a pattern similar to one Google itself uses to address related Android issues. The interviewer pushed for a further-optimized solution beyond that, and the discussion moved on to other design considerations before a single best answer was reached.

Coding round: string transformation

Determining whether one string can be transformed into another under given rules · 30 minutes

Solve LeetCode's 'String Transforms Into Another String' (premium): determine whether string A can be converted into string B.

The candidate described this as their weakest round, attributing it partly to fatigue after lunch. They initially approached it like a word-ladder problem before the interviewer redirected them toward reasoning about character order and uniqueness. They completed the core logic but did not reach the follow-up in the time available.

Coding round: N-ary tree API design

Designing an API for manipulating and querying an N-ary tree · 30 minutes

Design an API for an N-ary tree that supports: add(a, b) to attach node b to node a; delete(node), restricted to leaf nodes; getLeft(node) to find a node's left neighbor; and getRight(node) to find a node's right neighbor.

The candidate used a Node class with a parent reference and solved getLeft/getRight with a level-order traversal, noting a more efficient approach likely existed. They also flagged edge cases such as preventing duplicate parent-child relationships and validating ownership before deletion. The interviewer engaged closely with the discussion and let the round run past its normal time.

Coding round: grid-based matching

Shortest-path and matching problems on a 2D grid using BFS · 30 minutes

Given a person and a vehicle on a 2D grid with no obstacles, find the quickest way for the person to reach the vehicle.
Given multiple people and multiple vehicles on the grid, find the quickest way each person can reach a vehicle and return the resulting pairings (comparable in spirit to LeetCode's 'Campus Bikes').

The first part was solved with a standard BFS. The second used a BFS variant that tracked which person was expanding from which starting point and marked vehicles as claimed once reached. The candidate noted the interviewer spent extended time observing the first, simpler part, which left roughly 10-15 minutes for the harder second part.

Key takeaways

Studying with focused work blocks and deliberate breaks, rather than long unbroken sessions, was something the candidate credited for sustaining months of preparation without burning out.
Reviewing discussion threads for problems solved sub-optimally, not just problems solved correctly, was called out as more valuable than only reviewing failures.
Talking through reasoning out loud in detail, including uncertain or exploratory steps, was something the candidate emphasized as important for interviewers to follow the thought process.
Energy management across a multi-round onsite loop matters: the candidate pointed to fatigue after lunch as a specific factor in their weakest round.
An offer can still land at a level below the one targeted; the candidate received mixed explanations for this (resume signal versus round scores) and cautioned against assuming a single definitive reason.

Practice a Google interview

Rehearse out loud against the kinds of questions in this story — with an AI interviewer that asks follow-ups.

Practice this interview

Source

The questions and process facts come from the candidate's public write-up, linked below. The retelling above is our own summary.

Candidate's public write-up on LeetCode Discuss