Coding Interview Tips

There is much more to the coding interviews than just the ability to solve problems. In this section, we will talk about some additional tips on passing your coding interviews.

Problem solving approach

The following steps will help you to better approach the problems during the coding interviews. This applies to both phone and onsite interviews.

1. Read or listen to the problem statement carefully. Understanding the problem statement correctly is very important, so pay attention. You may also want to write some details down.
2. Ask clarifying questions and think of edge cases. After you have understood the problem statement, ask some questions to really make everything clear. Think of the edge cases. What if the input is empty, or is too big? Is it guaranteed to be X? Do we care about Y? Clarify everything with the interviewer. Thinking about edge cases ahead is much better than stumbling upon them during coding, or completely missing them.
3. Build some examples. You may still want to build some examples of input and output to understand the problem better. Confirm your examples with the interviewer.
4. Think about a straightforward solution. Even if you already know how to solve the problem optimally, think of some simple solution first. Is it possible just to check all possible options? Maybe brute-force or backtracking? Discuss simple solutions with your interviewer, their potential drawbacks, and time complexity.
   
   Rushing to the complex optimal solution may show that you are optimizing too early, before even considering simpler approaches. Also, it may turn out that your interviewer is fine with a more simple solution.
5. Think of and discuss the optimal solution. So now, what is the optimal solution to the problem? Describe it to the interviewer, and discuss it with him or her. What are the time and space complexity? How would you implement it?
   
   A great question to ask here is "Is this solution good enough?". This will tell you if the interviewer is ok with your solution, or if you need to think more. Also, don't rush to the coding – you may first want to ask something along the lines of "Do you want me to code this now?".
6. Think about what your code would look like before implementing it. This will save you from needing to rewrite or modify the code along the way and will save you time. Of course, it is almost impossible to imagine the whole solution code beforehand, but think of what its main structure will look like.
7. Handle bad inputs and edge cases. In your code, be sure to handle bad inputs (nulls, empty structures, and so on), and the edge cases. Even if your interviewer may be fine with you not checking the inputs, doing so will show that you are an experienced and considerate candidate, thinking about production quality code.
8. Check the code after you are done. After you have finished writing the code, read it once more, check that it works on your examples, and show it to the interviewer. Think if you need to consider some more test cases. Also, discuss with the interviewer how you would test your code.
9. See if anything can be improved. How else could you improve your code? What could you refactor or change? Are there any possible improvements or modifications to the algorithm or the approach? Discuss this with the interviewer.

Coding style

It is important to write good, clean code during the interviews. Think of it as of the code you would write at work. Here are some particular tips on the code style:

• Use good names for your variables and everything else. Even though you want to write code fast, it doesn't mean you have to sacrifice readability.

int b = 0;       // bad variable name
int bestSum = 0; // good

void go() {..}               // bad function name
void calculateBestSum() {..} // good

• Check input parameters. Like you would do in the production code, check the parameters passed to the functions.

int getMaxElement(List<Integer> list) {
    // You can use exceptions.
    if (list == null || list.size() == 0)
        throw new IllegalArgumentException("Received an empty list");
    ...
}

boolean isPalindrome(String word) {
    // Sometimes just returning true/false or some other value may be 
    // fine too. Ask your interviewer!
    if (word == null || word.length() == 0)
        return true;
    ...
}

• Keep your variable scope limited. Never use global variables. Keep the scope of the variables as small as possible.

// BAD.
// Varible matrix doesn't need to be a class field.
class Solution {
    int[][] matrix;
    public int processMatrix(int[][] matrix) {
        this.matrix = matrix;
        ...
        doSomething(); 
        doSomethingElse();
        ...
    }
    private void doSomething() { /* use matrix */ }
    private void doSomethingElse() { /* use matrix */ }
  }
}

// GOOD
class Solution {
    public int processMatrix(int[][] matrix) {
        ...
        doSomething(matrix); 
        doSomethingElse(matrix);
        ...
    }
    private void doSomething(int[][] matrix) { /* use matrix */ }
    private void doSomethingElse(int[][] matrix) { /* use matrix */ }
  }
}

• Use the right keywords. Learn what keywords like private, static, final/const, public, and others mean in your language, and use them correctly. Generally, you should mark your variables final or const whenever possible, and keep your functions and variables as private as possible.

class Solution {
    public int processMatrix(int[][] matrix) {
        ...
        // This should never change, so we use final here
        final int matrixLength = matrix.length; 
        processMatrixHelper(matrix);
        ...
    }
    // This helper function should not be called 
    // from outside, so mark it private.
    private void processMatrixHelper(int[][] matrix) { /* use matrix */ }
  }
}

• If you want to learn more about writing good code, consider reading Clean Code or Effective Java. They should help a lot.

Preparing for different interview types

Phone/online interviews

• A lot of phone interviews happen in Google Docs or something like coderpad.io. You can practice writing code there beforehand.

• Make sure you have reliable internet and, if needed, phone connection, good headphones with a microphone, and a quiet place where you can be alone for the whole time. Personally, I found that the best time to do phone interviews for me is the first thing in the morning, right after some breakfast, but you may see what works best for you. Interviews are quite a nervous experience, so you want to make yourself as comfortable and relaxed as you can.

Onsite interviews

• In a lot of onsite interviews, you will code on a whiteboard. Writing code on a whiteboard is very different from coding on the computer, so you may want to get a whiteboard and practice writing code on it closer to your onsites. Watch for things like how you manage your space on the whiteboard and how you edit the code on it.
• Onsite interviews are physically and psychologically demanding, so you should take at least one rest day before and between them. I'd suggest taking one or two weeks off work specifically to do the onsites, and not to do more than three of them per week.
• Be sure to bring the things you may need with you to the onsites. Stuff like water or a drink of choice, laptop with charger and everything else, in case you may be allowed to code on it, some snacks or even lunch if needed, markers for the whiteboard (good to have just in case), tissues and personal products, and so on. This will cover you in case you need something and will make you less nervous.
• Several days before the onsites it's probably more effective to mostly review past problems and solutions than to solve new problems. And it's better just to rest on the last day before the interview.

Mock interviews

From my experience, the only way to become less nervous during the interviews is to do a lot of them. Of course, you don't want to practice on the real interviews, so doing mock interviews beforehand is another good option. We will cover mock interviews in the next section.