I Passed The Google Technical Interviews; You Can Too.

All of my illustrations come from UnDraw. Thank you for your work!

I pulled myself out of the Google hiring process after passing the technical interview process. I know what you're thinking: "Are you crazy?! Who pulls out of the Google interview process?"

This blog post will discuss my history with interviewing at Google as well as tips for passing your technical interview process (at any company).
Google is notorious for having difficult technical interviews, and is a highly coveted company to work for, which is why I chose to highlight it in this blog post.

That being said, there are many amazing companies to work for (some which aren't as well-known as this tech giant) and THAT IS OKAY. You don't need to work for a well-known company to be a successful developer.

Additionally working for a big company has drawbacks as well as benefits (which I'll cover in this post). Determine what you want out of a job and look for companies that emulate those core values and working environment.

I can only speak to the JavaScript/front-end interview process at Google (or any other company) and my interviewing experience might not mirror your interviewing experiences so please take my advice and experience with a grain of salt.

I won't divulge the interview questions asked during my Google interviews (or any other technical interviews) as I believe it's unfair to company. As a candidate you want to be hired for your problem solving skills and that's why I chose to highlight the skills you should study versus the interview questions I was asked.

Don't memorize solutions, learn the problem solving skills needed to build a performant solution! You can refer to the interviewing tips section for more insight on having a successful technical interview.

Lastly I just want to say thank you to the entire Google team as well as any current or former employees I talked with. My recruiters were phenomenal and every interviewer I met was wonderful to talk to. They never made me feel unintelligent and made me feel comfortable. The questions I were asked were fair and assessed skills I would encounter in my day job. And for that I say thank you.

History

This was my third time interviewing with Google (each time I got a bit farther). Here's the overview.

Round 1: 2016

The first time I interviewed was back in 2016 when I was still living in Austin, Texas. I was DULY unprepared for the technical interviews but managed to make it through the recruiter phone screen and had two technical phone challenges before I was rejected.

Round 2: 2019

The second time I interviewed with Google was at the tail end of 2019. I thought I was interviewing for a UX Engineering role on the Material Design team, however I ended up going through the full Software Engineering interview process and was a bit unprepared.

I passed the phone coding challenge and moved on to the on-site interview on the Munich campus. I had two front-end technical interviews, two data structures and algorithms interviews, and one interview centered around development process, communication and cultural fit.

One of my front-end interviews was conducted on a Chromebook over Google Hangouts and unfortunately we had technical issues (i.e. the Chromebook wouldn't start up, Hangouts wasn't screen sharing) and spent half of the interview troubleshooting. I was also told that my JavaScript skills could use some improvement.

As a result the interview was thrown out and the team wanted me to re-interview in a month or two back in Munich. At that time life was a bit chaotic and I declined to re-interview.

Round 3: 2020

Early in 2020 I re-interviewed with Google for a UX Engineering role and because I had just interviewed with them a few months prior the interview process was expedited for me (I did not have to re-do my phone coding challenge or on-site data structures and algorithms or process/cultural fit interviews).

I did a take home UX/engineering project where I designed user flows and information architecture, created high-fidelity mock-ups using Sketch, and built an app. I then documented my process and tooling selections in a succinct document.

Once past the take-home challenge I had three "on-site" interviews which were conducted over Google Hangouts (due to COVID-19). I had two front-end technical (coding) interviews and one UX interview discussing my take home project and enhancements that could have been made from a UX perspective.
After the "on-site" interviews I was informed by my recruiter (two days later) that I had passed the interviews and would move on to the hiring committee and team matching phase.

I met with a potential hiring manager to discuss the role at hand. Ironically I had met the manager during the second round of interviewing in Munich so it was nice to meet him again.

After meeting with the manager I waited for several weeks, and in the mean time continued interviewing with other companies. Unfortunately due to COVID-19 the internal hiring process was a bit chaotic and I ultimately ended up accepting an offer at another company.

I'll never know if I would have received an offer from Google, however I'm pretty damn proud of myself for passing the technical interviews. As someone who was told I wasn't good enough and felt I wasn't good enough to make it in this industry, I was proud I had even made it to the on-site interview round.

What It Takes To Get Hired

To be hired at Google you have to exhibit the following characteristics.

• Be a kind person
• Have a willingness to learn
• Have good communication skills
• Be a good problem solver
• Exhibit great teamwork
• Have empathy

Based on my experience they're not looking for geniuses, but rather kind-hearted, hard-working people with great communication and teamwork skills, and this holds true for many companies.

General Interview Process

The general Google interview process has five to six phases:

The general Google interview process has 5–6 phases:

• Recruiter phone interview
• Technical phone interview / coding challenge
• Take home assessment*
• On-site interview
• Team matching phase
• Hiring committee

* This step was only necessary for the UX Engineering role and not the Software Engineering role.

Let's dig a little deeper into each phase.

Recruiter Phone Interview

During the recruiter phone interview the recruiter will tell you a bit more about the role and the interview process. Don't take this interview lightly, however, as each step in the interview process is important and counts towards your overall performance.

Some tips for the recruiter phone interview include:

• Read up on the role and the company ahead of time
• Be on time
• Have two or three questions prepared to ask the recruiter
• Thank them for their time

Your recruiter will fight hard to get you an offer, so treat them kindly!

Technical Phone Interview

If your recruiter phone interview goes well you'll move on to the technical phone interview. During this call you'll pair up with a Googler who will give you a coding challenge question.

I had one question to answer and it primarily tested the following skills:

• DOM manipulation (accessing DOM nodes, performing some task, dynamically generating new DOM nodes)
• CSS

I coded my solution in a Google document. Here is the approach I took to problem solve.

• Ask clarifying questions: The questions are left with a few missing pieces because the recruiter wants to see how you think.
• Write pseudo-code: Writing pseudo-code allows you to get your thoughts in order before you jump into the code.
• Code a brute force solution: You don't have to code the most efficient solution first. Starting with a brute force solution then optimizing shows your attention to performance.
• Optimize your solution: Once you have a brute force solution, where can you optimize it? Can you refactor a nested for-loop into two top-level loops?
• Test for edge cases: Once your solution is working and optimized, create some test cases. These will allow you to see if you missed any corner cases.

Coding Project

If your technical phone interview goes well you may be asked to complete a take home coding project. I was not asked for a project during the Software Engineering interviews, however I was asked to complete one for my UX Engineering interview.

I thoroughly enjoyed completing the coding project for a few reasons:

• I was able to pick from two projects which showcased different skills
• I had a week or so to complete the project (although I was informed it should only take a few hours) which reduced the "on-the-spot" pressure of a coding interview
• I was able to showcase some of my strongest skills like thorough documentation, user flows, and information architecture
• I was able to pick my tech stack

You should clarify project requirements with your recruiter before diving in. For example if you want to use a JavaScript framework you should ask if this is allowed.
Some tips for your coding projects include:

• Try not to rely too heavily on third-party libraries. I chose to use Material UI, Google's design system, for the UI work because it showcased my knowledge of design systems and kept the UI consistent, however using a UI framework can have performance implications.
• Be honest about the areas you would like to improve upon. One part I always include when submitting a take-home assessment is "areas for improvement." If you had an extra few hours or weeks, what would you have done differently?
• Run you application through an accessibility tester. I ran my app through Google Lighthouse to test for accessibility.
• Don't pour your heart and soul into the project. If the recruiter says to spend 2–3 hours on the project, don't spend a week working on it. You'll burn out and feel taken advantage of if they reject you after this step (I know from personal experience.)
• Clean up your code. Be sure to remove comments and format your code appropriately.
• Think about project architecture. Your file structure should be clear and organized.
• Include setup instructions. If the person reviewing your code doesn't know how to run your application you probably won't move on to the next round.

On-Site Interviews

If you've made it to the on-site interviews, CONGRATULATIONS! This is a huge step and you should be proud of yourself!

During my second interview with Google I was able to visit the Munich campus and get a tour of the office (it was beautiful!), however during my latest interview process all of the on-site interviews were conducted over Google Hangouts due to COVID-19.

The on-site interviews consist of five rounds:

• Two front-end interviews (coding)
• Two data structures and algorithms interviews (coding)
• One process/teamwork/culture fit interview

The front-end interviews will focus on front-end technologies like HTML, CSS, and JavaScript but may touch other areas like performance and asynchronous JavaScript.

Front-End Interviews

Here are the skills I recommend studying for the front-end interviews:

For an accessible gist please follow this link.

Data Structures & Algorithms Interviews

Here are the skills I recommend studying for the data structures and algorithms interviews:

For an accessible version please follow this link

Teamwork, Process & Culture Fit Interview

The teamwork/process/culture fit interview will be an amalgamation of topics ranging from Agile methodology or workflow, teamwork and collaboration, and conflict resolution.

To ensure success in this interview here are a few tips:

• Have two or three projects you can discuss.
• Have 1–2 team conflicts you were able to resolve.

Team Matching Phase

If you complete your on-site interviews, you've passed the hard part! Some candidates move directly to the hiring committee but some candidates go through the team matching phase.

In this phase you'll meet with prospective managers and discuss the team you'd be joining and the type of work you would do.

If a team wants you, they'll tell your recruiter and it will be added to your portfolio which will then be submitted to the hiring committee.

The Hiring Committee

The hiring committee is the last phase of the interview process. From my understanding the committee is comprised of several Googlers who review a candidate's performance throughout the entirety of the interview process.

In the day or two leading up to the hiring committee meeting, the reviewers read the candidate's packet and makes a recommendation on whether or not to hire the candidate.
At the meeting the reviewers discuss their feedback and if all members agree an offer will be extended.

I never received feedback about the hiring committee feedback, as I pulled out of the process before receiving it, so unfortunately I can't speak to the statistics of receiving an offer after going through the hiring committee.

Learning Tips

When interviewing here are a few general tips to ensure you perform to the best of your abilities.

Do a little each day

Although it might not feel like you're making huge strides, small bits of information compound to achieve amazing results. I love the book Atomic Habits by James Clear which dives into this idea more in-depth.

When you do a more focused amount of learning each day, you have a lower risk of burning out, and gives your brain more time to process the information you've learned.

Mix learning with doing

You can learn all the skills in the world but if you don't apply them to various projects you'll have a harder time using them in an interview. I recommend learning a skill or two and then finding an example application to utilize them in.

Learn to read other peoples' solutions

Your solution might work and might be optimized, but it's always a great idea to read other peoples' solutions and understand how they think. You might find a more performant way to complete a task, but in general learning to read code is a wonderful skill, and a necessary one, to have.

Interview Tips

When the on-site interview finally arrives, here a a few tips to keep you grounded.

Drink water

Having something to drink will provide you with a moment to catch your breath and relax. Your interviewer should ask if you'd like one but if they don't you're welcome to ask.

Ask clarifying questions

White-boarding questions are purposefully left with a few holes because the interviewer wants to see your ability to problem solve. If something seems unclear, it probably is! Write down the things you know and deduce what you don't.

Brute-force then optimize if stuck

If you have absolutely no idea where to begin, start with a less-performant solution; you can optimize later.

For example if you're asked to search for a number in a sorted array and return true if it exists, you can always start with a for-loop that iterates through each index and returns true if the number is found. In the worst-case scenario this leaves you with O(n), where n is the length of the array, because we're checking every single element in the array.

Further along in the interview you might realize "oh the array is sorted! I can use binary search to find the element!" Binary search is a wonderful divide and conquer algorithm that repeatedly searches for the target element by reducing the size of the array each time. This might end up being a more performant solution.

Speak your thought process

The point of the interview is to see how you think, so you must speak your thoughts out loud! Your interviewer can't read your mind.

If you're stuck between two solutions, tell your interviewer and explain your reservations about both. They might be able to put you on the right track.

Test your solution

Once you have a solution and you've optimized it, it's time to test. Many candidates forget about testing but this is a vital part of a coding challenge. Your solution might work for 75% of test cases but forget to account for the other 25% of edge cases.

Testing your solution is a must in an interview.

Don't rely on tooling

Google typically uses word documents or a plain text editor for their coding challenges so don't rely on linters or Prettier to format your code. Learn to write code in an environment without tooling.

Final Thoughts

Google isn't the "be-all-end-all" company to work for. You might not even enjoy working at a large company!

The most important thing to remember when interviewing is that this is a two-way interview. You're interviewing the company as much as they're interviewing you.

The skills you have are valuable and even if you get rejected it doesn't mean you're not good enough.

We all get more rejections than offers so hang in there.

Comments

[Gergely Orosz]

This is a nice overview of the Google interview process - thanks a lot, Emma!

As a hiring manager now at Uber including for frontend, and talking with several other hiring manager friends at other larger tech companies (Amazon, Facebook, Netflix etc) the frontend interview process is not too different for larger tech companies and the tips shared here would apply at those places as well.

Some places - like Amazon or Uber - also have a Bar Raiser round onsite, that is similar to the "Teamwork, Process & Culture Fit Interview" described here.

The main suggestion I have for anyone preparing for interviews is to go back to basics on web development basics (like the topics Emma listed very well on the Front-End Interviews) and to spend time to prepare for data structures interviews and solving simple - not necessarily tricky - algorithms questions. Most places don't ask this to test if you have advanced algorithm knowledge. They do this, to see how you can map a problem, turn it into code with a simple solution (the brute force solution), test it, and potentially optimize it. This, second part is something that most people would fail without preparation upfront - preparation that will be useful for the rest of your career, I would add. I would not go deeper than the topics Emma listed: but, I would go deep into them and master these tools. So e.g. being able to implement a BFS or DFS (breadth-first-search or depth-first-search) is something almost all places will expect people to be able to write working code for, if asked. BFS and DFS is especially true for Google, where trees and graphs are a bit of the DNA of the company.

Thanks again for this great overview!

[Gábor Soós]

I always wonder why data structures/algorithms is a necessity for almost all places...if you need them, you read/learn/use them. I don't feel any less of a programmer not being able to implement them in minutes, except for the brute force 🤓

[Gergely Orosz]

I think you misunderstand what I meant by you need to know data structures and algorithms. Where I work, we don't ask you to implement any of these on interviews (some companies do ask this - though a lot more are turning into more practical problems). You need to know them, to be able to solve the type of coding problems that can be understood in 5 minutes and solved in 45 minutes with no framework dependencies. So things testing your problem-solving skills. Though when I learned about them, I implemented them for fun - as they're all pretty simple ones, and it's a fun little challenge to do so.

For places like Google and the like, to pass the interview process, you most likely need to prepare for these - become familiar with how the structures work, cases where they are good solutions, and if you're curious, looking into real-world examples where they are used (e.g. do you know what tree structure is a very popular to use for SQL database indexing and why? It's interesting to learn why and how).

Not knowing these doesn't make you a worse programmer. But you'd probably do worse on the interview than the many other candidates you're competing for that same position at these places where it's competitive to get through each of the rounds, and then getting an offer.

[Gábor Soós]

I see, but one thing is still not clear.

What is the extra information an interviewer gets from the candidate if he/she solves a problem with this lexical knowledge or another one where this knowledge is not needed?

[Giuliano Roberto Pinheiro]

I think the main point comes from showing you know something that is easily testable (as algorithms and compleity analysis surely are) for your interviewers, you know?

The point, IMO, is not that you have to know them by heart because that is a skill you gotta know at any given moment. It is the process of learning and the growth that comes from it, and the specific areas of your reasoning those subjects encompass, that they should be trying to test.

In other words, as one of my teachers in primary school used to say: we are not here to teach you History or Mathematics or Chemistry, you're not gonna need all that. We are teaching you how to think, and each one of us [professors] is doing it the way he/she knows best.

[Emma Bostian ✨]

Wonderful comment Gergely! Thank you!

[Madza]

One of the main cornerstones, that later dictates the success of the company, is the hiring and ultimately the people you let in. Many of the companies focus all the resources just to get max profit in production, not focusing enough on step one. Google and other large companies know that, so they invest a lot of money to really filter the best.

With that being said, this would also be a nice insight for people looking to start their businesses or managers looking to improve their hiring process. Nice read, Emma :)

[Aki Seppänen]

IMO

Getting only the best of the best of the best with honors leads to a lot of frustration when the ultimate masters of coding have to do the basic grunt work that is 95% of real coding work.

Also having people jump through multiple hoops in their free time is also not a very compelling proposition for a lot of developers. I think it attracts certain types of people and not necessarily always the best of the best.

edit. So maybe my two arguments partly cancel eachother out :)

[Emma Bostian ✨]

Thanks!

[Shannon Crabill]

Oh this is great, thank you for sharing what the process looked like on your end.

In your case, were all the roles you interviewed for meant to be located on-site (the Munich office, for example, or another other Google office)? I've been curious if Google is considering permanent remote roles for front-end, etc.

[Emma Bostian ✨]

I don't believe they do remote but I'm not 100% sure :)

[Frank Szczerba]

No remote for most tech roles, except that now we're almost all remote. It will be interesting to see how things change once we go back to a new normal.

[Ben Greenberg]

Wow, what an amazingly thorough overview of the interview process! Word on the street is you are preparing a book on this very subject if this article is any indication, it's going to be a "must-have" when it comes out!

[Emma Bostian ✨]

Thanks Ben!

[Abdur Rehman Khalid]

Excellent Overview and Nice Way of Sharing the Experience of Hiring Process Adopted by Google.

Thank you very much for sharing your experience as well.

That post was a very nice read, looking for learning more from you.

[Gerard Klijs]

Thanks, it's a great overview. Really great to share the process to such degree. For myself I'm almost sure I don't want to work for Google. So far the smaller the company, the more I liked working there. But it might be a bit of coincidence.

[Alex Chiu]

Wow,the interview sounds really tough, so congrats for getting all the way through!

Do you have an resource recomendations for learning data structures and alogrithms for the things listed above?

You are absolutely right about not spending too much time on take-home projects. I had this experience recently where they said I should'nt spend more than 1 hour on it. But the problem I had nothing to show after 1 hour. I then proceeded to spend my entire weekend on it becasue I didnt know when to stop... @__@

[Emma Bostian ✨]

Yep I'm writing it now! gum.co/aUVXY

[Vaibhav Khulbe]

First of all a BIG CONGRATULATIONS passing the technical interview! 🎉

Thanks for putting all those interview processes in a concise way also those bullet points and images in between will definitely help. I've subscribed to your newsletter on compiled.blog.

Good luck with your future and stay safe! :)

[Emma Bostian ✨]

Aw thank you!!

[David Makogon]

This is a great read. Lots of insights and great suggestions.

While Google's interview process might not be the same as other companies, your experience (and writeup) highlighted many takeaways that (in my opinion) apply globally and are beneficial to anyone preparing for a tech interview, two of which I think are absolute standouts:

• asking clarifying questions. This is a big one, for me, especially when given requirements that are incomplete (which sometimes happens intentionally).
• speaking your thought process. Sometimes there are many ways to answer something (often based on our own experiences), and speaking out loud, as we work through a problem, gives the interviewer a peek inside our brains to understand context.

Thanks for sharing.

[Emma Bostian ✨]

Thanks David!

[Adeyemi Biola]

Thanks Emma for sharing your interview process. I imagine this process is not peculiar to Google and some of the tips you shared are useful for most interview process. Being a starter in the Dev-sphere, these tips will be useful as I prepare for what is ahead and even concentrate on my path(process) in the present.

I would like ask; how important is typing skill and speed in the context of interview and web-dev-sphere broadly ?

Thanks

[Emma Bostian ✨]

I don't think it's super important but every interviewer is different!