Guide to ace your coding interview 👩‍💻

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

1. 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.
2. 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.
3. 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.
4. 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. 
5. 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.
6. 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.
7. 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!