Sign in Subscribe

Interviewing at a large tech company like Google can be scary for a variety of reasons:

  • You have a general fear of rejection. Google interviews are notoriously difficult, and you believe there's a reasonable chance that you won't do well.
  • Google interviews require a lot of preparation. Preparation that you just don't have time to do.
  • You think you'll make a fool of yourself.
  • ... and a host of many other fears that you specifically might have.

I've been a software engineer at Google for a little over 3 years and this is my 3 best tips on how to do well in your coding interview with Google.

Tip 1: Prepare

Even if you ignore all of the other tips and any other advice you get from the internet on how to ace your next coding interview, don't forget this one tip.

It's the most important advice by a long shot and not preparing is just leaving everything to chance.

I have interviewed so many candidates at Google and a surprising amount of them don't know how to do a binary search or breadth-first search, and it totally kills their odds of doing well. These things are easy to pick up with just a bit of practice.

After all, this article is about swinging the odds in your favor. Naturally, the very next question people is "how do I prepare?"

The second tip will answer the question of what and how to prepare. I put this "prepare" as a stand alone tip because not preparing is precisely how I see so many candidates completely let the opportunity to work at Google slip through their hands.

Tip 2: Memorize Certain Algorithms

Many Google interviews are built off of data structures and algorithms. This knowledge is either implicitly or explicitly required. Here's a quick list of data structures and algorithms you should study and become familiar with at the very least:

  • Idiomatic dictionary / hash map in your language (You don't need to be able to implement this, but you should know about the characteristics unique to the idiomatic constant-look up hash maps in your language.)
  • Binary Search Tree
  • Queues
  • Stacks
  • Recursion
  • Binary Search (Algorithm)
  • Depth First Search (Algorithm)
  • Breadth First Search (Algorithm)

More specifically, I would recommend being so prepared on the above topics to the point where you can write out the algorithm from memory. You don't want to spend any extra effort in your interview thinking about how to do a DFS or BFS. It should be second-nature. This requires preparation and practice so you can pull it out of your toolbox at moment's notice, but it's worth the practice.

I wouldn't say these are absolutely required, but to maximize your odds, I would also study on topics like:

  • Graph traversal
  • Dynamic Programming
  • Trie

There are certainly more topics and a book like "Cracking The Coding Interview" will do a good job giving you coverage.

My universal advice for practice is to attempt one problem a day from a toy problem repository like Leetcode, and if you can't solve a problem within one session, just revisit the problem a week later and try a different problem the next day. You'll be amazed at what daily practice will do over the course of a few months.

Tip 3: Develop Good Interviewing Technique

The thing with coding interviews is that the time allocation is usually about 50% (think 15-20 minutes) figuring out a decent solution to go with and talking through the problem with the interviewer, and 50% (15-20 minutes) actually coding. This will vary from interview-to-interview, but if you're stuck in the editor for the entire duration of the interview, something's not right.

I say this because the solutions usually require a trivial amount of code to write in 45 minutes. It's usually somewhere between 10 and 20 lines of code.

In the weeds of your own code is a terrible place to architect a solution at the abstract level. If you have a habit of diving into coding before knowing how a solution generally works, stop this now. Get your head out of the editor and let's revisit the approach. Here's a quick rundown of techniques that I find helpful:

  • Develop a curiosity for difficult problems. Google interviews are notoriously challenging and the best advice I have is to be optimistically curious. No interview problem is too hard to solve, even if you won't be able to solve it in 45 minutes. Your job is to uncover the solution as best as possible in those 45 minutes. My advice here is to see each interview problem as a challenge instead of an obstacle getting in your way to a successful interview. Successful interviews are not about knowing all the solutions but showing your ability to discover the right solution.
  • Always ask at least one question about the question. I encourage asking as many questions that come to mind. Be sure you understand the problem.
  • Mention the brute-force approach first. Put it on the table so you can fall back to it.
  • Talk about the different approaches you're thinking, and the trade-offs like time and space complexity of each approach.
  • If you can't think of any optimal approaches beyond the brute-force approach, that's okay. Admit that you're having trouble thinking of a more optimal solution and ask whether the interviewer thinks the sub optimal solution should be implemented or not.
  • Talk through the algorithm before implementing it. If you can't talk through an idea of what the algorithm is accomplishing, this is a sign that you don't know how to solve the problem yet. It's probably best not to proceed until you have a better grasp of how you will solve the problem.
  • If you get stuck, it's okay to admit that you're stuck. It's better than spending time twiddling your thumbs. Get the interviewer's help to get back on track.

Bonus Tip: Get Good Sleep and Exercise Before Your Interview

This is generally good interviewing advice, and it applies to software engineering interviews as well.

Happy studying!

3 Tips On Coding Interviews From A Google Engineer