Do you know that passing a coding interview means more than solving all the coding questions?
One of the most common misunderstandings is that once you cracked all the “puzzles” in the coding interview, you’re done.
However, it’s not always the case.
In reality, there are quite a lot things that most people ignored but are very important in a coding interview. Paying no attention to these factors may totally screw up your interview. On the contrary, if you prepare well for these things, you can get better chance.
#1 Big-O analysis
Personally I put big-o analysis as the number one point here.
Why? I’ve seen so many good candidates who successfully solved all the coding questions in my interview with perfect code but fail to tell me time or space complexity.
Initially I was quite surprised by this as I don’t think big-O analysis is that hard and most of the time the answer is very obvious. Later on, I realized that most people don’t pay much attention to it and this looks like a very common pattern.
Many people were able to figure out time complexity but unclear about space complexity. When it comes to a dynamic programming solution or recursion, most people are confused.
Sometimes the algorithm is so tricky that the interviewer himself may not know about the answer, but in this case interviewers still want to see how candidates analysis the problem. The expectation is not a correct answer, but the whole analysis process. Unfortunately most people just give it up.
To be straightforward, I can hardly hire someone who fails to analysis complexity even if he solved all the problems. Without a clear understanding of time and memory, you can’t get a good estimation of how costly your solution is in real world problems.
#2 Input validation
It’s a great habit to validate all your input, which is true for both production code and interviews. However, many people assume inputs are all validated without even asking.
As the robustness principle said “Code that sends commands or data to other machines should conform completely to the specifications, but code that receives input should accept non-conformant input as long as the meaning is clear.”
So a practical suggestion is whenever you’ve written down the function definition, put input validation right after that immediately.
Another suggestion is to ask interviewers for clarification, which can save you from unnecessary checkings. For instance, you may ask if you can assume all inputs are integers. If the answer is yes, then you can skip the integer checking in your code.
#3 Check corner cases
Similar to input validation, another common mistake is that most solutions cannot handle all corner cases.
In an interview, most people are a little bit nervous and want to finish the code as soon as possible. So it’s very natural that those solutions don’t take all situations into consideration.
A general tip is that you should always consider corner inputs when writing your solution, which is a great habit for experienced engineers.
Secondly, after you finish your code, it’s highly recommended to use few example inputs to test your solution and you can include several corner inputs.
Writing robust code is a skill that is developed through experience and real life projects. That’s why good engineers can write well-rounded solutions without even thinking about it.
#4 Clean code
When I say clean code, actually there are two meanings here.
First, you should have good handwriting on a whiteboard. Many people tend to write very fast in hopes of saving time, however they may waste more time to explain what they have written.
Not only does clear writing make it easier to communicate with interviewers, but it also makes the reader comfortable and happy.
Second, you should care about your coding style. I suggest everyone pay attention to this point as it’s both a low hanging fruit for interview preparation and a great habit for your work.
I’ve covered this topic in detail at 7 Simple Ways to Improve Code Quality In Interviews.
#5 Prepare questions at the end of the interview
At the end of each interview, you will get a chance to ask any question to the interviewer. In fact, it’s a great opportunity to further impress the interviewer.
It’s unlikely to happen that someone who failed to solve a single problem but got hired due to good questions. However, good questions can still make you stand out to some extent and give you some advantages, let alone that it doesn’t require a lot of time to prepare.
Questions to Ask At The End of an Interview has a detailed discussion about this. In a nutshell, you can ask questions about product, company culture or technical questions if you don’t have any idea now and you should prepare well before the interview.
#6 Be confident in communication
A lot of people are so nervous in an interview that they are even afraid of making a single mistake. As a result, they tend to be very unconfident in communication.
For example, even if they are quite sure about the time complexity, they could still say “I guess the time complexity might be O(n), I may be wrong though”. From the interviewer’s perspective, it seems that the candidate is not very clear about big-O analysis although he gave the correct answer.
However, I’m not encouraging you to be confident when you are not. The correct interpretation of this point is to be certain about things you know. Of course everyone can make a mistake and you don’t need to be afraid of that.
Also you will keep discussing with the interviewer so that you may still figure out the correct answer later.
Don’t take an interview as a painful exam. Instead you should think of it as a chance to discuss interesting problems with someone else.
A lot of people look pretty “unhappy” from the beginning of the interview. They might be too nervous or they have struggled a lot to solve the problem.
However, as is known to all that your mode not only can affect your performance, but your interviewer’s feedback as well.
Not all interviewers are happy to take an interview. They need to spend time preparing the interview, and the interview itself takes one hour and also they need to spend maybe an extra hour to write feedbacks. It’s a lot of work.
Having a pleasant conversation with the candidate can at least make the process better. The candidate may not be able to figure out every question, but a good communication process may still make the interviewer feel like working with him.
To pass an interview, of course you should try your best to solve all the coding questions.
However, don’t overlook other factors at the same time, which may be equally important. An coding interview is more of a compound process that the final result is determined by a variety of factors.