My Google L4 interview experience
3 Years ago I applied to Google and was rejected immediately after the phone screen. Fast forward 2022 and was given another chance to re-interview. Here’s how the entire experience went.
Quick Background
I am currently a junior level software engineer at Microsoft (L60) with previous experience at Amazon (SDE I). My tenure is 1 year at Microsoft and 1 year at Amazon.
The first time I applied to Google was fall of my senior year of college at NYU. I failed the phone screen horribly and never thought I would join a company as competitive as Google. But I did not want to count myself out before even interviewing.
Recruiter Screen
I slowly built my LinkedIn to make sure recruiters would notice me whenever I wrote a LinkedIn post. With 15,000 followers at the time, it wasn’t too difficult to have one of them reach out with the chance to interview. A message came in my LinkedIn inbox and I responded promptly to schedule the initial recruiter call.
The chat was focused more on my previous experiences engineering and some of the projects I worked on. It was important to talk about what languages I was using and how much of my day was spent coding (70% of my day at Microsoft).
The recruiter was interested in having me follow through with a full-loop and asked when I would like to go through the process. It was important to me to ask what engineering level I was applying for. He shared it was L3/L4 role where the interviews would calibrate me depending on my performance. Knowing that, I mentioned I’d like to interview 1 month later and asked what the process looked like as explained to me.
- Technical Phone Screen
- 6 Hour Virtual On-site a. 4 Technical Coding Interviews or 3 Technical Coding Interviews + 1 system design b. Behavioral “Googliness” interview
Phone Screen
Following the initial recruiter phone screen, I received an email from Google. It explained that I would be exempt from the Google Technical Phone Screen.
Why? I am personally not sure but it likely had to do with prior experience at large technology companies. I was personally surprised because to this day my first Google Phone Screen is still one of the toughest coding interviews I have ever been given.
It looked like that was as relevant as my current work experience and I didn’t have much to complain about moving quicker through the process and directly on-site.
Technical Onsite
Every coding question I had was a coding question that was either on LeetCode or could be solved with the patterns you find solving coding questions. Here’s what my experience for each of them looked like
Coding Interview #1
The interviewer looked like someone who was my age and likely joined Google directly after university. Maybe I wasn’t jealous. Maybe I was.
The question I was given was a string parsing Hash-Map question. Easily doable if you worked through a few medium questions regarding hash-maps and string parsing. But if you’re not careful, you may have fallen into a common trap.
Let me point it out for you. Abstract away the logic for tedious parsing logic by writing something like “parsingFunction()”. Otherwise 30 minutes may pass without you solving the question. I wrote a short “ToDo” mentioning I’d come back to it if the interviewer cared.
Spoiler: The interviewer didn’t care.
They lastly asked me to optimize with a heap and what the running time was. Unlike others who assert the running time, I solved for it and the interview concluded there.
Coding Interview #2
The interviewer who was more senior than the previous interviewer. I heard the coding question and thought the on-site was over.
The thing about some coding questions is whether you see the pattern for the algorithm or not. The recognizing the pattern for the algorithm can be much more difficult than actually writing the code for it. This was one of those interviews.
After hearing the questions I was thinking of ways to brute force the question or if there was a pattern I could see using smaller test cases. I wasn’t able to recognize it and eventually the interviewer told me what the pattern was.
I tried not to come off embarrassed but followed up with the algorithm to implement that pattern and the interviewer gave me the “go ahead” to code. I finished coding the pattern and answer the follow up by the interviewer on how to make my code modular to handle another requirement. This did not require implementation.
Afterwards was a discussion on time and space complexity and the interview was over.
Coding Interview #3
The interviewer was a mid-level engineer who was not as keen on chatting as much as the interviewers.
Some coding interviews are just one interview where you have to get the question correct or not. This one started off easy and iterated to be tougher.
My quick advice to anyone is to never come off arrogant for any coding question. You may know the question is easy and the interviewer likely does as well. Often times it’ll get harder and all that ego will go out the window. Go through the motions and communicate you always do for any other coding problem.
The problem given was directly on LeetCode and I felt more comfortable knowing I had solved this awhile ago before. If you’re familiar with “sliding window” then you more than likely would be able to solve it. But here’s where the challenge was.
After the warm-up question, the follow up had another requirement on top of the previous question. That follow up was more array manipulation. Finally the last iteration was shared.
I implemented the algorithm where Math.max was being called more than necessary. To me it didn’t affect the output of the algorithm and looked like it didn’t matter. But it mattered to the interviewer. I took that feedback and carefully implemented it the way the interviewer asked me to (whether it actually affected the algorithm or not).
Time and space complexity was solved and the interview was over.
Coding Interview #4
This was another interviewer who had joined Google after university and had the same work experience I did.
This prompt was not given to me and I expected I had to write down the details to the question myself. After asking some clarifying questions on what was and wasn’t in scope, I shared my algorithm.
The question was an object-oriented question to implement a graph. If you had taken any university course on graph theory, you would be more than prepared.
The interesting discussion was whether I had to implement the graph with BFS or DFS and explain the pro’s and con’s of each. Afterwards, I decided with BFS (because BFS is easier for me to implement) and the requirement followed up with taking K-most steps iterative.
I’m not sure if that’s the follow-up because I implemented it in BFS or if that was always the follow-up but I quickly adjusted the algorithm and solved for space and time complexity as always.
The Googliness interview
Googliness is just Google’s behavioral interview. Most questions were along the lines of
- Tell me about yourself
- What’s a project you worked on?
- When was a time you implemented a change?
- When was a time you dealt with a coworker who wasn’t pulling their weight?
To prepare for these, I’d recommend learning about the STAR format and outlining your work experiences if you can recall them before interviewing.
This seemed to go well but then I was given a question I didn’t expect. A product question and my thought process on how to work with teammates to answer the question.
My key point of advice: Nothing matters if the user doesn’t want it.
Emphasize how important user research is to build a product that a user will use otherwise everyone’s time could be better invested in other initiatives. Avoid jumping straight into designing the product and coordinating talks with product managers and UX designers.
Offer
2 weeks later, an informal offer was shared with me in my email.
Most of the interview didn’t not pertain to my previous experience directly. A systematic way of approaching, communicating, and implementing coding problems is enough without experience from Amazon/Microsoft.
— — — — —
If you enjoyed this experience consider being a member for more content like this!
Please consider subscribing to be the first to be the first to receive emails for my experiences.
The easiest improvement anyone can make interviewing is learning to communicate more.
Learn more on how I do that here
And follow me on my quest to 30,000 followers on LinkedIn Alex Nguyen | LinkedIn
Here’s the best system design resource that helped me with my interviews.
