Interview Experience | SDE | π₯π₯ | Google
2026 (JulβSep) Software Engineer Full-time @ Google β Virtual Onsite | π Positive | Medium | Pending
My overall impression is that Google's questions are not necessarily very hard, but they like to keep changing the conditions after you have written the code. Both interviewers were friendly and let me finish explaining my approach. They did not interrupt on purpose.
Round 1 β BQ + Coding
BQ
The first ten minutes or so were BQ.
Questions:
- Why Google?
- The biggest challenge in a project, and how I solved it.
I talked about a service whose latency got worse after traffic grew.
I thought that would be the end of it, but the interviewer followed up on the project quite a bit:
- Why did you choose Redis at the time instead of a local cache?
- How did you decide the cache expiration policy?
- What if the cache and the DB disagree?
And at the end: if you were doing it again now, what would you change?
I answered this one so-so. Most of what I had said was "why we did it that way at the time", and suddenly I had to pick apart my own original design. I thought for a moment and said I would probably build cache invalidation and monitoring earlier now.
Coding β restaurant waiting list
Then coding.
The question was a restaurant waiting list. Roughly three APIs:
join(user, table_size)delete(user)find_first_match(table_size)
First come, first served.
For example, when a 4-person table frees up, find the earliest-joined user who can sit at that table.
I said queue at first, but quickly found that delete is awkward.
I ended up with linked list + hashmap. delete(user) goes through the hashmap straight to the node.
The annoying part was find_first_match. You still have to keep global FCFS, so you cannot just give every table size its own queue and then take anything from it.
My first version was still an O(n) scan in the worst case.
After I finished, the interviewer asked: if the waiting list is very long, is there a way to make the lookup faster?
I did not fully write this one. We discussed maintaining a helper index per table size, but it still has to respect global arrival order, so the bookkeeping gets a lot more complicated. Time ran out and I talked through it instead.
In this round I felt the coding itself was fine. It was the project follow-up that was more detailed than I expected.
Round 2 β BQ + Coding
BQ
The second round started with a few more BQ questions.
The one I remember better: how do you win over a team member who initially disagrees with you?
I gave an example of disagreeing with a teammate about a technical approach. The interviewer followed up:
- How did you confirm your approach was actually better?
- If the data had shown the other person was right, what then?
And another: when multiple priorities compete, how do you decide what to focus on first?
That one was more normal. I talked about impact / urgency / dependency.
BQ was about ten minutes, then coding.
Coding β Meeting Rooms II
It started with a very simple warm-up: how do you tell whether two time intervals overlap. I finished that quickly.
Then it became Meeting Rooms II: given a set of meeting intervals, find the minimum number of rooms needed.
I used a min heap. Sort by start time first, keep the current room end times in the heap. If the next meeting's start is not earlier than the heap top, that room can be reused.
I had done this one before, so I wrote it quickly.
Then the interviewer added a follow-up: now, not only tell me the minimum number of rooms, but also tell me which room each meeting was finally assigned to.
That is a small change to the original heap. Instead of just end times, put (end_time, room_id) in it, and reuse the id once a room frees up.
I got the logic for opening a new room id slightly wrong at first. I found it myself during the dry run, fixed it, and then all the test cases passed.
At the end they asked about complexity.
The whole coding part finished in about 25 minutes. There was some time left, so we just chatted about the team and day-to-day.