Senior Software Engineers interview at Google can consist of :
Coding Questions (2–3 interviews)
System Design
Distributed systems knowledge
Behavioral interview

Before I jump into the myths, I want to call out that google has one of the best-interviewing experience. The recruiters are some of the best in silicon valley. Every interviewer is extremely polite and most likely you will end up feeling good at the end of the day.
Google interviews have been really beneficial to me as a stepping stone. I have been rejected by google 4 times, every time ending up with a better opportunity.
As an interview coach and interviewer, I want to break the myth that Google hires the smartest or most prepared software engineers.
We have all discussed extensively Max Howell’s rejection due to the binary tree problem. And, the debate on defense was — preparedness.
So, success, experience, communication, and preparedness are all essential. In addition, the performance of the day interviews matters. What if all of them are perfect, do you still get rejected?
I will break down my interview experience with Google. My experience can help you be better prepared.
In addition, a callout for google to acknowledge its broken interview process.

Google does not ask puzzle questions anymore.

The questions can be posed in a way that it ends up being a puzzle.
The question was simply: given error values and timestamps find if in the given range any value exceeds a given error threshold.
To confuse the candidates, the interviewer gives params like ‘p’ for time, ‘t’ errors, etc.
To solve questions that add unnecessary complexity, as a candidate you should redefine these params to better-named values. Ask clarifying questions.
Towards the end, the interviewer called out that these interviews are meant for creating confusion and induce ambiguity.

The only problem in my case was: I could not understand the accent of the interviewer. Asking clarifying questions more than 3 times I decided it was a waste of both our times as his English was incomprehensible. I went ahead to give him an exhaustive list of all the possible solutions and let him chose which one he intends me to solve.
This was just a bad pairing- giving the ambiguity question to an interviewer who could not clarify the question and the question itself was written to confuse the interviewee. Can’t win here.

Google interviewers have in-depth knowledge of System Design

The system design was: creating a log aggregator system. Something I have thought about before and was aware of possible alternate solutions.
Just because the round is system design doesn’t mean that you should assume the interviewer has a good domain knowledge. I figured out this pretty early and tried to dumb down things for him. Repeatedly asking if he is satisfied. I have many tricks down my sleeves to solve the system design interview. Then, I wanted to make sure he understands the solution, so I offered to explain every bottleneck, every decision made. The interviewer closed the interview with the comment that I did great and the system looks great. Not many follow up questions.
Having helped candidates to prepare for interviews, reading most research papers on design, and going through many mock interviews, working at scale problems everyday... I was more than prepared for the interview. It was a piece of cake for me.
The feedback from the recruiter - System design skills not satisfactory.

Google questions are well vetted.

Having interviewed with Google 4 times, I understand that to hire smart candidates and interviewing thousands of candidates every month, google creates lots of new problems every day.
Not all of them can be vetted for the most optimal solution.
And if the candidates come with a more optimal solution, it might be hard for the interviewer to understand it within 20 minutes time frame.
I have had times when I could not understand the candidate’s solution and had to go back and study the solution in depth. So, we are all susceptible to be tunnel-viewed by the solution present in front of us.
But, this particular interview was way off the chart.
Question: Given 1000 machines, each with 1M records of double, find the median.

Before I go into my approach vs Google’s approach, please take time to think about the solutions.
The solution is very simple
Sort the items in all machines. The problem is then reduced to merge the k-sorted list. https://leetcode.com/problems/merge-k-sorted-lists/
I knew this solution, but the problem was related to scale. The network cost. And I attempted to optimize for that.
The interviewer didn’t understand this optimization and wanted to solve this is a brute force manner. His words “don’t solve for scale”. Which was really weird. Why would the question have 1000 machines with 1 million items each if the scale is not the concern?
To give a glimpse into the difference:
Google’s solution runs in 57.9 days.
My solution runs in 200 seconds.
I guess the interviewer wanted the solution in front of him and didn’t let me venture out.
Here is the detailed solution and analysis:
https://leetcode.com/discuss/interview-question/695445/google-l5-mountain-view-find-median-of-doubles-from-1000-machines-reject/586528

Other than these 3 interviews. I had 3 more interviews.

The first one didn't start until 20 minutes due to the Google handout incorrect link shared by the recruiters. This was the start of declining interview experience.

There was an interview on distributed systems, which I easily nailed. Additionally, a behavioral interview that I was well prepared for since I had good examples from my work experiences.
Google hires smart and lucky candidates. A more optimal solution is not desired. Follow the desired solution and if time permits try to show your optimal solution. If you get paired with a bad interviewer, you can’t win unless you luckily have the same frequency.