I failed the Google L5 interview in 2016. I failed it again in 2017, at a different location, with different interviewers, and a different set of questions. I was very angry about this at the time, largely at myself and slightly at the process. Three years later I cleared the L6 loop in a single attempt. This is what actually changed.
Attempt one (2016): the "I'm clever enough for this" attempt
I went in thinking of the interview as a test of cleverness. I could solve LeetCode-hard problems under time pressure and I assumed that was the brief. I performed competently in the coding rounds. I got demolished in the design round because I spent forty-five minutes drawing an increasingly baroque architecture and never stopped to ask what the product was.
The feedback I got back — a summary from a recruiter over the phone — was that my technical ability was "clearly there" but I had "struggled to engage with the collaborative aspects of the interview". I was furious. I thought it was a polite way of saying they hadn't liked me. Now I think it was precisely the feedback I needed. I was treating the interviewer as an adversary.
Attempt two (2017): the "do more LeetCode" attempt
I did the obvious wrong thing. I assumed my problem was technical and I ground through another 400 LeetCode problems. My coding got faster. My design didn't change. My communication didn't change. Unsurprisingly, I failed for the same reasons I'd failed the first time.
The failure mode was specific: in the design round, when an interviewer offered a different opinion, I defended my original answer instead of engaging with theirs. It read as inflexibility. The internal rubric at Google calls this "collaboration" and weights it heavily.
The year in between
After the second failure I did not reapply for a year. Partly out of pride, partly out of exhaustion, partly because I'd been promoted internally at Google already and had moved to a different team. What I did instead:
- I started deliberately giving interviews. Dozens of them. For L3 and L4 candidates at first, then L5 as I was cleared to bar-raise. Giving interviews is the single fastest way to learn what interviewers are actually looking for. Nothing else comes close.
- I read every design doc my team had written in the last two years, slowly. I then wrote four of my own, not because the team needed them, but because I wanted the practice of structuring a technical argument in writing.
- I joined a mock-interview circle with three other engineers, one of them above me in level. We met in a meeting room in the Paddington office once a fortnight and took it in turns to give and receive design interviews. The feedback was brutal and specific. This was the single highest-leverage hour of my week for about six months.
Attempt three (2019): what I did differently
Four things, in descending order of importance.
1. I treated the interviewer as a collaborator
This is a cultural point disguised as a tactical one. Before, I had been trying to demonstrate that I was correct. Now I was trying to have a conversation. The difference showed up in tiny moments. When an interviewer said "what if the load was ten times higher?", I didn't say "then I'd need to shard, which is what I was about to propose". I said "fair, let me think — the bottleneck here would be X, so I'd probably Y, does that track?". One of those is a defence. The other is a conversation.
2. I narrated the structure of my answer
At the start of the design round I spent about thirty seconds explicitly saying: "here's the shape of how I want to approach this — clarify requirements, sketch capacity, draw a first-pass, then go deep on what looks interesting. Stop me if you'd rather I ran it differently." This did two things: it gave me a safety net when I got lost mid-way, and it invited the interviewer into the process. Several of them told me afterwards it was one of the things that had marked me out.
3. I prepared three specific stories for the behavioural rounds
Not a dozen. Three, drilled until I could tell each in three to five minutes, with a beginning, a middle, an end, a specific quantifiable outcome, and an honest statement of what I'd do differently. I'd wildly underprepared for the behavioural rounds on both previous attempts. It had cost me.
4. I stopped preparing the week before
On the two failed attempts I'd been grinding LeetCode the night before the interview. On the successful one I stopped seven days before, got a decent amount of sleep, did something unrelated the day before, and walked into the interview tired but calm. The performance gap between me-on-day-seven-of-cramming and me-rested was not small.
What the levels actually test for
From having now given several hundred interviews, my simplified mental model of what each level actually tests is:
- L3/L4: Can you code accurately under observation?
- L5: Can you design a non-trivial system, handle feedback, and communicate clearly while under pressure?
- L6: Can you lead a technical conversation, identify the genuinely interesting problem in an underspecified prompt, and demonstrate judgement about trade-offs?
The transitions are cultural as much as they are technical. I didn't become a better engineer between 2017 and 2019. I became a better collaborator.
If you're preparing for a senior FAANG interview and you think the problem is your coding: it's probably not. It's almost always your collaboration.
— Nivaan