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 :
Understand the problem correctly
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.
Clarify the constraints of the problem.
After you are done understanding the problem, ask the interviewer what are the constraints on the input size or any special requirements.
Clarify time constraints
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.
Clarify if there are any space complexity constraints
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.
Think out your solution loud
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.
Explain your solution to the interviewer
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.
Make sure that your code is readable
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:
- Concrete Naming: Give concrete name to functions and variables. for example, if you are writing a method that does Depth First Search, don’t write your method name as
solve, instead write it as
- Use STL: Make sure that you use standard libary methods, wherever necessary as that would make the code concise and easy to read. To write such code, you would need to increase your understanding of such methods and their associated time complexities.
- Pure Functions: Try to use pure functions if you can. It is very easy to reason about pure functions, and they make your code simple to read. However, don’t over do this as writing too many pure functions might increase the time complexity of your program.
- Divide tasks into functions: When writing the code, try to make sure that a function does only one thing. for example, while writing bubble sort code, don’t write the swap logic inside the for loop. Instead make a separate function called
swapwhich will be called inside the for loop. This makes the code much easier to read and debug.
- Handle Edge Cases: Before submitting your code for review, make sure that you dry run it and test whether it is able to handle the edge cases or not.