Table of Contents:
The following notes reflect some of my personal thoughts on applying to Google, where I’ve been working since July 2020. These notes are best suited for junior developers - for instance, the notes don’t include any advice for a System Design interview, because that is only given for applicants with experience (which I wasn’t at the time).
Disclaimer: these notes in no way reflect Google’s position on the matter, and only represent my personal opinions.
First, I strongly suggest applying for companies besides Google as well. The reasons I recommend applying for several companies are:
Have Alternatives: Don’t put all your eggs in one basket. First, nothing guarantees that you’ll be accepted to Google, and I’m assuming your ultimate goal is to get an interesting and challenging position. You should apply to your top 4 companies. Be open to being offered a more interesting job in your 3rd choice, and don’t let Google’s brand be the sole deciding factor. Also, be respectful of interviewers’ time, and only interview at places you would actually be pleased to accept a position in.
Negotiations: Even if you get into Google, you’ll want to negotiate your conditions. How much negotiation experience do you have compared to Google’s recruiters? Basically, none. Even if you think you’re a good negotiator (e.g. with your siblings, with your friends), remember that company recruiters do this full-time.
Thus, your best shot at negotiating is simply stating the offers that you have received from other companies. Having alternative offers ensures that you won’t fold on your demands (because these are real terms that you’ve already been offered). Google’s recruiters will sense that, and put more effort into securing you a better offer. Of course, even if you don’t have other offers, negotiate and ask for a little more than what you’d be happy with.
Interview Experience: Interviewing is a completely different ball game than taking a test. In an exam, you have time to reflect on questions, take 10 minutes to breath and overcome your nerves, and sketch out possible answers in any order you fancy. In contrast, during interviews you need to think on the spot, out loud, and start offering ideas almost immediately. Combine that with nerves, and you get a good recipe for freezing on the spot (this definitely happened to me).
For this reason, I would recommend interviewing with several companies. You’ll habituate yourself to the interview environment and gain valuable practice in verbal communication.
The interview nerves discussed in the previous section lead me to strongly suggest you find people to do mock interviews with before approaching any company. There are 3 avenues I would recommend for mock interviews, each one having its unique benefits:
With friends: The advantage of having a friend interview you is that you’ll probably be slightly more relaxed, since you know your friend appreciates you and won’t judge you harshly for mistakes! Another benefit of having a friend interview you is that they’ll probably be frank and honest in their feedback.
One thing to make sure your friend doesn’t do though is be too supportive: smiling, nodding in encouragement, etc. This is especially important for Google interviews, since Google interviewers are instructed to keep poker faces - so, make sure your friend interviews you without providing a lot of guidance.
In my experience, the Google technical interviews aim to check 3 qualities in (junior) software developers:
The resources that helped me the most, and which all proved invaluable:
This wonderful book covers almost all the theory you need in order to understand the standard data structures and algorithms (notably, it’s missing information about Tries; I’ll detail resources for that below). However, note that some of the book’s data structure implementation details don’t correspond to those normally provided in interviews:
heapDecreaseKey()). If you’re coding in Python though, there is no easy way for you to track an element’s index in the array. In fact, the standard Python
heapqlibrary doesn’t even provide a public interface for updating an element’s value. If you’re given a problem in which a heap would have its elements periodically updated, then if you’re coding in Python, you should either state how you would implement this functionality on your own, or perhaps opt for another language.
parentattribute, and this simplifies many tree operations, such as CLRS’
getSuccessor()function. In interviews, this attribute often does not exist, so I would strongly recommend understanding how to implement all the standard binary tree operations for two separate cases: one when nodes have a parent attribute, and one when they don’t.
This is the book that truly got me excited about using data structures (and reviewing their theory again). It’s a long book, and I don’t think you need to read all of it (I didn’t). By reading the author’s algorithmic “war stories” from real-world businesses, I finally internalized how crucial the correct choice of data structure is, and how interconnected it is to the choice of algorithm. Among the book’s highlights:
This book is indescribably useful in learning how to approach an interview question. The book details the crucial steps in tackling a problem:
Ask clarifying questions, clear up ambiguities, and check assumptions.
For instance, ask (1) how the input is stored, (2) how to handle edge cases, (3) if the input fits in RAM, (4) if access patterns are uniform (e.g. for a database, perhaps read operations occur a lot more frequently than write operations). Ask: are strings made up of ASCII or unicode characters? If multiple solutions exist, which one should be returned, if not all? Can I assume the input is valid, or should I check it first? Can I modify the input, or is it immutable?
Leetcode is an amazing resource for practicing coding interview questions. I personally felt that Leetcode’s question style was quite similar to many of the questions I received at interviews. In addition, I liked the fact that Leetcode’s questions are succinct in comparison to other sites, such as HackerRank. (Side note: HackerRank’s lengthier problem statements are a good resource if you need to prepare for a coding home assignment).
Leetcode offers detailed solutions to many of its problems, and the forums are also a wonderful source of information (for instance, see this post on dynamic programming patterns). I learned how to nicely code Tries on the platform, and the ability to filter problems by corporation, by difficulty level, and by topic was immensely beneficial. I felt that the Google questions I was asked corresponded to easy and medium on Leetcode, so those are the ones I would recommend spending the majority of your time on.
For concrete technical advice, please see my next post.