Hello! This is part 4 of my Google Interview series. If you want to start from the beginning, here you go.
In my last post, I talked about how I had passed the phone screening and was moving onto the onsite interviews. In this post, I talk about how I prepared for the onsite interviews.
After a call with another Google recruiter (this time, someone responsible for on-site interviews), I was given all the details regarding the interview, interview prep, and answers to any other questions I had.
Here was the rough plan of the onsite interview:
- The first interview starts at 9:45 - 10:00 AM. Come in 15 minutes early for buffer time.
- There will be 3 interviews in the morning, followed by a lunch with a Googler. The lunch is not an interview. It’s simply an opportunity to meet and talk with a Googler about anything that I am curious about.
- There will be one last interview in the afternoon after lunch.
- All the questions will be algorithm questions; system design question is not asked for University grads.
The recruiter gave me two follow-ups - a guide on how to prepare, as well as an appointment for a Google Technical Interview Coaching session. The guide was not too much different from the prep materials that I posted in my second post. The coaching session was a 1-hour long Google Hangouts session where a Google Software Engineer would share his way of acing the Technical interview. It was a group session taken with a bunch of other interview candidates.
I wanted to be bulletproof for the interview, which required me to master the following topics. I broke it down into basic, intermediate, and advanced.
- Min Heap
- Max Heap
- Linked Lists*
* be able to implement from scratch.
- Binary Search
- Bidirectional search
- Merge Sort
- Quick Sort
- Breadth First Search
- Depth First Search
- Pre-order (recursive and iterative)
- In-order (recursive and iterative)
- Post-order (recursive and iterative)
One minor exception - it’s okay if you can’t implement both merge and quick sort from scratch. Just make sure you can implement at least one of them from scratch and have a good understanding of the two, like the tradeoffs of each one. Instead of spending time on perfecting both, spend the extra time on other concepts / questions.
- Sliding window
- Dynamic Programming
- Topological sorting of a DAG
- Travelling Salesman
- Knapsack Problem
- NP-Complete concepts
- Kruskal’s Algorithm for finding Minimum spanning tree
I juggled questions from CTCI, Leetcode, and GeeksForGeeks.
- I used Leetcode most of the time
- I always carried my CTCI book around with me, and would look at it whenever I had time
- I used GeeksForGeeks whenever I needed an explanation & solution to any question, especially the advanced ones
One problem I had was that once I solved a problem and moved on, I would forget about that problem within a week or two. So for my onsite prep, I decided to create a review system. The motivation came from Dr. Barbara Oakley whose book I read in my 2nd year of University. Basically, one key habit a student must do to keep on top of his studies is to do active review.
Instead of looking over the question, the solution, and thinking that you reviewed the question, you would instead look at the question, and try to remember the solution. What were the edge cases? How did you solve it? Was there anything hard about this question?
For me, I did this by keeping a log of all the questions that I did. Their name, date, difficulty, last reviewed date, and a column to indicate whether another review is needed.
Here is a screenshot.
It’s not the most organized spreadsheet by any means, but I was able to frequently review all the hard questions and keep on top of all the different topics. By accesing this through my phone, I would look at it whenever I had time.
In the perspective of on-site interview performance, this is how I see things:
- 1 mock interview is worth like 3 whiteboard practice questions.
- 1 Whiteboard practice is worth 3 Leetcode questions.
The majority of my study was solving Leetcode and CTCI on a whiteboard while talking out loud. In retrospect, I would have liked to focus more on mock interviews. Remember, you could solve Leetcode problems like a programming god, but may screw up on communicating your thoughts properly to a person while solving a question on a whiteboard. It doesn’t matter if you are a genius in your head. What matters is what you PORTRAY during the interview session. Your best interest is to brush that performance act flawless.
Aside from having friends to help you, there are multiple mock interview platforms out there.
In my next post, I will discuss the on-site interview!