This article outlines the process I used to prepare for my Google technical coding interviews. I had interviews for a Summer 2019 internship and then further interviews during my internship for conversion to a full-time role. This led to an offer to be a full-time Software Engineer at Google to start in 2020. In this article, I'll go through the straightforward method I used to approach coding questions, and give pointers on what topics to practice.
A little about me: I am currently a Computer Science PhD student
in the UK and learnt to code around 6 years ago.
Before the interview
- Know
your data structures - You should have a grasp of the following
data structures: Arrays, LinkedLists, Maps, Stacks, Queues, Trees,
Tries and Graphs (possibly Heaps too if you have done the
others). What is the time complexity to add and remove elements from these
data structures? Which data structures are cheap to expand when you don’t
know the number of elements? Try to know these data structures inside out.
In that way, you won't need to memorise time complexities of basic
functions, but can work them out on the fly.
- Big
O - You need to be comfortable in analysing the running time of
algorithms using 'Big O' notation. A great introduction to this can be
found here.
- Sorting -
What is the time complexity of sorting an array? How would you sort a
list? Don’t forget the basics like these. Although it is unlikely that you
will get a question that directly asks you to implement merge
sort or quick sort, it is possible that a different question
could be solved elegantly with just a tweak to one of these algorithms.
Additionally, sorting can form part of naive solutions before moving on to
a more complex solution.
- Recursion -
Unless this is something you use every day it can take you a little while
to wrap your head around it. But, like data structures, recursion is
a technique well worth getting comfortable with. As a starting point, try
comparing iterative and recursive solutions for something
very simple like calculating Fibonacci numbers.
- Dynamic
programming - Dynamic
programming questions usually take longer to code and for this
reason tend to come up less frequently in time limited interviews. You
should understand the concept in case it does come up, but if your preparation
time is limited then I suggests practicing this after you have mastered
the other points above.
- Practice,
practice, practice… - Use the framework described in the next
section to practice coding questions. If you are applying to Google, also
practice your coding in a Google Doc as this is what you will do in
interview. Some great resources for coding questions are HackerRank and CodeJam. Another great resource is LeetCode which lists
its questions by topic and difficulty. Start off with easy questions, and
continue until you are comfortable with medium difficulty questions.
- Practice
what you are bad at - A really useful process for me was to
practice what I was worst at each time. For example, if Trees really
aren’t your thing then try to purposefully tackle Tree
questions until you are comfortable, then move on to your next worst
thing, and so on.
During the interview
In the interview you may be given the choice of coding on
the whiteboard or on a laptop. Choose whichever suits you, but make sure that
you have practiced using that format.
You will be given the outline of a problem to solve using
algorithms and data structures. This coding question approach is broken up into
four steps: Understanding, Solving, Coding and Finishing.
Step 1. Understanding
- Ask
problem-specific questions - What is the overall objective? Are
the numbers integers or floats? What are their bounds?
- Ask
what to return - Should I return the number of times this occurs?
Should I return whether this is solvable? Should I return the minimum
number of moves to solve this?
- Talk
about edge cases - What should I return if given an empty array?
What would you like me to do with a negative entry?
Step 2. Solving
- Talk
through your thinking - This is an absolute must. Get comfortable
with saying your inner monologue out loud while answering questions. It
lets the interviewer know you are thinking about the right things. Also,
it can help you to be steered back on course if your interviewer thinks
you are going in the wrong direction.
- State
naive solution and runtime - This can be as simple as saying:
"A naive solution might be to start at each element and then search
through all other elements to find their pair. This would be an O(n²)
solution."
- Get
a better solution and runtime - This is where practice comes in.
If you make sure you have seen a wide variety of problems before the
interview, then you will probably have seen something a bit like your
question before. Use that knowledge to start to piece together a solution.
You also know you are looking to achieve a better runtime than your naive
solution so use that information to your advantage. You will get hints
from the interviewer as you go along - use these hints. The
interviewer knows a good solution for this problem and is trying to help
you make your way to it.
Step 3. Coding
- Be
methodical - Try not to go too fast and get your code in a
tangle. If you prefer, you can write down the structure of your answer in
comments and then code step by step. Find a style that works for you,
practice it, and then use it.
- Leave
comments - If you don’t want to deal with an edge case now (e.g.
what to do if given an empty array) then leave a comment. This lets the
interviewer know you have not forgotten about it.
- Prioritise
finishing the coding over quality of code - An example of this
would be to make instance variables public rather than writing accessor
methods (in Java). But do first ask the interviewer if they would
prefer you write accessor methods. This shows the interviewer
that you know accessor methods are best practice and you ordinarily would
use them. They will most likely say that you can use public instance
variables for the interview, to make your life easier.
Step 4. Finishing
- Debugging - Say
you are debugging and debug. This not only gives you an opportunity to
debug your code, but also indicates to the interviewer that you know
debugging is important.
- Testing - Say
you are testing and test. Use a very small example and walk the
interviewer through what happens. Similar to above, this increases the
chance you will find issues with your code, and it tells the interviewer
you know what testing is.
- Tidy
up your code - If you have time left at the end then don’t waste
it. Look through what you have written and improve your style. Have you
used ‘0’ or ‘1’ as indicators? Think about switching to enums (or
their non-Java equivalent). Have you got any repeated code? Export it to a
helper method/function.
After the interview
Write down what you did well and what you can improve on for
next time.
Try not to worry if the interview goes badly. Firstly, for
this particular company, there will be several interviews for you to show what
you can do. Secondly, there are plenty of Big Tech Company fish in the sea. Try
to figure out what went wrong and add it to your list of things to practice.
Most companies will be happy to interview you again after
around a year. They know that peoples skills change over time, so don’t be shy
about getting in touch with them again after you have practiced more.
Good luck!
$ads={2}