Frontend interview guide
Search, Gmail, YouTube, Workspace, Cloud Console. The DSA bar is the famous part; the rest matters too.
Frontend engineers interviewing at Google. The loop is dominantly algorithmic, with FE-specific rounds appearing on frontend-oriented teams.
Last reviewed 2026-10-04
What they emphasise
- Algorithmic reasoning — the Google loop remains heavy on data structures and complexity even for a frontend role.
- System design — frontend-specific at an FE-focused team, generic distributed at others. Ask your recruiter which.
- Googleyness — the behavioural round is real; collaboration, bias to action, intellectual humility.
- Reliability thinking — Google products scale, and candidates are expected to think at that scale.
The loop, round by round
5 rounds. Durations and formats are typical, not guaranteed — confirm the loop shape with your recruiter in the screen.
Round 1
Recruiter screen
~30 minPhone or videoWhat it covers
- Resume walk-through, level alignment, and team-match preferences.
- Confirm the loop shape for your target team (FE-specific vs generalist).
What they're looking for
- A specific, well-prepared pitch for why Google and why this product area.
Round 2
Technical phone screen
45 minLive coding in a shared docWhat it covers
- One or two medium-hard algorithmic problems. Explicit complexity analysis expected.
- Follow-ups testing edge cases and optimisations.
What they're looking for
- A working solution with the stated complexity. Hand-waving complexity gets caught.
- Clean iteration from brute force to optimal with the interviewer following along.
Round 3
Onsite: coding (multiple rounds)
45 min eachLive coding, often in a shared docWhat it covers
- Two to four coding rounds, each a different algorithmic area — arrays/strings, trees/graphs, hash/heap, dynamic programming or recursion.
- On an FE team, at least one round may be JavaScript-specific (debounce, promise control-flow, event-emitter).
What they're looking for
- Complexity reasoning that holds up to probing.
- Clean, idiomatic code with meaningful variable names — not golf.
Round 4
Onsite: system design
45 minWhiteboard / shared docWhat it covers
- On generalist teams: a distributed-system prompt (design a URL shortener, design a chat).
- On FE teams: a frontend-shape prompt (design a search autocomplete, design a feed, design a video player).
What they're looking for
- Explicit trade-offs, with the specific conditions that make each choice right.
- A visibly bounded answer — scope control over trying to design everything.
Round 5
Onsite: 'Googleyness and leadership'
45 minConversationWhat it covers
- Behavioural stories grounded in collaboration, ambiguity, failure, and recovery.
What they're looking for
- Specific, well-formed STAR stories. 'I did X; it worked / didn't; here's what I learned.'
- Intellectual humility — 'here's where my first instinct was wrong' is a positive signal.
What each level expects
The bar you're being measured against — plus the failure modes candidates most often trip on at that level.
SDE 2 / mid
~2–4 yearsL4 — owns features end to end with mentorship.
What they expect
- Solid data structures and complexity reasoning.
- Can decompose and ship small-to-medium features on an existing team.
Common failure modes
- Over-engineering the FE round into a 10-component architecture when a 60-line component was the right answer.
- Behavioural stories at the 'I was on the team' level rather than 'I did this specific thing'.
Senior
~5–8 yearsL5 — owns a technical area, mentors, drives patterns.
What they expect
- A system-design round where you lead the discussion.
- Behavioural stories at the 'I owned the outcome, here is the measurable result' level.
Common failure modes
- A system design that is 'the standard pattern' with no adaptation to the specific prompt.
- In the Googleyness round, no evidence of changing your mind when presented with better data.
Staff
~8+ yearsL6 — technical direction across teams, drives multi-quarter initiatives.
What they expect
- A system-design discussion that reads peer-to-peer.
- Visible leverage — your work made other engineers measurably more productive.
- Strong technical opinions with evidence, backed by shipped work.
Common failure modes
- L5+ output rather than L6 leverage. The L6 bar is specifically about multiplying others, not doing more.
How to crack it
Day-of advice. The specific moves that separate offers from no-offers when the content is already in your head.
- 1Grind the algorithmic basics until the common patterns (sliding window, two-pointer, BFS/DFS, heap, DP) are automatic. The Google algorithmic bar is real.
- 2If the team is FE-focused, make sure you can also build a UI from scratch with keyboard, ARIA, and empty states — JS idioms alone won't cover you.
- 3For the system-design round, start with clarifying questions. Three good ones beats going straight to the whiteboard.
- 4Pre-write five Googleyness stories. Rehearse to under 2 minutes each, with specific numbers.
- 5On the day: narrate your thinking even when stuck. Silent debugging reads as 'can't do it'; narrated debugging reads as 'thinks under pressure'.
How to master it (over months, not days)
The longer-horizon work. These are the habits that pay off at Senior+ bars where cramming visibly fails.
- Treat the algorithmic round as a sport, not a surprise — a daily (or weekly) problem rhythm for months beats a cram week.
- Build one real product in your own time. The system-design round rewards someone who has actually shipped, not just studied.
- Read Chrome and V8 engineering blog posts. Google's frontend scale and performance culture is reflected there.
- Pick one accessibility primitive and go deep. The depth beats breadth, especially on FE-focused teams.
- Write — RFCs, blog posts, long PR descriptions. The L6+ path leans heavily on written artefacts.
Resources
On-site content for the technical prep, plus short-list of external links worth your time.