Stuck in your Coding Interview? Here is what you should do…
Whiteboard coding interviews are an essential part of every FAANG interview for software engineering roles. And it’s also the most terrifying part of the whole interviewing process for many engineers no matter their level of experience! One thing most interviewees don’t know, since they only do a couple interviews every couple of years, is that getting stuck is normal. It happens to almost everyone! Today, I’m sharing what can go wrong and how you can prepare, recover and still ace your interview! Rather watch a video? Check out my youtube video!
First of stay calm and don’t freak out. Which is something easy to say I know, but once you know the different reasons you might get stuck and strategies to recover, it gets much easier. So, when you get stuck in the middle of coding, it’s typically because of one of the following three reasons. We start with the most easy to overcome reason to be stuck.
- You blanked out
Interviewing is a high-pressure situation. It requires a lot of focus, and still you are being expected to think and communicate with the interviewer. It’s ok to lose your chain of thought sometimes. Stay calm, go up a few lines and see what you were doing. If that doesn’t help, go back to your high-level approach and see where you are in your problem. That’s exactly, why you should always plan your solution before you start coding, otherwise you do not have any structure to fall back to.
BTW, Interviewers know better than anyone that the candidate is human after all, not a robot. So don’t worry about them when you black out — they understand. Just keep them in the loop, tell them you blacked out, take a deep breath and recover.
- The approach is not completely clear in your head
Sometimes, you realize in the middle of your implementation that you didn’t consider a particular edge case or condition. For example, how to handle arrays of length one. Of course, it would have been better if caught all of these cases before you start coding, but it never goes perfectly well. So don’t freak out, you can’t do much about that now. Go back up your code and walk through it to see how this case fits in. Let your interviewer know, once your are sure that you missed an edge case.
- Something is wrong with your whole approach
At other times, you may realize that your approach will not work for this problem after all. This is the most critical problem that might appear. But again, what’s done is done. So, double check, tell your interviewer what you think happened and how you will fix it. Then, go back to your approach and modify accordingly. Make sure your initial approach actually doesn’t work, don’t just abandon it without giving it a fair consideration.
In all of the cases above, there are common strategies to avoid and eventually correct them.
- Plan your approach beforehand Before you start coding, make sure you have a clear idea of what you are implementing. If you don’t, then spend some time figuring it out. Better now than after you start coding.
- If you get stuck, go back a few lines of code, or review your approach again.
- Talk to your interviewer and share your train of through and your reasoning leading to make changes, as that’s what they want to learn about. Correcting a wrong approach and explaining your reasons is much better than staying dead silent, especially since many interviewer are willing give some hints, once they see you being a good communicator.