You spend your whole career being scared of completing a coding interview, and then suddenly you're tasked with creating one to use in your hiring process. Where on earth do you start? Having been recently been in this situation I thought it would be good to share the thought process I personally went through.

First up, what format works best?

The initial question I dealt with was whether or not it should it be a take home or a live test. Take home tests offer people more space to be with their own thoughts (and potentially a closer to a real life scenario). However, being able to go through the test with people allows you to see how they communicate and collaborate and learn a bit more about them on the way.

It's also a positive that these are usually shorter and so take up less of the candidates time!

Time for some reflection

It’s unlikely that you will be creating a coding interview before ever completing one yourself. So, taking time to look back on those you’ve done before is a great place to start.

Think about which ones you enjoyed, gave you a chance to show off your skills, and represented what it might be like working at the company. For example, in one of my favourite interviews I was given a PR, asked to run through a review for it, then fix a few bugs and add in a small feature. This really felt like it would be similar to how I would work day to day if I was to join them.

Take inspiration

Another great source of input is looking at companies that you respect and see what they offer as their code interview if it is available publicly. I knew there were people far more experienced who share how they do it, and this allowed me to work out what the key ingredients were.

What are you trying to assess?

Now it’s time to focus more inwards. What are you looking for in a software engineer? Do you need to verify their frontend and backend skills, or is it better to focus on just one of those?

Usually you want to keep your interview fairly snappy, so you want to limit the what you cover, as it might be hard to dig deep enough to be helpful otherwise. For example, we don’t include testing as a requirement in our interview as it’s not something we feel is a skill we need to see demonstrated, however this might not be the case for another company where TDD is a key part of the workflow.

Make it snappy

There are a few key parts that need to be thought about to make sure the interview runs smoothly in a short time-window.

Firstly, making sure that the topic of the interview is quick and easy to understand is a must. You don’t want the candidate spending the first 10 minutes just trying to work out what you want them to do, it should be clear what the end goal is for the test.

Secondly, getting the environment set up right for the test is important. Relying on a candidate to have everything set up to the correct version is risky. A great way to get around this is to use a tool to host the interview, for example CodeSandbox. This means you can just send them a link and they won’t need to install anything on their own machine. It also means you can review the code again after the interview if you are so inclined.

Building it out

Now, it’s time to build out the code test. The most valuable approach for everyone involved is if you can simulate the working environment they would be coming into. If they are going to be working on an existing codebase that might have its issues, make sure you throw some bugs in to the test so you can see how they find them and deal with them. Something I made sure to add was a really small bug at the start that is simple to fix, this tends to give the candidate a bit of confidence and relax them into the process.

Once you have your first attempt up and running, time yourself trying to complete the challenge. Given that you have so much more context and built the codebase, you should be able to easily complete the task. If you couldn’t it is probably a sign you need to reduce some of the requirements.

Documentation

There are two parts of your interview that will need documenting. Firstly, some sort of marking scheme for interviewers to use, this can define how you pass or fail someone as well as how you can level them in terms of seniority. The other is for candidate, which lists out the requirements for the interview, which you could share with them in advance. By matching the style of how they might get requirements internally they can get more of an idea of how your company works. It also allows them to come in with some prior understanding so they are likely to feel a bit more confident and get going quicker.

Test run internally

Once you’re happy with it see how many volunteers you can drum up from your existing engineering team. Observe how they go about the task, check the timings and see if the expectations you have in place are realistic or if they need rethinking. It is also a great time to see if there are bugs that you didn’t mean to have in there!

Feedback and iteration

Then come the first few times running the interview for real. Most of the time a coding interview will only need one interviewer. However, it is important for the first few runs to make sure that you pair with another interviewer. This allows you to both feel more comfortable running the interview as well as becoming more aligned on how to mark the interview at the end. It is also a chance to call out if there are any more tweaks needed to how the interview runs.

It's important to remember that you should make sure to reflect and change continually as the team grows. A skill you are looking for right now, might not be the same in 3 years time.

Hopefully an insight into how I created my first coding interview came about can help guide you somewhat!