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 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.
This was my third time interviewing with Google (each time I got a bit farther). Here's the overview.
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.
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.
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.
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.
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.
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.
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!
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)
- 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.
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
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.
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
For an accessible gist please follow this link.
Here are the skills I recommend studying for the data structures and algorithms interviews:
For an accessible version please follow this link
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.
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 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.
When interviewing here are a few general tips to ensure you perform to the best of your abilities.
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.
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.
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.
When the on-site interview finally arrives, here a a few tips to keep you grounded.
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.
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.
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.
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.
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.
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.
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.