Over the last five years, I’ve been in over a hundred coding interviews. I conducted a majority of them as an interviewer, and in about 15 of them, I was a nervous interviewee looking for a job.
In the beginning, I dreaded coding interviews. Solving algorithm problems under time pressure wasn’t my idea of a good time. But, as I got more experience on the opposite side of the table as an interviewer, I realized that it’s not just about whether you solve the problem or not. A lot of it has to do with how you solve the problem.
In this guide, I’ll go over general tips that I’ve learned can make or break an interview.
Let’s get started...
Analyze & clarify requirements
You are usually presented with a couple of sentences of requirements to kick things off. Far too often, people will start coding right away. Coding too soon without talking through the problem to verify their assumptions is one of the most common mistakes candidates make.
A good way to start is to repeat the question back to the interviewer in your own words. Once you’re sure you understand the problem, take a few moments to think of edge cases and clarify what should happen in each situation. Common areas to ask questions about are: handling bad inputs, addressing ambiguous or undescribed behaviour, different types (strings, ints) and handling exceptions.
You can usually find a few questions to ask about even the most straightforward questions. If there are tons of edge cases to cover, it’s worth noting them down as comments so that you remember to test them later.
It’s always a good idea to go over the problem with a couple of sample inputs to ensure that your output and the output the interviewer expects is the same.
Once you’ve understood the questions and uncovered some edge cases you should have some idea(s) for a way forward. It’s best to describe your proposed solution in words at this point. If you can think of multiple solutions, discuss them with the interviewer, and weigh tradeoffs. Exploring a problem space together can give the interviewer a good idea of how you think and communicate when you’re handed requirements. After all, breaking down requirements into code is what we do on a daily basis.
Some problems have multiple parts that are introduced as you solve a portion. Each time a new requirement is given, you should repeat the process of looking for edge cases and asking questions. Additionally, look out for how the new functionality you need will affect what you have so far. What will you need to refactor, and how will it modify existing behaviour?
Write clean code
Is your code readable? Are you hard coding values? Do your variable and function names make sense? Are you writing small functions or is the entire solution in one big function?
These are some things interviewers look out for in regards to your code. Sometimes it’s difficult to write production-level code under time pressure, and It’s okay to take some shortcuts. Use your best judgment; be sure to let the interviewer know “I’m doing X so I can do this quick, but I’d do Y if I were committing to production”.
Even when the shortcuts are obvious, or the naming is bad because you’re in a rush, mention anything that makes the code messier or harder to read. Remember that the interviewer knows nothing of your coding abilities outside of what you show them in this hour. The interviewer might think the shortcuts and you use in the interview are a reflection of how you code at work.
Test your code incrementally. This will help you catch and correct syntax issues as you go. If it’s a multipart problem, as you solve and test for new requirements, make sure your tests still pass for the previous sections.
Note on Coding Language*:* Are you comfortable with the language you’re working in? Some people like to use a different language than the one they use every day at their job. If you do this, make sure you are up to date on your interview language. You shouldn’t have to google how to loop over an array during the interview. Most coding interviews are fine with you looking up documentation, but you should be familiar with the basic data structures and operations. Showing mastery over the language you choose can get you extra points!
Debugging
When you run into errors and bugs don’t panic. This is a good opportunity to show your pro debugging skills. If there are compiling errors, take your time, read the stacktrace, and narrow down where things are going wrong. If there are no errors, but you have unexpected output, take a structured approach to troubleshooting. Place print statements methodically to help you find where things are going wrong. A good approach is to print out internal data structures and other key variables in your solution. You want to avoid sporadically printing things without any rhyme or reason.
Communication
If you communicate poorly during the interview, it can overshadow the rest of the interview even if you ace the actual problem. Every company I’ve been at has a section to rate an interviewer’s communication skills. Individuals don’t write code, teams do. The interviewer wants to ensure that you’d be someone they would want to work with, and a large part of that is based on how well you communicate.
Put simply, communicate your thinking throughout the interview. The interviewer should be able to follow your train of thought as if they were a passenger on it. When you arrive at points in the question when you need to make a decision or if you hit roadblocks, talk through your how you decide which paths to take, and how you unblock yourself.
Positive communication also goes a long way. When you hit an especially difficult obstacle, where you can’t seem to find the way forward, try not to get frustrated. Approach it with a positive attitude, and ask for help when you need it.
Communicating like this while you code is is probably not something you do every day at your job. It can feel unnatural and awkward. Practicing problems with a friend while speaking out your thoughts is a good way to improve in this area.
Virtual interview communication tip: Don’t cut off the interviewer. This is very difficult to have a hold on when doing interviews virtually. Try to speak once it’s clear that the interviewer is done speaking. The minor lag involved in online calls can make for jarring interruptions.
Final thoughts on improving
That’s a lot to keep in mind while doing an interview. As with any skill, practice is the best way to improve.
Practice the different aspects I’ve described. Do mock interviews with friends or colleagues, and ask them to rate you on the criteria above.
Interview your friends. It’s easier to spot mistakes and areas for improvement when you’re on the other side of the table. This process can help you stay attentive to your strengths and weaknesses in interviews. Conducting interviews as an interviewer has been a key factor in making me a better interviewee over the years.
Do leetcode questions; practice makes permanent. The point of doing leetcode is not to memorize solutions, it’s to recognize different types of problems. When you see a new question, you’ll be able to categorize it and draw on your knowledge to have an idea of which path to take, which edge cases might be an issue, which questions you’ll need to ask, and what kind of performance implications you’ll need to address.
Thank you for reading. I hope this guide helps you ace your next coding interview!
How do you approach coding interviews? If you have any tips or tricks, please comment and share!
Top comments (0)