Experience: 3.5 Year FT, 0.5 Year Intern.
Position: L4 at Google
Location: Google, India
Interview Date: Nov 2021 to Jan 2022

I'm not gonna describe the round problems (I don't know if google re-uses questions), but will give some ideas about how it went.

Algo Round 1:

• Question was in geometry domain, simple to understand.
• First defined the trivial approach : O(n^4).
• Refined it to O(n^2), utilizing hash-map's O(1) query complexity (Probabilistic).
• Interviewer found my solution to be novel, something he hadn't thought of / seen before, but worked well.
• Interviewer asked me how I'd change my code for production readiness. I had already named my variables well and had extracted out most of the functionalities in seperate methods. Polished the naming and mentioned that some functions could be generic, and extracted to / use some utility class.
• Interviewer then added some more conditions to the problem, and asked me how would I handle these conditions.
• Had an in-depth discussion on how to approach the updated constraints, and had most of the details and complexities ready.
• Interview time was up, but the interviewer mentioned that he felt confident that given some more time, I'd be able to implement the solution as well.

Algo Round 2:

• Question was in Graph Theory domain.
• Was able to come up with a solution (find if a cycle exists in a DAG).
• Coded it up quickly (~20 mins).
• Some complexities were added, which after some thought, I realized could be easily handled by adding a few more edges in the graph in O(n) time.
• The answer required was changed (find the sequence, rather than if a solution exists).
• Thought about it a bit, and came up with an approach.
• Interviewer was convinced. Didn't have the time to code the 2nd solution.

Algo Round 3:

• Another graph theory question.
• Was able to answer and code within 20 mins.
• Made a few bug-fixes / naming changes to clean up the code.
• Interviewer added another set of constraints, that were mentioned as "might not be solvable", but just for discussion.
• Discussed the problem a bit, and realized that if we modify the graph by performing another BFS-like traversal before applying the existing solution, the problem could be solved.
• The interviewer was convinced with the solution, and we ran out of time, didn't have to code the second solution.

Algo Round 4:

• This was the one round where I had to struggle a bit, as my initial approach was not in the best direction.
• My mind went imagining the problem in 2D space, and trying to apply geometry to it to find some patterns.
• After a bit of discussion with the interviewer, he pointed out some scenarios that led me to understand that my model was flawed.
• Went back to the drawing board, and after a few discussions with the interviewer, I realized that a simpler (non-geometry) approach existed.
• Coded up the solution, and the interview was done.

Googlyness:

• Asked about my past experiences and projects.
• Asked about different challenges I had faced in my work before.
• How did I deal with specific challenges (eg: reprioritization of tasks, etc.)
• We also talked about WLB, and setting boundaries at work, it's impact, etc.
• In general, had a nice conversation about work culture, and how to have a healthy discourse about issues / concerns with projects, and how to manage entropy in software engineering projects.
• I think what helped a lot in this interview, was that I had in my previous roles, taken an (unofficial) lead role, and had focused on attempting to maintain good wlb for my team, high code quality, and several discussions with management on our shortcomings / challenges between planning and executions.

Algo Round Notes:

• Used Java, since that was my language of preference.
• Got some language function patterns confused, like whether comparator returns true/false or +ve -ve for sorting, mentioned it to interviewers, and they were helpful, and didn't mind.
• Made sure to keep the code clean in the first go, talking as I coded about what the variable / function I was defining would be doing.
• Left some things abstract, like how a graph would be initialized, eg: adjacenciesList = buildAdjacenciesList(inputArray);
• Let the interviewer know that I'd code these functions if they wanted me to.
• Often, once the interviewer was convinced of the solution, they'd ask me to implement these functions, which was easier to do, since there was less time pressure.
• Also, it helped in identifying bugs when your code is split into clean functions with Single Responsibilities and good names. This helped a lot in debugging a few cases as well.
• Overall, having a good hang of algorithms and why they work the way they do, and clean coding practices (general SWE stuff) helped a lot.
• Another thing I made sure was that I wasn't struggling with the language.
• Since there's so much time pressure, most of my practice before the interviews was focused on making sure that I could code cleanly and quickly whatever solution I had in mind.
• The above helped me focus on discussing the solution and approaches with the interviewer, instead of spending time on the code / struggling with the language.

Overall Experience:

I was in no rush to finish the interviews asap, and the recruiter was extremely accomodating. In general, Google interviews are known to take time, so it's best to keep some time out for it, in parallel to one's day to day job.

Overall had a very nice experience, the interviewers were friendly, approachable, and helpful.

Compensation Link