Coding interviews are universally considered pretty horrible. You have a set amount of time to complete a task that has little resemblance to the day to day job of being developer, in front of someone who knows the answer to the question and holds your fate in their hands.

It's not wonder we don't like them!

Whether you are a seasoned pro at coding interviews or a complete newbie who has only ever heard the horror stories we can all improve. Here are my tips to getting through your next test.

1. Play the game

We all know that you won't have to reverse a linked list in the actual job, but during the interview you need to forget that. Whatever challenge they have you do, treat it like a real work task, that way when you get stuck and stressed your brain won't be saying "this is madness, the job won't be like this!" If you let those thoughts get in to your head you will get in a downward spiral that won't do you any favours.

2. Question and clarify

On the topic of making yourself believe this is a proper task, really treat it like one. This means you ask questions to clarify what is required and clear up any ambiguities there are in the task. If you don't understand something the way it is written, don't be afraid to speak up, it could have been written in such a way to make sure you ask questions. Often the most important parts of an interview happen outside the core test so asking questions, clarifying points and reiterating what they want you to do is vital because those are all things you will be expected to do in the actual job.

3. Check the rules

It's no secret that Google is the main tool in a developers box and a good interviewer will allow for this. Don't sweat through not being able to remember the syntax for .reduce() when you could Google it. Ask at the start of the interview if Googling is allowed and to what extent you can use it, if it's a solved problem (like reversing a linked list) they will say not to Google that explicitly, but usually language syntax and standard library functions are fair game. Each company will vary slightly and asking what is and isn't allowed is only a good thing.

4. Talk, talk, talk

Don't code in silence, make sure you are verbalising your thoughts. This felt very alien to me the first time I did it so I would suggest practicing on a small problem yourself, get used to talking about what you are coding, tell them what you are thinking and the trade offs you are making. Don't think in silence and then write code, the interviewer isn't a mind reader so help them out. If you are making a trade off between two approaches ask for their input. For example "do we want faster reads of writes do you think? I'm thinking the writes are more important but would love your input"

5. Tell them what you're skipping

If you are taking a short cut that you wouldn't usually do then tell them and explain why. If you don't want to waste 10 minutes setting up an automated test library and you normally would then let the interviewer know that. This goes hand in hand with talking about what you are doing and could subtly de-rail you if you skip over something without addressing it.

6. Test as you go

Don't forget to run your code. Don't code for 25 minutes and then run it for the first time! They want to see an iterative process, how you respond to errors and how you debug them. Don't be afraid to debug with console.log('here') if that's the best tool for the job, they want to see how you solve problems, how you deal with roadblocks and how you think.

7. Be yourself and be honest

Imposter syndrome is horrible, made worse by if you actually are one! Be yourself in the interview, code how you want to code and make your level clear. The last thing you want is to make out you know things you don't, or have experience you don't, only to get found out on the job. Don't let the pressure of performing in an interview change who you are. If you code as you and don't pretend to be smarter or more experienced than you are then you can go into that job imposter syndrome free 😀