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.