Maybe let yourself stuck for a while. Maybe its part of the process.
The coding interview is about solving a programming problem. I always emphasize how the thought process is more important than the code and it is certainly true. However, being able to solve i. e. “find a solution to the problem even though you don’t have time left to implement it in code” – is extremely important. I would assume it is extremely unlikely to clear the interview without solving the problem. Most of the time questions are fairly general, so you will likely be able to figure something out from your experience. It does happen sometimes that you don’t know the problem and you get stuck. This is a post about how to navigate in that situation and how to get unstuck.
Believe me, when you get stuck in an interview, you have the opportunity to actually get maximum points from the interviewer as long as you keep the positive attitude and logical approach. Ideally, the interviewer would like to see the candidate struggle and then find the solution. This way, they are able to see how you tackle the problems in the real world. This is also a reason why I think knowing the problem (solution) already can be disadvantageous in an interview. If you just breeze through the problem, the interviewer is getting little data about you that you can solve the particular problem. If you also explain the thought process, the interviewer will get the data that you can communicate well. But if you struggle and still find a way to get to the solution, the interviewer will see how you approach when you don’t know the solution i.e. how you navigate in an unclear, ambiguous situation, whether you ask for help at right time, are you able to communicate clearly when you are facing problems, etc. This is too valuable information to get from the interview, and in fact, this is the purpose of the interview. Solving a problem is just an excuse. Any good interviewer would value you as long as you keep the right attitude.
There are mainly two categories into which we can divide the things that you should do when you are stuck –
- What you should do continually throughout the interview (Soft skill aspect)
- Actually putting efforts into solving the problem (Technical skill aspect)
What you should do continually
- Think of the interview as a situation where you and your coworker are trying to find a solution to a problem. Involve the interviewer, convey your ideas, listen to the interviewer’s ideas.
- Keep communicating with the interviewer. The interviewer is going to help you by giving you feedback on whatever you are thinking of.
- Precisely communicate what you are thinking, what subproblem you are blocked on.
- Another reason why communicating is important – in the real world, you are going to see unseen, unsolved problems. If you are struggling and still not asking for help, communicating – is a big red flag.
- Every word that the interviewer speaks is a hint because the interviewer knows the solution and they want you to succeed as long as you do your part well.
- Also, from the attitude point of view, have this in mind – “there is a way, and the way is on the way”.
Various approaches to poke the problem
Assuming that you will keep communicating and have the right attitude, let’s see how you can actually solve the problem.
- Solve manually with a couple of examples.
Think step by step, observe what you are doing while solving those examples, what steps you are taking. Our brain is sharp and fast, so it finds the solution for examples very quickly. However, it is important to think slowly and observe yourself because the computer will need very precise step by step instructions. Many times, this step is all you need to figure out the solution.
- By far the most effective step is to break down the problem.
If you can break the problem into a few independent subproblems, great! Now you have relatively smaller problems to deal with. Now you can hopefully think with more clarity and better focus on smaller problems as the burden of one big problem is reduced to only one subproblem at a time.
- Find a brute force solution.
It’s relatively much easier to find a brute force solution. If you can, find this solution and convey this to the interviewer. This will give you more confidence because now you have something tangible. Importantly, the brute force solution can be optimized to figure out the efficient, optimal solution.
- See if you can solve the easier version of the problem.
Some tweaks to the problem make the problem easier, see if you can do that. Once you can solve the easier problem, you can maybe reuse the solution with some changes to solve the original problem.
- Check if you can solve a very small version of the problem.
The reason why you can solve the examples manually but can’t write the generic solution is that the examples you generally solve are very small. Look to capitalize on that. Say a problem involves some operation on an array, think – can you solve the given problem if the array size is just 1, or 2, or 3. If you can solve the problem of size 1, 2, or 3, it is likely that you will be able to figure out what exactly needs to repeat for the remainder of the array. You will likely find a pattern. So try solving very small problems.
- Can you build the solution to the bigger problem using the solutions of the smaller problem?
This is a typical pattern in dynamic programming problems where a relatively larger problem can be solved using solutions to smaller subproblems. Thinking about this can help you get in the right direction.
- Optimize the brute force solution.
As I said, it’s generally obvious to figure out the brute force solution. The main idea to get to an optimal solution from a brute force solution is to see what same smaller problems are you solving repeatedly, what process you are following repeatedly on the same input. Finding a way to avoid repetition can lead you in the right direction. Sometimes an optimal solution is achieved by pruning the input size. Think of a binary search. Once you know the middle element and the element you are searching for, you choose one direction to search in and ignore the other. You just divided the problem size into half, and this led you to solve the problem in O(logn) time than O(n). So avoiding the repetition and cutting down the input size are some of the ways to find an optimal solution from a brute force one. I talk about choosing a right data structure for an optimal solution in one of my other post, check that out too.
- If you are struggling with the optimization part, make sure that you are using the right data structure.
Each data structure has its own uniqueness & strengths, so play on the strengths of data structures. If you repeatedly find yourself looking for the maximum element in the data, it might be better to use priority queue/heap to store the data/elements. Similarly, if you find yourself repeatedly wasting time in checking if some element exists in the data or not, it might be time to use a set to check the existence or sort the array once and keep using binary search.
- If you can’t find the right data structure or algorithm or design paradigm for the problem, try the other way.
You can also try this approach. Throw all data structures that you know (array, linked list, stack, queue, graph, tree, set, map, trie, heap, etc.), all algorithms you know (DFS, BFS, tree traversal, heap sort, topological sort, shortest path, merge sort, binary search, partial sort, etc.), all design paradigms you know (dynamic programming, greedy approach, brute force, divide & conquer, etc.) – at the problem, and see if any of them fit the problem. Although this is not a great way of solving the problem, it has the potential to solve the problem or at least get you closer to the solution.
- Fall back on the basics, take a step back.
It’s common and easy to get swayed away in one direction (generally the wrong one), it’s easy to go so deep and forget what you actually want to solve. Hence it is important to keep asking yourself repeatedly what problem you are stuck at, what are you trying to solve exactly. Take a step back and see the bigger picture. When you try multiple ways and still can’t figure out, looking at the bigger picture by taking a step back, you might be able to find out how multiple pieces can be put together to achieve the desired outcome.
- Use these approaches recursively until you have deciphered the original problem totally.
There is a high chance that you can make at least some progress using the approaches mentioned above. Maybe you were able to break the problem down and now stuck on a subproblem. Apply all the ways we discussed above, to that subproblem. Keep doing this recursively.
I believe the above steps will help you get unblocked in the interview. The best-case scenario for you is you get a problem that you didn’t know, you come up with a brute force solution, you struggle to find an optimal solution, you attack the problem in multiple ways logically, and finally, you come up with a solution and implement it. Along the way, you communicate your thought process, where you are stuck, etc. with the interviewer. I told you to not be afraid of asking for help. However, it’s important to note that the interviewer will write the feedback of the interview and if they provide you a hint, they will mention that in the feedback as well which makes you rank lower than someone who didn’t need a hint. So don’t ask for hints or help prematurely. My point is if you can’t find a way, instead of hitting the wall, it’s better to get help and solve the problem. Although it ranks you lower than someone who didn’t need a hint, it ranks you much higher than those who couldn’t solve the problem, to begin with.
The above list of approaches is nowhere close to exhaustive. From your experience, what strategies worked for you when you got stuck in an interview? Share those in the comments below. What approaches did I miss, let me know and I will be happy to add for the benefit of everyone. Also, let me know your thoughts on the post.
Finally, don’t forget to like, share the post and subscribe to the blog.