Google L5 software engineer interview: phone screen waived, vague onsite prompts, and an extra round before an offer
GoogleL5 Software Engineer·Not specified·Interviewed 2021OfferUpdated July 17, 2026
This account comes from a senior software engineer with eight years of experience in research and development of programming languages, working in C++ on Linux at a non-FANG company in Boston. The candidate had failed onsite interviews at Amazon and Microsoft in 2017, then spent roughly two months rebuilding algorithm skills through monthly coding challenges before landing a Bloomberg interview. A Bloomberg offer followed, which the candidate then used to prompt a long-standing Facebook recruiter contact into scheduling Facebook interviews. Google came after Facebook, and this account covers the Google loop specifically.
Google waived the phone screen entirely and went straight to a virtual onsite: three coding rounds, one system design round, and a separate Googlyness round. The candidate described Google's prompts as more vague than the other companies' and harder to break down, requiring clarifying questions before an approach became clear. After that first loop, the panel felt it hadn't gathered enough signal and asked for two more coding rounds plus another system design round before the process wrapped up.
How the process went
Background
Eight years of experience as a senior software engineer (C++/Linux, programming-language R&D) at a non-FANG company in Boston, with prior failed onsite interviews at Amazon and Microsoft in 2017.
Prep restart
Used roughly two months during the pandemic to rebuild algorithm skills through monthly coding challenges before a Bloomberg interview opportunity came up.
Parallel loops
Received a Bloomberg offer first, then used a long-standing Facebook recruiter contact to schedule Facebook interviews; Google's process began after Facebook's.
Phone screen
Waived for Google — the candidate moved directly to the virtual onsite without a phone screen.
Virtual onsite
Three coding rounds (dynamic programming, backtracking, heaps, graphs), one system design round, and one Googlyness round, with prompts the candidate described as vague and requiring clarification before they could be broken down.
Additional rounds requested
The panel felt the first onsite loop hadn't produced enough signal and asked for two more coding rounds and one more system design round.
Outcome
The writeup's title reports offers from Facebook (E5), Google (L5), and Bloomberg from the same interviewing cycle.
Virtual onsite — coding
Three coding rounds spanning dynamic programming, backtracking, heaps, and graphs, with prompts the candidate found vague and requiring clarifying questions before an approach emerged.
- A dynamic programming problem — the candidate specifically flagged DP as carrying a lot of weight in Google's process.
- A backtracking problem.
- A heap-based problem.
- A graph problem.
The candidate said Google's prompts were more vague than Bloomberg's or Facebook's and needed to be actively broken down through clarifying questions rather than solved from a clear starting statement.
DP, backtracking, heaps, and graphs are the candidate's loose summary of the concepts that came up across all three coding rounds combined, not a claim that each round mapped to exactly one concept.
Virtual onsite — system design
One open-ended system design round.
- A vague system design prompt that had to be broken down at multiple levels into orthogonal sub-problems before it could be tackled.
Virtual onsite — Googlyness
A separate behavioral/culture-fit round included in the same onsite loop.
- A Googlyness-style conversation; the candidate did not detail specific prompts from this round in the writeup.
Additional rounds (after the first loop)
Two more coding rounds and one more system design round, requested after the panel felt the first loop lacked signal.
- A dynamic programming problem.
- A complex API design question combining a graph, a heap, and a map — the candidate wrote afterward that they still weren't sure they'd approached it correctly.
- Another vague system design question.
The candidate's advice from this stage: treat the recruiter as an ally and try to learn what signal was missing rather than assuming the extra rounds are a bad sign.
Key takeaways
- A waived phone screen doesn't necessarily mean an easier process — this candidate still went through a full multi-round onsite loop with deliberately underspecified prompts.
- Practice turning a vague, open-ended prompt into a solvable problem through clarifying questions before writing any code; the candidate flagged this as the main difference between Google's style and other companies' in the same search.
- A request for extra rounds because the panel wants 'more signal' isn't automatically a rejection signal — asking the recruiter what was missing can be more useful than guessing.
- This candidate's prep split practice into separate learning, rehearsal, and revision sessions rather than only grinding new problems, and repeated a curated set of roughly 70 problems until the underlying concepts stuck.
- Not being fully confident in a system-design or API-design approach doesn't automatically rule out an offer — the candidate said as much about the graph/heap/map design question in the second loop.
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