I had interviewed for their L6 (staff software engineer) position, so this post is tailored to that experience. I have also taken dozens of interviews and was in their hiring committee (HC) which makes hire / no hire decisions for engineers at L3, L4, L5 levels. That gives me some idea of how the interview process at Google works.
The most important thing is that you should be enjoying the process of interview preparation. If it is a chore then you will not succeed. Preparing for such interviews is always a pleasant experience for me. I need to get back to the books and solve puzzle type of questions which helps me revise all the concepts which I learnt long ago. I think to clear coding interviews, you need to have a similar outlook - have fun in solve the coding puzzles.
I think one should allot a 2 month of preparation time (when one is not doing a regular job) and prepare for 4-6 hours everyday.
There were 2 coding rounds, 2 system design rounds and 1 Googleyness round.
They are medium to difficult questions. One cannot be expected to solve those questions unless one has practiced well. Specifically for ex Simpl senior engineers, for whom this article is intended, I know that their fundamentals are all good. What is required is a very good practice. At work we write straightforward code, but interview questions are more difficult - might involve dynamic programming, or some other crucial insight which is only possible to develop with practice.
Following sources helped me in getting to shape:
I solved many questions from the book Algorithmic puzzles. This book is not specifically for interview questions, but question quality is very good from aesthetic point of view and gets your brain working.
I solved lots of easy and medium leetcode questions. I think one should not attempt hard questions. They take too much time to solve and are not efficient use of one's time. Aim perhaps to solve like 40 easy and 60 medium questions.
Google search "Google programming interview questions" and solve 40-50 of them. The code that you write should be a proper code in some language - C++, python or go, but you don't need to compile and run the code.
You should know basic graph algorithms - BFS, DSF and dijskstra.
Another thing is that one should solve questions only of mainstream data structures - arrays, linkedlist, trees and hashmaps. Perhaps stacks and queues and may be heaps. More esoteric structure than that like red black trees, tries, and more complicated things whose name I don't even know are not worth putting time in. Interviews are mostly about being able to apply brain in problems that are solved with simple data structure rather than knowing the uses of esoteric stuff.
You should be able to tell time and space complexities of your solution.
Typically in a system design question you get asked to design some large distributed system. I think that unless you have worked on designing distributed systems, it will be difficult to answer those questions. And if you have done so then if you practice a little, you will be able to do a good job on these questions. I think these questions distinguish between junior and senior engineers - both should be able to do coding, but designing requires some experience.
To prepare for these interviews, one thing is to again Google search "Google system design interview questions" and practice some representative questions.
I found Narendra L youtube channel on system design very good.
I have heard good things about Alex Wu book, but did not read it myself.
I think it would also be worth spending some money to get some paid course on system design. It is important to cover questions involving various basic concepts: ELB, map reduce, database table design, caching etc.
Two notable points: while solving such questions you should not immediately jump to solution, rather spend some time understanding the question and seek any clarifications. Secondly, always do some numerical estimates: like you should ask for input data size or request rate etc and figure out some high level estimates of your resource requirements, or the throughput characteristic of your system etc. Overlla, some numerical analysis of capacity planning should be there. Also, during the process of thinking, think aloud so that interviewer is engaged. They may prod you in the correct direction if they know what you are thinking.
Lastly there is googleyness round. It is soft skill round. Very few people get rejected because of this -- you should just try to project yourself to be a nice collaborative person. Like most people are.
Still from preparation point of view, you should should google search some questions and think of their answers.
Once you are done with your round, if the recruiter feels that you have a chance to clear HC (hiring committee) -- because HC will be deciding finally, then the recruiter creates a packet for you with your resume, references and interview notes. In case some manager is particulary interested in you (recruiter may reach out to hiring managers if they feel some candidate is particularly suited to their team) then the packet also contains a note from hiring manager that they are particularly interested in you.
HC evaluates the packet and makes a hire/no-hire decision. If the candidate is a hire then via some processs (I forget the details), recruiter puts you in touch with hiring managers who are interested in you. You talk to them and pick whichever team you are most interested in.