How To Approach Coding In Job Interviews

I'm Adam, and I coach candidates on how to best demonstrate their skills in interviews. This article includes the steps and a structure to enable you to make the most out of those interviews where you are given a problem and you are asked to think of a solution and implement it.

Knowing data structures and algorithms and having plenty of practice with these kinds of problems are great ways to build the skills that you want to highlight. This article focuses on how to make sure that, if you do have those skills, you can avoid some common pitfalls.

While these steps focus on the technical part, remember that an interviewer is also assessing how you behave in the interview. Stay upbeat and friendly, accept technical advice on the assumption that the interviewer knows the question better than you do, and communicate clearly throughout the interview.

1. Understand the time you have available

A good interviewer will make sure that you know how much time you have available. This isn't always the case, and you are more than welcome to ask for clarity on this. Knowing whether you have 45 minutes to solve one problem, or if this is just the first problem, will help you to pace yourself and to balance code quality, solution optimality and completeness.

2. Understand the question

A key mistake that candidates make is to code a solution to the wrong problem. This can be due to nerves or time pressure, or poor communication from the interviewer.

There are a number of methods which you can use to remove confusion about the question. Always start by taking the time to read the problem statement and think about the question.

If there is a sample input and output provided, make sure that you understand why the sample input leads to the provided output. If there is no sample input and output provided, ask for one, or preferably create one and confirm your assumptions with the interviewer.

Clarify whether you should handle any invalid input or any cases you are unsure about.

3. Write down test cases

Either in code or note format, write down what you will test at the end. This may include a given or chosen sample input and some edge cases. In some cases, these may all be given.

This will help you to avoid errors when you are formulating an approach. It will also show the interviewer your rigorous approach, and when you are finished the test cases can come in handy for testing your solution.

You likely are not best off going full TDD and writing beautiful test cases under time pressure. Some of my notes might look like [1, 2, 4.8] -> 9 - showing that when I take the list of those three numbers, my output for this function should be 9.

If you do feel comfortable with testing, and you feel that the time might be well spent, it may be worth turning those notes into real tests. That might mean a few assertions at the top level, but it might also mean creating a mini test-suite. Check out the coding environment that you are going to use in advance as many of them include test frameworks such as pytest and mocha.

4. Describe an approach

Take your time to consider an approach to the solution. Sometimes it is best to describe a brute force or very simple approach, as this is better than having no approach. From there you can think about, or even discuss with the interviewer, whether it is worth continuing to think of approaches.

Once you have thought of an approach, this is a key opportunity to demonstrate to the interviewer that you can communicate technical plans. You can mix words with written notes or even pseudocode - the important thing is that both you and the interviewer know the plan. If you have nodes, this might make it easy for you to refer back to your plan if you get lost in the weeds while coding. When you describe your approach, focus on the types - What type is my input? What type is my output? What types are my main intermediary structures?

Describing an approach has some other benefits, too. In particular, it allows the interviewer to jump in and help if you get stuck while coding, and if you don't finish, you at least get credit for having a valid approach.

Some of the things I like to consider with regards to the approach:

Am I modifying input, and is that acceptable? Am I unnecessarily copying the input somehow (causing at least O(n) space complexity)? Am I using a list or array where a set or hashmap would be simpler or more efficient?

A common pattern for interview questions looks something like:

 result = None  # or nil, or [], or 0
 for item in given_input:
     do_something...
     modify result
return result

Keep that in mind if you are stuck!

Validate your approach by running through your algorithm, in your head or out loud, with at least one sample input.

5. Write code

As much as possible, turn your notes into working code. If you decide to change your approach, go back and create notes and validate the new approach.

Keep variable names and function names very clear - err on the side of verbose. For example, if iterating through a 2D array, you might choose row and column instead of (i, j) or (row, col). This will help you fix bugs with your code, and it will show the interviewer that you can write maintainable code.

Use small helper functions where appropriate. If you have a bug, you can test just these functions alone to narrow down the cause of the bug.

And most of all, focus on simplicity. Some of the questions I ask myself to make sure that my code is simple:

• Do I have a lot of unnecessary and specific base cases?

• Am I trying to make a single line of complicated logic that could be simply written out into multiple if statements?

• Am I trying to use a fancy functional style or remember a specific function or regex when an explicit for-loop would do?

If possible, run your code early and often with print statements or test cases confirming what you expect. If that is not possible, run through your code out loud with a sample input, explaining what each variable should be.

6. Test your code

Run your code with all sample inputs if sample inputs are given. Remember those test cases you wrote before? They can come in handy again as you can use them now for testing. If there are any other cases which you have thought of along the way, test those, too.

When you are confident that it is working, let the interviewer know.

Those steps seem mostly like common sense, but in the heat of the moment, if you don't have a plan, it can be easy to panic. Perhaps have a go at using this plan on your own with HackerRank, or on a practice interview with Pramp. Best of luck!