Tips for How to Succeed in Coding Interviews

Coding interviews are very daunting. You interview for your dream job, and a random stranger asks you to think on your feet for an hour. You are being put under a microscope, and every comment you make and every code you write is being analyzed intensely. Beads of sweat drip from your palms, and your mind ricochets everywhere. How do I solve this problem? Will my approach handle all edge cases? How many minutes are left? Are there any edge cases that I am missing? What was the facial expression of my interviewer?

I agree. It’s not an easy experience. It’s tough. Let's talk about how to make this experience smoother for you.

1. Come up with a game plan

Before you start writing code, you should come up with a plan on how to tackle the problem. You should spend around 5 to 20 minutes on this portion. My game plan involves drawing diagrams and running through test cases. For instance, whenever I get a graph problem or a tree problem, I like to draw a recursion tree to identify the different states that I will be visiting and the order of states that I will be visiting. More importantly, drawing these trees highlights any logic I may need to perform, such as backtracking. Another example is if I plan to use hashmaps in my approach, I always list out what are all the key-value pairs that my hashmap is storing.

Coming up with a game plan has several advantages. First, the interviewer can inform you if you are heading in the wrong direction. If so, you just saved yourself 30 minutes from writing all that wrong code! Second, it is easy to pinpoint what data structures and variables will be needed to solve the problem.

If your initial game plan is not the most efficient, that is okay! Do not worry about defining the most efficient solution early on. This is because it is better to have a working code than a broken code or even worse no code. This tends to be the downfall of numerous interview candidates.

Once you have implemented your game plan, you can come back to refining your approach to be more optimal.

2. Always communicate

Because the interviewer does not know what is going on inside your head, you have to communicate your thought process to your interviewer. This is an important soft skill to focus on because the interviewer is evaluating your problem-solving skill and your journey to solve that problem.

I am stressing about this skill because communicating effectively landed me a job offer at a top company. During that onsite interview, a staff engineer asked me a difficult dynamic programming interview for a 45-minute session. I drew out a 2D auxiliary matrix and the different states in the matrix. However, I was stuck for the longest time in expressing the correct recurrence relation. I would test my recurrence relation on numerous edge cases, and my approach would yield an incorrect answer. I would explain why my recurrence relation was wrong and discuss approaches to refine it. I communicated every step of my thought process.

At the end of the session, I had a defined recurrence relation, but no code was written. Zero code. The whole entire whiteboard was filled with a bunch of matrices and arrows. As I walked out of the interview room, I was confident that I failed that interview. I would have bet my whole life savings that I failed. A few days later, I got a call that I got the job.

So when do you need to communicate?

You need to communicate

• when you are coming up with a game plan
• when you notice that there are several approaches to solving the problem, and you identify which approach is the most efficient one
• when you see a bug in your code
• when you are stepping through your final code with a test case to validate the correctness

3. Always Test Your Code

It is a rewarding feeling once you write out the final line of code. You feel accomplished for solving a difficult problem under pressure. However, you have not crossed the finish line yet. If you say to your interviewer that you are done with your code without validating it with test cases, you could be significantly jeopardizing the interview performance.

If the interviewer catches bugs in your code and informs them to you, the interviewer will mention in the feedback review that “the interview candidate did not test code, and I identified bugs for the candidate.” Not testing your code is not abiding by the most fundamental practices in software engineering. No one writes perfect code on the first try. You always need to validate your code in order to gain and maintain the trust of your customers.

So always make sure to step through your code with at least two test cases, and one of them should be an edge case. Make sure to communicate during the testing portion.

4. Ask about the input

Before you start coding, you need to think about the various forms of your input. This will determine which game plan to come up with.

You should pose these types of questions to your interviewer:

• Can my input be null?
• Is my array sorted or unsorted?
• Is it a doubly linked list or a singularly linked list?
• Will my array contain negative numbers?

How can asking this be helpful?

For instance, let’s say the task at hand is to find a target number in an array. If the interviewer confirms the array is sorted, then you can do a binary search, which has a runtime of O(log N). However, if the interviewer says the array is unsorted, then you have to do a linear search, which has a runtime of O(N). The nature of the input can change the approach to solving the problem.

5. It’s okay to ask for help but not too much

There may be situations where you have no idea what to do. It is okay to ask for guidance from the interviewer. You don’t want the interviewer to give away the solution, but you want him or her to nudge you in the right direction. If you are able to come up with the correct solution with just a hint or two, that is still positive feedback. It means you are still an independent thinker with the right guidance.

However, you do not want to keep asking for a lot of help. You do not want to seem you are incapable of problem-solving. A good safe number of hints to use is 2. Going more than that may drastically lower your chances of getting the job offer.

Resources

I do resume/interview workshops with clients applying for software engineering jobs. I have worked with over 50+ clients, and they have landed job offers at companies like DoorDash, Square, and 1Password.

Yen is a senior software engineer at a high-growth startup. He has worked with numerous clients on ramping up their technical skills for jobs with over 400 client sessions.

You can find him on Instagram.