Hi community,

I recently completed 4 interview rounds with [Google] — 2 online rounds followed by 2 onsite rounds. I’m still waiting for the final result, so I wanted to share my experience and get your thoughts on my chances.

Round 1

The questions were based on easy-medium level string manipulation. I was able to solve them, but the interviewer focused more on clean and concise code rather than just optimization.

One mistake from my side was initializing:

vector<char> v;

without resizing it beforehand. The interviewer asked how this would behave for a large database and hinted toward memory optimization. I understood the concern, but the specific improvement he expected was using v.resize().

Overall, that was the only major thing I lacked in this round.

My verdict: Hire

Round 2 — Googliness

This round went well overall. The discussion was smooth, and I was able to communicate my thoughts clearly.

My verdict: Hire / Strong Hire

Onsite (after 2 weeks)

Round 3 — Graph Question

The problem involved a list of airports with flight arrival and departure times. I solved it using BFS.

Where I struggled was in representing the graph cleanly. I started overcomplicating things using nested pairs, maps of vectors, etc. The interviewer suggested using a struct, which was definitely a cleaner approach. He also suggested using tuples for storing time-related data.

So one weakness I noticed was choosing the right data structure quickly.

Another issue was around visited nodes. I initially argued that visited tracking was unnecessary because the traversal depended on time comparisons, but later the interviewer pointed out a missing case and hinted toward maintaining visited states.

Overall, I was able to explain and code the solution, though I did need a few hints during the discussion.

My verdict: Hire / Lean Hire

Round 4 — Rook Placement Problem

This was the hardest round for me.

Problem statement:
There was an n x n chessboard with n-1 rooks already placed such that no two rooks shared the same row or column. The matrix itself was hidden, and the only API available was:

countRook(a, b, c, d)

which returned the number of rooks inside a rectangle.

I initially approached it with a backtracking-based solution. However, the interviewer was heavily focused on reducing the number of API calls.

My first solution required around 2 * n * n API calls. After using memoization, I reduced it to around 2 * n.

I was able to code this version successfully, but the interviewer seemed more interested in problem-solving ability and optimization thinking rather than just implementation.

I also proposed another approach, but it became overly complex. The interviewer kept hinting toward a better search strategy, which eventually led me toward binary search. However, I reached that idea only after hints and did not have enough time left to fully code it.

I found this problem genuinely difficult because it was not a standard pattern I had seen before. Initially, I approached it more like a queen-placement/backtracking problem.

My verdict: Lean Hire / Lean No Hire

It has now been around 25 days since my onsite interviews. The recruiter mentioned they were waiting for feedback from one panelist, Does it take this long for a interviewer to give feedback or the reason is something else?

According to you, what would my overall verdict likely be, and what do you think my chances of selection are?

Recruiter Called me and told still waiting for evalaution, She told Onsite was not up to the expectations but online round were good so they are yet to come to a decision, She was inclined more towards rejection.

Thanks