A couple of months ago I had two separate Google interviews over the course of two weeks and got rejected from both. Apparently, I am not the best person to offer advice but, after reflecting on the interview moments, I realized that I made some tactical mistakes. I would like to share them with you, along with some tips I found useful, to help you increase your chances on that first technical phone interview:

  • Prepare, but don't overdo it. Keep in mind that the time is strictly limited to 45 min - 1 hour max. The questions at this interview stage generally examine your understanding of basic data structures and algorithms, your ability to think on your feet and typically are not too complicated. Remember, this is only the first technical interview; if you succeed, you will visit Google offices for 6-8 hours for a more in-depth assessment of your skills; you can prepare on more advanced topics later on. My mistake was that I tried to cover the entire interview material, from OS internals to more advanced data structure implementation (e.g. tries), when I should instead exhaust all available programming questions on simpler topics (linked lists, binary trees etc.). Be patient and focus on winning this first battle.

  • Understand algorithm complexity. You will most likely be asked on Big-Oh notation. If you haven’t already, get a copy of Skiena’s excellent Algorithm Design Manual. I could talk for hours about this book, it truly is a gem. Devoid of intimidating mathematical formalities, Skiena gets to the point from page one and presents, in a very enjoyable and, often witty, writing style, the theoretical framework and tools that will make you a better engineer. On the negative side, the C implementations of several algorithms do not follow a consistent style (thus making them hard to read), the naming of variables is often cryptic and there are occasional bugs. Make sure you study having the book’s errata nearby.

  • Study all basic data structures (arrays, linked lists, stacks, heaps, priority queues, hash tables, binary trees etc.) in depth. Know their traversal/manipulation algorithms. Github is your friend: experiment with your own implementations or, even better, be social and contribute to other repositories!

  • Master recursion.

  • Study sorting algorithms, namely Heapsort, Mergesort, Quicksort, Selectionsort, Insertionsort and friends. Study them, learn their complexity. Implement them from scratch. Which algorithms can be used on lists? Which on arrays? Which on both? Is Quicksort stable? Know their strengths and weaknesses and how they compare to each other.

  • Testing: Be prepared to answer questions on how you would test your code. Be precise and pay attention to detail when describing your test cases.

  • Use a language that you are very comfortable with. Ideally, one that will also give you speed of development. If in doubt, don’t use C. I made the mistake of choosing C on both interviews. On my first interview I presented a complete solution in 40 minutes and then chatted with the interviewer for the remaining 20 mins - he was a vey cool guy by the way. Had I used python, for example, I would likely have finished faster and have more time to work on an extra problem. In the second interview, I got trapped into some silly pointer bugs and ran out of time. When using C, you start at a disadvantage, because you have to do one more thing: memory/pointer management. It simply is not the right tool for this job. Also, why are you still programming in C? It’s 2015!

  • Practice, practice a lot! Google and other big companies outsource their initial technical interview to platforms like Codility, so getting familiar with them is a good idea. I also highly recommend working on the questions from the noteworthy tech interview book, Cracking the Coding Interview. Last but not least, remember that Google interviews are conduced on a shared Google Doc. You will probably be already stressed, so don’t let this be another distraction; spend a few days before the interview coding on Google Docs and getting used to it.

  • Think out loud. This might seem unnatural at the beginning, but is really important. The interviewer can’t read your mind and has limited time to assess both your technical and soft skills. Discuss your proposed solution before writing a single line of code. Talk throughout your implementation and try to be casual about it. If you get stuck, chill-out, don’t panic, talk to your interviewer and don’t give up. I was particularly concerned with this aspect of the interview beforehand, but it went pretty smoothly and I actually enjoyed the whole process.

Am I wasting my time? Why study algorithms at all?

There is a long-standing debate on whether studying CS fundamentals is a waste of time or not, given that in your normal everyday job you will never have to implement, say, a Red-Black Tree, from scratch. Recently, a tweetstorm followed a tweet by @mxcl after he had an unsuccessful interview at Google. I was especially intrigued by this case since @mxcl is a well-known developer who has created some very successful open source projects, like Homebrew and PromiseKit for Swift. This particular case seems like a false negative, and false negatives do happen (for the record, @mxcl later got hired by Apple).

The process is far from perfect and it seems more like a character test, by demonstrating that you have the discipline to work towards reaching the bar set by Google; it only requires time, you don’t have to possess any superhero powers. More importantly, there is another advantage, regardless of the result. The process of studying algorithms and data structures will up your game as a developer. The theoretical foundations will help you grasp new concepts faster, making you flexible and adaptive in a software ecosystem that evolves at a crazy fast pace.

Additional resources

Closing words

The Google interview process is an unexpectedly fun experience and, regardless of the result, you are going to learn a lot. The worst case scenario is that you will sharpen your skills. Just go for it!

Don’t be shy; share your thoughts and experiences in the comments below or ping me at @kwstasl.

Edit: This post also appeared at Medium