Google has been one of the most sought-after companies. It's one of the universally known companies, and its products have revolutionized our internet experience. Combined with its reputed and skillful engineers, Google rakes up a fair bit of demand for prospective Software Engineers.

Google; one of the most sought after companies for SWEs

The awesome peer group, coupled with its top of the class development experience, and the in-office and personal benefits that sweeten the offer, makes it fairly difficult(almost a no-brainer) to reject the offer/consider other offers(there are a few companies that makes a competing offer in terms of benefits and dev experience and growth). So it makes it obvious that many people apply to Google, and foresee themselves working with Google sometime in their career.

The benefits of Google are of the top class among the tech companies :)

I would narrate my experience from the glasses of a college undergraduate student. There are some nuances involved with senior engineering interviews, and since I don't have a first-hand experience with them, it would be more suitable for undergraduate folks. You can also take a look at some of the resources, which I have mentioned for improving on the Algorithms/Data Structure part, and some of the behavioral part, which might be useful for senior-most roles too :).

Let's get started 🔥!

How did I manage to get interviews?

As with many tech companies, applying for a technical internship/full-time role, it is advisable to apply to their careers page section.

General Advice

Google has a nice careers page section; it contains links to all the technical/non-technical roles available in Google. I would suggest taking a look at the careers page and searching for suitable roles.

Google's Careers page is the best place for applying for open roles

Referrals are a cheat-code method for getting assured communication from Google about your application. Note that I didn't mention that it would be a guaranteed interview; getting an interview is a nuanced topic, and it depends on a lot of objective aspects, such as relevant experience, availability of headcount, resume passing through ATS, and so on. There are some subjective aspects as well, such as a recruiter considering your application in case your experience is borderline, how much your application stands out among the other applicants, some locations might be easy to apply as compared to others, and headcount being open.

I have personally faced challenges applying to Google, and many of the above points have come up, which made me rethink and work on my application. I didn't get through the application process on the first go.

Just to give you some statistics, I never managed to get an interview for Google Bangalore location, while I had applied to Google North America for an internship, and I had successfully managed to get an interview. For my FTE role, I had failed to get an application for Google India, while based on my experience, I managed to get an interview for Google EU for the SRE role. This is not to brag, but to explain the number of applicants for Google India, with the selection curve being really high :)

It is often a combination of objective + subjective reasons, so don't feel dejected if your application doesn't get through; it's a matter of one Yes among streaks of No(s).

My experience

So I applied 2 times for an internship role with Google North America for an SWE role. I had used a referral while applying in 2019, while for 2020, I had simply applied through the careers portal.

One important point to note is the time of application, apply early as soon as you get the role live. You can track the information using the following resources -

1. Reddit -

   1. CS Majors
   2. CS Career Questions
   3. CS Career Questions EU

2. Discord -

   1. SRE/DevOps Community

You can also reach out to some of the recruiters from LinkedIn. If you have a good rapport with them, many of them will be happy to let you about an opening for an Internship/FTE role. I got to know about an opening in my current FTE role with this method :)

While applying for the FTE role, I was interested in pursuing an SRE role. So I had been looking for an SRE role in the EU/UK and had applied in both locations, without a referral. I had also applied with another account with a referral but unluckily didn't get any reach out. I managed to get interviews with the non-referral account xD.

I had been contributing to Open Source for a fair bit of time, so it was easy for me to add real-world experience to my resume. Whatever roles I applied, it was quite relevant to my previous experience as an intern.

Another tidbit that I observed while applying to any tech companies in general, is that getting an FTE role with the US offices is much more difficult than getting one for the EU/UK offices for non-US citizens.

My best guess about this is getting the work permit, where getting a work permit for non-US countries is fairly straightforward. US requires 1+ YOE in the same company before they send the candidate to the US offices through their L1B visa. On top of that, if they want to undertake the candidate under the H1B visa, it is a lottery-based system, where the Master's students from US Colleges have a slightly better chance at making it through.

That doesn't mean that you don't stand a chance, you should still apply for any roles for which you find yourself suitable.

Preparing for the Interviews

Now that you have managed to get the interviews, you should now start prepping for the interviews. But wait, since Google is one of the most sought companies, you can imagine the difficulty curve of Google's interviews. By far, my experiences with Google Interviews have been fairly challenging; each of the interviews barring a few, have made me put on my thinking cap, and make sure I am challenged from my comfort zone.

So you should have already started prepping for the SWE Interviews and should avoid going head-first just after getting the interviews.

Algorithms / DS Interviews

One of the most important skills that you should cultivate if you are going to be involved with the Software Engineering role, is exercising your Algo/DS skills. It is, unfortunately, one of the most objective and fair(is it? am not sure!) ways to judge a candidate on their coding skills and their understanding of problem-solving.

I used LeetCode, which is a holy grail for prepping for SWE interviews(or any interview which has an Algo/DS round). You should use this resource as a marathon, rather than a sprint, because the number of problems, and the sheer depth required before you have a fair chance, make it important that you take your time in understanding the content and practicing it thoroughly.

LC is one of the bible for studying for coding interviews

While the interviews arrive, you can buy LC premium before 1-2 weeks. Solve the Google tagged questions, to get an idea about the difficulty level of the interview problems.

There is a lot to talk about on how to use leetcode properly, and I might talk about it in detail in some other post.

Behavioral Interviews

Behavioral Interviews are one of the trickiest interviews because you don't have an objective way to judge a candidate; there is a hint of subjectivity, which makes it different from the way how you prepare for the interview.

In contrast to other interviews, behavioral interviews are quite different; you should always use your previous experience to prepare for behavioral scenarios. You should polish your answers while speaking about the different behavioral scenarios, but that is the only place the prep ends; you need real-world experience to back up your answers.

The interviews are taken by Engineering Managers generally(at least for the FAANG companies), and they value genuine answers from candidates. Most of the time, some of the questions are constructive; it is easy to talk about the positive aspect of any experience(much easier to focus on the good parts that went). The real challenge lies in sharing the uncomfortable events, parts talk about your indecisions, your failure.

EMs like to see how you foresee failure; how you define ownership, and how much of the failure you own. It is easy to delegate responsibility to someone else, and in some cases, it might be true as well. But you should be aware that any failure, be it due to your fault, or someone else, affects you after all, how you might have ownership of the failure, and how you plan to overcome and improve yourself. That is where the real challenge lies, as you accept part/full ownership of the failure, and how you can foresee yourself finding a solution, rather than blaming the situation/people, and doing nothing about it.

You should be genuine throughout the process. The dispersal of information is something that you should work on, and the content is your entire technical career beforehand. I used my relevant internship experiences and my time with KOSS, serving college folks with knowledge about OSS.

In case you don't have relevant experience to talk about, you can use fair reasoning and logical-sounding arguments to answer behavioral questions. Again, you should mention the interviewer about the lack of relevant experience for a certain question, and they would be happy to calibrate the expectations or change the question.

I found this video very powerful and succinct in how we should go about behavioral interviews - Jackson Gabbard's Video - link. The guy talks about all the points in detail, and one of the goto videos while suggesting to anyone about behavioral interviews.

My 2 points

I like to frame all of my answers in a story mode, where I explain the context, before diving into the content. People like to listen when the entire answer is packaged as a story. Add a flavor of genuinity while talking; you can laugh or express unhappiness over a small aspect of your story. It makes the interview relate to your experience more empathetically.

My Entire Google Interview Experience

Instead of talking about the different Google interviews I had(2019, 2020 for SWE Internship in Google NA, 2022 for SWE-SRE role with Google EU), I thought of talking about the difficulty level of interviews, and all the topics used in the Algo/DS round.

Difficulty Level

• Most of the interviews required you to be fairly equipped to solve Leetcode Medium problems in 15-20 mins(including dry testing the logic), and Leetcode Easy problems in 5-10 mins.

• LC(LeetCode) Easy problems are often included as warmup problems, so it is imperative to complete and get ahead of the problem as soon as possible.

• You should not rush though, I often used to read and understand the problem while taking 2-3 mins. It is easy to lose track, once you have someone breathing down the neck, so consider practicing mock interviews in a time-simulated environment.

• Reading the problem helps you cultivate the logic much quicker, and instead of rushing through pre-assumed constraints, make sure you repeat to your interviewer the logic that you have in your mind, and if you are solving the same problem, which has been presented to you. Often you can start solving some problem, which is different from what was asked. Take your time and repeat what you have understood from the problem, and if both of you are on the same page.

I recall one of the interviews from my internship, where I had spent close to 10-15 mins, without solving a single problem. That was a LeetCode Hard problem(as I feel xD), and understanding what the interviewer was looking for was the trick. I had to use some bit manipulation(which boiled down to using simple bit manipulation tricks to solve the problem), which was made difficult because the problem statement was vague. It is important not to lose composure, and instead of already giving up, make sure you try to salvage the situation and keep persisting. It's the interviews like these, that make Google's Interviews very challenging.

• Often as you would find, solving the problems of Algo/DS contains 60% thinking, and 40% writing code. Thinking and cultivating the solution is by far one of the most challenging aspects of the interview, so you can cover up for the lost time, by writing up code in a fairly fast way.

Writing code can be practiced, and you can make sure, it doesn't take a lot of time to convert your ideas to code. There are some templated ways to go about solving the problem, make sure you don't falter on them. For example, there are different variants of Binary Search; you should have a fundamental clarity of how binary search works, and be able to write up the bug-free binary search, without spending a lot of time. All it takes is a hell lot of practice and using the skills in a new place. Try taking part in contests, those are one of the best places to work on coding + thinking skills.

I often used to write up code fairly fast, e.g. writing up DFS, BFS, and Dijkstra's Algorithm without a lot of thought. You can practice them to prepare for the boilerplate code, and spend the rest of the time formulating the actual logic of the problem.

• Using Encapsulation while solving problems - Encapsulation is a concept from Object Oriented Programming, which makes sure, you hide a fairly complex logic in a black box and work accordingly. I often used verbose but small function names, which were commented to summarise the problem that would be solved. I often used to communicate to my interviewer about the function, and that I would fill up the function later on.

This gave me the flexibility on focussing on the higher-level logic of the problem while making sure I can take care of the lower-level logic later. This gives me the clarity of the higher level solution, and once I am happy with the higher level logic, I can quickly move on to the lower level logic function. This is the onion peeling technique, you peel more layers once the outer layers have been consumed.

This also helps, when the interviewer has follow-ups, and if your code is modular, you can introduce more constraints to your problem, without re-writing code.

• Use a less verbose language, preferably Python - I used to work with C++, but switched to Python because of its simplicity and few lines of code for the same logic.

Topics used in the interviews

Google's interviews use a mixture of beginner and advanced topics of Algorithms and DS. Most of my interview experience used the following topics -

• Binary Search
• Array Manipulation
• Graphs
• Bit Manipulation

Closing thoughts on Google

Google by far has been one of my favorite companies to apply for; the interview process, though difficult and a bit irrelevant, is one of the fairest ways to evaluate candidates. Coupled with the transparent interview experience, and the best-in-class recruiter experience(all of my recruiters were nice, so a big shout out to them!), it is a really good choice for cultivating an SWE/SRE/DS/MLE/RS career.