Google L5 software engineer interview: phone screening, three onsite rounds, system design, and a late rejection

How the process went

1. Phone screening

   A single search problem that began with almost no constraints and evolved step by step — input validity, edge cases, then scale — rather than being a fixed, static prompt.

2. Onsite, round 1

   A tree traversal problem that shifted from passing state through recursion to exposing it as a property, followed by a serialize/deserialize extension.

3. Onsite, round 2

   A shortest-path problem where recognizing the underlying tree structure was itself part of the challenge.

4. Onsite, round 3

   A short system-design prompt about a mobile client fetching server data, closing with a coding task that used a real platform API.

5. System design round

   A separate mobile system design round that required actual code for parts of the design rather than pseudocode.

6. Googleyness and Leadership round

   A conversational behavioral round covering standard situational questions.

7. Decision

   After about two months without an update, the recruiter told the candidate the role had been officially closed as of March. The candidate believes a rejection was likely regardless, given the self-assessed 'No' from two of the four technical rounds.

Phone screening

Coding — search problem with evolving constraints

• Given a set of numbers, determine whether a target value is present; the prompt started with almost no information, requiring the candidate to ask about input type (array, tree, or stream) before proposing a brute-force linear search and then a binary search.
• Once the input was assumed sorted and valid, that assumption was removed — the candidate had to work through edge cases such as negative values, overflow, and duplicates, and decide how invalid input should be handled.
• As the input size grew past what a single machine could hold, the discussion moved toward a distributed approach that would need to partition and merge results.
• The interviewer asked the candidate to justify choosing binary search over linear search and to identify test cases missing from the candidate's own test list.

The candidate described this interviewer as unusually conversational, closer to a day-to-day design discussion than a rigid ask-hint-retry pattern.

Onsite round 1

Coding — tree traversal, interface constraints, serialization

• A depth-first traversal problem with a follow-up requiring depth information, first solved by passing depth + 1 through the recursive calls.
• The interviewer then changed the interface so depth had to be exposed as a property rather than a parameter, which pushed the candidate toward a breadth-first solution instead.
• A follow-up on serializing and deserializing the data, complicated by the objects being a custom model rather than plain numbers, which required preserving identity across serialization.
• The candidate was also asked to write tests, though with less rigor than in the phone screening round.

The candidate came away from this round expecting positive feedback.

Onsite round 2

Coding — shortest path in a tree

• Find the shortest path to a given node, or determine the distance to a node not present in the structure; the candidate did not immediately recognize the structure as a tree and began with a linear search.
• A follow-up to improve the time complexity, during which the candidate tried array-based, binary-search, and graph-based approaches before reaching a working solution with substantial hinting from the interviewer.

The candidate assessed this round as a likely 'No' given how much help was needed to close on an answer.

Onsite round 3

Lightweight system design combined with API-level coding

• Starting premise: a mobile client needs to request data from a server. The candidate had to design the flow while the interviewer steered the discussion away from extending the design beyond what was actually asked.
• Closing task: implement code that calls a system API to update a table view, referencing Apple's documentation on inserting and deleting rows, with the interviewer expecting a batch-safe, efficient, diff-based update rather than a full reload.
• The candidate made an implementation mistake in the final minute of the round, in the vein of updating UI off the main thread or creating a retain cycle, which the referenced documentation flagged as an inefficient usage pattern.

The candidate expected a 'No' from this round as well, in part because the mistake touched on a documentation detail read years earlier and not retained.

System design

Mobile system design with required implementation detail

• A mobile system design prompt the candidate found similar in shape to a Facebook system design round from an earlier interview loop, with the feature already defined rather than left open-ended.
• The interviewer asked for actual code rather than pseudocode for parts of the design, including asking the candidate to fully specify how an error message would be displayed rather than leaving it as a placeholder.

The candidate's general approach to mobile system design: reason about latency (caching and threading), consistency (a single source of truth), and security (privacy implications for the storage layer).

Googleyness and Leadership

Behavioral

• Standard behavioral prompts about situations such as handling a difference of opinion or an unreasonable request, drawn from typical behavioral-question categories rather than anything specific to this loop.

Source

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