Solving problems sitting at our home and solving problems in front of interviewer is completely different. At home, we have enough time and even if we take few extra attempts to get the problem right, or take few extra minutes, it doesn’t matter. However, these extra attempts and minutes will definitely break your interview.
Therefore, it is important that we keep the following things in mind when we are interviewing :
First step is to understand the problem correctly and completely. To make sure that you have understood the problem correctly, try to solve a few smaller cases by hand on the whiteboard. This will not only improve your understanding of the problem, but might also show you certain patterns.
If it is a graph/tree or Linked List problem, then it makes even more sense to utilize the whiteboard that you have to draw the relevant diagrams. Even if you don’t see any pattern now, you might if the picture is right in front of you when you start thinking.
After you are done understanding the problem, ask the interviewer what are the constraints on the input size or any special requirements.
Asking about the constraints on input size would give you an idea about the expected time complexity . for example, if the problem is about an array and the input size of the array could be upto 1016, then it means that the expected solution will have complexity of O(logn)
, which gives a big hint that the problem will be solved using some divide and conquer approach like binary search.
Apart from time complexity, clarify whether there are any restrictions on space complexity. If you can use some space, then you might want to explore using other data structures to organize the input like Stacks, Heaps, Trees etc.
While thinking about your solution, try to think about the approach that you are taking and why. The interviewer will not know about any approaches you have been trying or rejected unless you tell him that. If you are using binary search to solve a problem, try to explain to the interviewer what made you think binary search would work.
With this approach, the interviewer might also start giving you hints to nudge you in the right direction if you are going really off track.
Before jumping into writing the code, it is important that you verify that your algorithm will work on all the test cases. Try to test your algorithm on different edge cases for example for a problem involving arrays, an edge case can be when the array contains only one element, or when all the elements of the array are duplicate.
After this is done internally, it is important to clarify your algorithm with the interviewer. You don’t want to start coding unless you are absolutely sure that your algorithm will work. This way, if your algorithm will not work on certain test cases, your interviewer will point that out initially saving you valuable time.
When writing the code, it is very important that you write readable code, since the interviewer can understand the code easily. You can follow the following practices, to make your code readable:
solve
, instead write it as dfs
.swap
which will be called inside the for loop. This makes the code much easier to read and debug.