Hi folks,
I recently interviewed with Google, and since this community has helped me a lot during my preparation, I wanted to give back by sharing my interview experience.

It looks like Google’s interview process has evolved a bit. I had 4 interview rounds in total:

DSA – Online

Googliness – Online

DSA – Onsite (Google Bangalore / Pearson)

DSA – Onsite (Google Bangalore / Pearson)

Question:
Can anyone explain why Google has moved to this structure and what the reasoning is behind this change?

• Round 1: DSA (Online)

Problem:
Android Unlock Patterns
https://leetcode.com/problems/android-unlock-patterns/

I started by explaining a recursive backtracking approach. I also mentioned that we could store all possible states to simplify the implementation.
The interviewer then asked if we could optimize further. I explained how symmetry can be used to reduce the number of computations, which he seemed happy with.

I then moved on to coding. Since this was my first interview, I was a bit nervous and made a few small bugs, which the interviewer later pointed out. With around 6 minutes remaining, he asked me to optimize it further and hinted toward bitmasking. I immediately realized the approach and explained it.

He asked me to write how to set the nth bit, and mentioned that for interview purposes, he was not expecting a full bitmask implementation. He seemed satisfied overall.

Verdict: Hire

• Round 2: DSA (Onsite)

This was an onsite round, and the interviewer was extremely gentle and polite.

Problem:
Last Day Where You Can Still Cross
https://leetcode.com/problems/last-day-where-you-can-still-cross/

I explained a DSU (Union-Find) based approach and used the whiteboard to walk through an example. After that, I wrote the code.

The discussion went deep and took some time, mostly because the interviewer asked a lot of follow-up questions and edge cases, which made the round quite interactive.

Verdict: Strong Hire

• Round 3: DSA (Onsite)

This interview felt slightly different, though the interviewer was still very helpful.

The problem was a variation of:

Find the Safest Path in a Grid
https://leetcode.com/problems/find-the-safest-path-in-a-grid/

I initially proposed a Dijkstra-based solution. The interviewer asked me to walk through an example and analyze the time complexity. After that, he asked if I could solve it without using extra space or a heap.

At that point, I felt a bit pressured because explaining the example had already consumed time. I then proposed a Binary Search on Answer + BFS approach, which he liked.

He asked me to code it. Since there were only about 10 minutes left, I rushed and introduced a few bugs. The interviewer noticed and calmly told me to relax, pointed out the issues, and even gave me 2–3 extra minutes to fix everything properly.

Verdict: Hire

• Final Result

The recruiter reached out the next day and informed me that the overall feedback was positive, and I would be moving forward to the team-matching phase.
She also mentioned that I should be patient, as team matching can take time, and that my interview results are valid for one year.

• Questions:

How long does team matching usually take?

Is there any way to speed up the team-matching process?

• Tips from My Experience

Listen carefully to the interviewer’s hints and suggestions—they matter a lot.

Use the whiteboard to walk through examples and clearly explain your approach.

Speed matters: you should be able to write clean, bug-free code within 10–15 minutes.

Go through lots of interview experiences and actually code those problems. In some rounds, I recognized patterns from previous experiences, which helped a lot.