Winning isn’t everything, but desiring to win is.
Well, it may sound like an exaggeration and it is indeed a bold claim, but let me tell you that it’s very well possible if you are prepared and know what you are doing. It is definitely not easy, but you can greatly improve the odds if you nail the following approach. I am going to explain the key elements that you need to get right to crack the interview. How many times you solve the question, code it completely, but still don’t clear the interview? This post is an attempt to stop this happening with you. I have appeared for over 125 interviews in a short time, and here are my learning from that which I am presenting as a step by step approach –
- Before the interview, decide the language you are going to use and know common tools for solving coding problems in that language like using a map or sorting an array. There are arguments about whether to change the language after knowing the question.
- Understand the problem carefully and ask clarifying questions, questions are kept intentionally open-ended and ambiguous.
You have heard this thousand times and I have to emphasize that one more time. Clarifying questions are going to change the way you are going to solve a problem. The last thing that you would want to do is to solve a different problem with different constraints than what the interviewer wanted you to solve. There are more ways of solving a problem than you think. So ask questions.
- Many times, a basic solution is easy to come up with. Let the interviewer know about it immediately. Follow it up with its time and space complexity immediately. Now the interviewer will tell you to implement it or you can ask if you should implement this solution. If the interviewer has a better solution in mind, they will want you to think harder about the problem. A better thing would be to be proactive about it and start thinking about a better solution immediately after you explain the basic solution. This works better because (1) If there is no better solution than what you mentioned, the interviewer will tell you to implement it right away anyway. (2) If you don’t come up with a better solution, you can always go back to the original basic solution and implement it. So there is no advantage in not thinking harder about improving the solution.
- Before you call your approach as a potential solution, test it if it works on an example test case at the least. Make sure that the solution is correct and will solve the problem for all inputs. Once you have finalized what solution you are going to implement, discuss the time and space complexity. This will give a very good impression that you are thoughtful about your choices, tradeoffs and you know what you are doing. These things do make a big difference when a candidate does or does not move forward after an interview even if they solved the problem correctly. Remember, an interview is not about solving a problem, it’s about how you think and how good of a job you will do if hired.
- Code the solution well – clean + accurate. Code is what you are getting evaluated on and other things like complexity analysis are supplementing it. Almost every problem can be divided into small problems, so divide your problem. Write separate functions. Give appropriate names to variables and functions. Although code gets auto-indented, do it manually if it doesn’t. Add quick comments wherever necessary, this can actually help you in implementing the solution easily and remove bugs if there are any at the end.
- Don’t call it done. You coded the solution, but untested code is worse than no code (well, maybe not but it isn’t much better either). I recommend writing a unit test – a simple separate method which will call your method. Ideally, I would be happy if you write the test first and then write code. The least you can do is to manually dry run the solution with some examples in addition to the one you started with.
- You can confirm the time and space complexity one more time in the end. Also, test your code for very basic and corner cases like a null pointer, 0 input, maximum integer input, etc.
A quick note I would like to add – whenever you convey the time & space complexity, ALWAYS mention the meaning of your variable. For example, if you say the time complexity is
O(n), also tell what that
n mean? Similarly, if you say the time complexity is
O(klogn), mention what those
It’s not rocket science to crack a coding interview. If you follow the steps logically, there is a close to 100% chance that you will move forward. Understand the problem well, find multiple solutions, convey your thought process, state the time & space complexity, code clean and follow good conventions, test before calling it done.
I do understand you might think whether there is enough time for all this in a 45-minute interview, the answer from my experience is YES. I will explain this in a separate post but trust me, it does not take as much time as you would think.
This post will help you when you are able to solve the problem. The first step to solving a problem is choosing the right data structure. What should you do when you are stuck when solving a problem? I have written a post with many approaches you can take in those times, I recommend checking out the post.
One question for you, assuming that you followed the above steps, is there a reason for you to not move forward? (You have to trust the interviewer that they will do the right thing and put everything in the feedback). Let me know in the comments what you think about the approach above, did I miss something, share your interview experience when you thought you did well but didn’t get a green signal.
Of course, don’t forget to like & share the post, and subscribe to the blog.