7 Things Most People Ignored In a Coding Interview

7 Things Most People Ignored In a Coding Interview 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, youre done. However, its 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? Ive 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 dont think big-O analysis is that hard and most of the time the answer is very obvious. Later on, I realized that most people dont 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 cant get a good estimation of how costly your solution is in real world problems. #2 Input validation Its 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 youve 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 its very natural that those solutions dont 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, its 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. Thats 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 its both a low hanging fruit for interview preparation and a great habit for your work. Ive 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, its a great opportunity to further impress the interviewer. Its 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 doesnt 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 dont 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 interviewers perspective, it seems that the candidate is not very clear about big-O analysis although he gave the correct answer. However, Im 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 dont 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. #7 Smile Dont 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 interviewers 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. Its 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. Summary To pass an interview, of course you should try your best to solve all the coding questions. However, dont 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.