Interview Skills and Coding Styles

By /

Here are some interview skills and coding styles that on top of my head.

Interview Skills

Try to avoid “I know a fancy algorithm called xyz…”

Try to avoid using uncommon existing algorithms used for very specific cases, such as KMP for substring problems, Manacher for longest palindrome, etc.. Most of the times, the interviewer doesn’t know these algorithms neither. The interviewer wants to know if we can resolve the problems with multiple approaches and evaluate the performance of each solution. The knowledge for a very specific algorithm to a very specific use case is not what an interview is expecting for. Don’t overly invest your time in these algorithms.

Sanity check on input

We need to do sanity check on input unless the question explictly says all the inputs are valid. Failing to do so may result in NullPointerException or index out of boundary exception, etc.. Normally there’re some edge cases because input has unexpected data than the normal input, say we expect the input array to be non-empty. To guarantee our algorithm works, we need to perform sanity check on inputs to check all kinds of unexpected values.

Communicate with interviewer

Keep communicating with the interviewer. Some people start writing code immediately after interviewer throws out the question. It’s better for us to speak out the solution first, asking the interviewer if he wants us to implement the code. If yes, do it. If no, we talk about an optimized solution, and usually, this is the one that the interviewer wants us to implement.

While coding, don’t talk to much, such as reading your code, nor just keep silent and make the interviewer feel embarassed to interrupt you. Talk about what this block of code is doing.

List out the code skeleton before filling out details

Sometimes we may not have anough time to implement the whole solution, so it’s important that we list our the solution skeleton before we fill out the details. We can write the signature of the helper methods, and in our main method, use comment to section the steps of our algorithm. If we still have plenty of time, implement the main method first, and then focus on the helper methods. If we don’t have enough time, you still give the interviewer the impression that you have a clean and systematical way about how to resolve this problem.

Actively discuss the time and space complexity implementing code

Don’t sit and wait for interviewer to ask you about time and space complexity. Since we know it will happen, and it’s just a matter of time, we’d better actively talke about time and space complexity after coding. Some interviewers may want you to talk about complexity after you speak out your solution before coding, make sure after analyzing the complexity, check with interviewer to see if he wants you to proceed and implement the code.

Avoid index out of bound exception and null pointer exception

Every time when access an array’s element, or call a method or field on an object, we need to make sure index is in bound, and object is not null. Either we do a sanity check or we are confident the target is always valid.

Coding Styles

First, let’s take a look the following Java code snippet:

class Solution {
    public int[] twoSum(int[] nums, int target) {
        int[] a=new int[2];
        int j;
        boolean aa=false;
        for (int i=0;i<nums.length-1;i++) {
            for (j=i+1;j<nums.length;j++) {
                if (nums[i]+nums[j] == target) {
                    a[0]=i;
                    a[1]=j;
                    aa=true;
                    break;
                }
            }
            if (aa) break;
        }
        return a;
    }
}

What do you think about this code?

Explanatory names

No matter it’s class name, method name or variable name, we need to make them explanatory. Look at the above example, what does a, aa mean? We can only guess their meanings. If we rename a to result, and aa to resultFound, the code can be much easier to understand.

Space to wrap binary operators

Add a pace in front and right after the binary operator can make the code much cleaner to read. However, unary operator does not need to.

a += 1;  // Binary operator
--a;     // Unary operator

Space in if and while code block

if (someCondition) {
  ^               ^
}
for (someCondition) {
   ^               ^
}

Explicit code block

No matter it’s a loop or an if statement, even though there is only 1 line in the code block, we should explictly mark them out. So instead of 

if (someCondition) someVariable = someValue;

we write:

if (someCondition) {
    someVariable = someValue;
}

which makes the code cleaner to read.

Indentation

Different language may have different indentation requirements. Please follow the rule for the specific language. If we align each line of code to the left, that will be a nightmare for interviewer to read our code.

Try to avoid global variables

Sometimes we use class fields to serve as global variables, but that’s not quite a good idea, especially in production code. If we have many functions, or same function but on different call stack, which modify this variable, it’s hard to debug. Also, we might be facing thread issue if too many methods modifying same class fields.

The way to avoid this is trying to make our return value of the method more informative. Say instead of a single value, we may want to return a tuple with addtional infomation, or create a new class which has all the information we need.

Leverage private helper method

We don’t want to make our main method too long and doing too many things. Break the code into several logical block, and seperate them out into private helper method. This also might reduce the code duplication since we may encapsulate duplicated code into method.

No more than 3 layers of indention

More indention layers, harder to understand the code. We can avoid it by simplifying the logic of the code, more condition judgement in if clause, and seperate some logic into another method.

Use “continue” or “return” over “if”

If we use too many if clause, it will cause our main logic nested and very hard to understand. Instead, we can break out from the loop or even the method early, and keep the main logic not indented too much.

Use blank line to seperate logical block

Don’t concatenate all the code togeter. Instead, seperate logical block of code by using blank line, which will enhance the code readability quite a lot.

Scroll to Top