Approaching coding challenges in an interview: the basics
Completing a coding challenge with an interviewer breathing down your neck can be intimidating, but there are things you can do to prepare yourself.
The world of coding isn’t kind when it comes to interviews. While in many fields of employment you can rely on just flair and persuasion to sell your skills, if you’re presenting yourself as a web developer or a data analyst you will be expected to prove on the spot that you know what you’re doing. This is usually done through a coding challenge, which very often will take place in person, right in front of the interviewer(s).
It can be a daunting moment for many, but there are ways to be ready for it. In this article you will learn:
- The essentials of how to carry yourself during a coding challenge
- A universal problem-solving routine to tackle the challenge
Acing an interview is a matter of preparation, experience and persistence, so practice your skills and never give up — you can do this
1. THE ESSENTIALS
Keep calm
This is important for any interview, but never more so than when you’re facing a coding challenge. Our natural reaction to any situation in which we are being judged is to become nervous, hesitant and unfocused. There isn’t a one-size-fits-all solution for this problem, as different people will find that different things relax them best, but one routine that generally helps is to articulate your anxieties and then rationalize them.
When you’re feeling uncomfortable, quickly ask yourself why, or what it is that is making you feel that way. Don’t suppress your feelings, listen to them, and then try to express them in a sentence. If your gut is telling you, ‘this problem is unsolvable’, take a mental step back, and address the concern rationally: ‘If this problem were unsolvable, the recruiter wouldn’t use it’. If your gut is telling you, ‘you won’t get the job’, you can reply to yourself: ‘Even if I don’t get this job, I will simply apply for the next, with the extra experience I am picking up in this interview’. Nervousness often stems from thoughts of a worst-case-scenario echoing in your head, but most of these fears are baseless, and it becomes easier to dismiss them once you’ve worked them out in your mind.
Communicate
You could be proving Euler’s theorem in your head, but believe me, nothing will make you look as clueless in an interview as just sitting there quietly. The whole point of a live coding challenge is for the interviewers to understand how you think and how you approach a problem, so for heaven’s sake speak up: if you’re going to add a supporting data structure, explain what makes it useful; if you’re opting for an iterative solution over a recursive one, tell them why; when you choose a particular approach to the coding challenge, tell the people in front of you why your option is better than the alternative(s). Even when you’re simply practicing for the interview, you should make it a habit of speaking out loud and explaining what you’re doing to an imaginary interlocutor — it will be a lot harder to do it on the spot otherwise!
As importantly, ask questions. Ask your interviewer what kind of solution they are looking for (quick, elegant, simple, exhaustive, creative?), and clarify anything that still feels ambivalent or obscure. This won’t help you alone — it will also make it easier for your interviewer to keep track, and drop hints if necessary.
Practice the concepts
One question interviewers are likely to be especially interested in, is how you approach something you do not know. They will be looking for problem-solvers, not people who can reproduce material written by someone else in a textbook. Thus, expect their coding challenges to feature one or more elements of unpredictability, even if the field they belong to is one you know quite well.
There isn’t much you can do about this during the interview itself, but there is a lot you can do while preparing for it. When practicing coding problems, always put your focus on understanding the concepts that you are working with, not just on finding whatever solution works on the spot or on memorizing your way through a problem. In general, understanding the logic behind your code is one of the golden rules of good programming, and coding interviews will show you exactly why it’s so important!
2. THE PROBLEM-SOLVING ROUTINE
It is important to recognize that a creative process like coding has a fundamentally individualistic element — how you work best will always come down to you. For this reason, long before you get to the interview stage, you should actively be testing out different problem-solving approaches until you find the one that suits you best.
If the method we are going to outline does not work for you, by all means consider other options as well (here’s one, for example). Even better, develop your own routine. Just make sure that by the time the interview comes round, you have a structured, tried-and-tested approach which you can fall back on when a problem appears unreasonably complicated, or simply when the interview jitters bite. Once again, you will find this a useful tool well beyond the interview process.
Lay down input and output
The first step should be the most elementary: based on the material you’ve been given, get a clear sense of where you will start from and where you need to go, or more simply, the input and output of your code. I would recommend drawing out the rough path between these two points, or writing down the fundamentals of the transition.
This basic approach is useful for all coding problems, and vital for algorithm challenges, which are among the most popular interview tests and which also happen to be entirely predicated on input-output transformations. Sometimes this process will already reveal a rough solution; more often, it will pre-empt further trouble down the line.
Look for edge cases
Unforeseen edge cases are probably the most common reason why candidates will fail a coding challenge. You may have come up with a very smart solution to your problem, only for the interviewer to ask what happens when you try and return a particular string, and suddenly your carefully-constructed code must be furnished with a dozen extra statements which take half an hour to put together.
Long before the interviewer throws you that curve-ball — even before you write a single line — start looking for scenarios in which to test your code. Make sure those scenarios cover far-flung possibilities. You’ll want to have a solution that accounts for them, and no less importantly, you’ll want your interviewer to see you didn’t miss them.
Break down the problem
Right, you’ve figured out where you’re going and you’ve accounted for the bumps in the road — now it’s time to code! The most important thing you have to bear in mind at this stage is that you should follow a step-by-step procedure of solving — and testing — one small issue at a time.
Remember what we said about drawing out the various steps from input to output? This is where that visual blueprint comes in handy. Refrain from trying to code the whole solution in one go. Instead, break down the problem, and work your way methodically (and patiently, interview nerves be damned!) through each task until you have the result you were looking for.
Don’t worry if the solution isn’t too elegant yet — what matters is that you reach a solution. That should be your only priority for now, because the final step is…
Optimise
This part will arguably be your truest test as a developer. The reason for this, is that there is no procedure you can use on the spot to make sure you have the best and most elegant version of whatever solution you came up with. It really just comes down to competence, and this in turn comes down not to what you do during the interview but to what you did before it.
If you want to get good at optimisation, your best bet is to take advantage of the coding community itself. Working in groups (if you have this option) is exceptionally formative in this sense, because it lets you compare methods and approaches in real time — incidentally, and at the cost of tooting our own horn, this remains one of the greatest advantages of bootcamps over self-learning. If you don’t have anyone to work with, then find a coding challenge that is publicly available (for instance on Kaggle or Codecademy), solve it, and then compare your solution to what others came up with.
Over time, this sort of comparative exercise will train you to think eclectically in terms of different paths to the same goal, and will teach you to choose the best one. Show that you can do this in an interview, and your next step will be your own desk in their office!
