Google Interview Experience

Hi everyone,
I've prepared in Leetcode from last 9 months and benefitted a lot through the discuss section. Time to give it back to the community :)

Application:
Recruiter pinged me on Linkedin around the same time that I've started preparing for interviews. I asked 2 months of time to prepare and practise properly. We agreed to have a sync-up call every 3 weeks or so to check the progress. Follow-up was prompt and we used to discuss what all areas I've covered, how many questions I solved and how much time it takes to solve the problems. Their standard/expectation is to solve a LC hard under 30 mins and then you are ready.

Once I felt ready, we moved to the interview process. Phone screen round was scheduled.
I did a lot of Interview Assessments tests in LC before appearing for the phone screen.

Phone Screen Round:
Interviewer was an Engineer from US. Greetings were warm and he started with a behavioural question about my recent technical challenge in the current role. I was prepared for this after reading similar experiences in the Discuss section. Answered it without consuming much time (3-4 mins, may be).

Then he explained the problem to solve. It was a typical enumeration problem with some constraints which would take O(2^n) with brute force and O(n) with DP. I couldn't come up with DP solution right away. We discussed the brute force solution and started coding it (thinking that, this would be good enough solution). He asked me if we can do any better. 45 mins got over while we were reaching the DP approach. He gave a couple of minutes for queries and I asked him the same question that he asked me in the beginning :)
Similar question: https://leetcode.com/problems/student-attendance-record-ii/

Self Verdict: No Hire. Tanked.
Actual Result: Interviewer was considerate enough to pass me for onsite. He asked the recruiter to give me some more time for preparation.

I practised LC hard for a couple of more weeks before going for the interviews.

Round 1:
Interviewer was again an Engineer from US. Asked a question on grid based cost optimization. Discussed the algorithm and coded quickly once he was satisfied with my approach. Did dry run with a test case. There was a follow-up question to print the path too. I directly started implementing as it was straight-forward. Time got over in the middle. But he seemed satisfied. He answered a couple of questions from my side and then ended the call.
Similar question: https://leetcode.com/problems/minimum-falling-path-sum/

Self Verdict: Hire.

Round 2:
Interviewer was a Senior Engineer from India. He explained the question with a lot of clutter and underlying expectation was to do a simple min operation and a min heap top k items retrieval as a follow-up. He was focused more on code quality rather than the problem complexity. I understood the question little incorrectly and started with a wrong approach but be corrected me immediately. He gave ample amount of time in the end for questions and we had a good discussion on team changes within Google.
Similar question: https://leetcode.com/problems/top-k-frequent-elements/

Self Verdict: Lean Hire.

I took a gap of one and half months in between due to personal reasons. I lost interest in continuing the interview process. But the recruiter followed-up again and resumed the process. She again gave a week to revise everything and then scheduled the interviews. I was little out of practise by then and thought of just appearing for the interviews without any practice.

Round 3:
Interviewer was an Engineer from US. He started with an easy question to warm up. We discussed and solved with 5 mins and moved to the actual problem. It was a grid question with islands and merging them in some way. Explained him a multi-node start BFS approach and he seemed satisfied. Coded it quickly. It involved implementing both DFS and BFS for some reason. Did a dry run. He asked to write some test cases for the solutions and asked what changes we could make if it was a production code. Answered well with my practical experience and seemed satisfied. We discussed a little bit about culture at Google and ended the call.
Warm up question (similar): https://leetcode.com/problems/missing-number/
Actual question is little spiced up than this question: https://leetcode.com/problems/shortest-bridge/

Self Verdict: Strong Hire.

Round 4:
Interviewer was from UK. Asked a data structure designing and APIs building around it kind of question for a specific problem that they were solving (trimmed down the complexity due to time constraint). He made his intentions very clear that he was going to test the code quality and asked me to write it how I would write it in production from start itself. It needed a combination of two hashmaps and some temp vars. He seemed not so impressed by the algorithm but was very much impressed with the code quality (and apt commenting everywhere).

Self Verdict: Lean Hire.

Round 5: Googlyness Round
Interviewer was a manager from India. Easiest round with hypothetical questions for checking the behaviour. You could give imaginary answers as to what you would do in such a situation or you could answer with your own working experience. Ex: If you need to work with a team who doesn't write unit tests for their code, what would you do? Conflicts with teamates, etc.

Self Verdict: Hire.

Recruiter told me that all the interviews were positive except one which was average (Round 2, I believe). She moved me to team matching stage. I had a call with a hiring manager a couple of days later. I liked the work they were doing. I didn't wait for anymore team matchings to happen and expressed my interest to the recruiter. She moved my packet to the HC and I got selected, yay!

Reasons for not sharing actual questions in details:
I read from many sources and sympathize with the interviewers in this point. They give a lot of time to frame the questions properly with ample amount of details so that they don't have to eat interviewee's time to explain the question. If the interviewee shares the question publicly, they are forced to do a new question again (probably ends up with increased complexity and less quality if time is less. My round 2 is such a question and it costed me time to clarify the question) which they find it hard to do on a regular basis. Eventually it is going to hurt us in the long run (We can already see the complexity of the questions going up and this could be a small reason contributing to it). If we can discuss the concepts involved without actual questions, it would be beneficial for both the parties. (Entirely my personal opinion, agree to disagree).

Key take aways for me (and possibly for someone reading too):

1. Practising good amount of questions will definitely help.
2. Practising the templates of important algorithms would help to speed up the coding in interviews and opens space for discussion instead of coding.
3. At least for Google, it is better to be conscious of the steps to be following for each round. Listen question, repeat it to validate your understanding, write small concrete examples to validate correct input and output, quick brute force, improvise on it and reach a common point where both are satisfied with the algo, try this algo on the examples written in the start before coding, code, dry run, test cases, done.
4. Seeing the google interview experiences on YouTube, I used to think that only very smart people like them would be able to clear. But in reality, the questions are entirely doable and many normal engineers are cracking them without bothering to share publicly.
5. Little bit of luck is a blessing to get all the questions which could be solved.

Thanks!