In our previous article, we outlined some of the essential practices to approach a live coding challenge in an interview. Now it’s time for us to get into the nuts and bolts of the question. Being relaxed and communicating effectively are all well and good, but how do you actually solve the problem staring back at you from the monitor?
Here we will present one linear routine, divided into four steps, which can help you tackle a coding challenge efficiently and without being overwhelmed. This is meant as a suggestion and a starting point, but it’s important to stress that your favorite way of working ultimately depends on you. If you wish to tweak this method to your preferences, or if you discover a different one altogether, and after having tested it in practice you find that you get better results with it, then ditch any and all of our suggestions – always listen to your own brain first!
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…
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!