How to Pass a Coding Test
Simple steps, must dos, and red flags to get you through the dreaded coding test
In this article I’ll tell you how to pass a coding test. I’ve been the interviewer in hundreds or thousands of these, and I know what does and doesn’t work.
Firstly, keep calm. The interviewers want to see that 1) you know what you’re doing, 2) you know what to do, and 3) you know how to behave. It doesn’t help you if you are flustered, stressed, or arrogant.
The challenge will likely sound super complex at the start, but if you dig a bit you’ll find it is way simpler than you expect. Good interviewers are not trying to trip you up. They want to give you the opportunity to show what you can do. These steps will walk you through this process.
Practice, practice, practice
Well before any interviews, practice spinning up a new project (npm init, npx create-react-app, or what ever works for your language of choice) ten times a day, so it is second nature, even (especially?) if you are a senior engineer. You should not rely on reference sites for these basic instructions during the test.
You will give interviewers great confidence if you can spin up a bare environment (with a testing framework) as if it’s second nature. My heart sinks when I see a developer flap about at this stage, and no matter how good the eventual result, I am left with doubts. This is the easiest part of the test to get right, and — equally — the easiest to get wrong.
Do not come armed with a template
Always start from a blank sheet (see practice above). Once you know what you have to build, spin up a bare environment quickly and proficiently, ready to start work. Do this, fuss free, in front of the interviewers.
Any template you prepare will not match the test’s requirements. It will just distract you. You will waste time and look incompetent trying to make it fit. It shows you don’t know the basics and is a red flag.
Think out loud
Express your thoughts throughout the interview to show the interviewers your approach. It’s okay to correct yourself, change your mind, or express doubts. This is way better than silence. The interviewers will want to see if they can work with you and grow you.
Validate and verify by asking questions
The challenge will often be deliberately vague or obscure. This is the first part of the test. You must not make any assumptions. You should admit you don’t understand the requirement, ask them to repeat it, and ask lots of questions.
Make notes
As you ask questions, make a bullet list of the requirements. Share the notes on screen so the interviewers can see how you organise yourself. Make each bullet point pertinent to a part of the requirements; you are effectively writing a specification. Keep it simple. Validate your assumptions and adapt. Do not build what the interviewers don’t need.
Confirm the scope
Ask if your notes capture the requirement. Refine until you all agree they are complete and correct. Then, summarise out loud in plain language.
Explain how you will test your code
Review your bullet points and explain how you will verify how your code will meet each part of the requirements. Maximum bonus points for writing pseudo code tests, even if you don’t believe in TDD. Whether you like it or not, TDD (or something similar) is perfect for passing a coding test as it proves you have delivered what’s needed. Build the right thing, and build the thing right.
Ask if you can use Google
This is not a memory test, so looking things up on reference sites should be okay as that’s how developers work. However, ensure you are not looking up basic things you ought to know, and refrain from copying and pasting from StackOverflow.
I’d avoid relying on ChatGPT. All that shows is you know how to use that service. It doesn’t really prove that you understand the fundamentals of your craft. Save AI for when you’re on the job.
Start a test watch
Do whatever your coding language needs to start automatically running tests as you code (Jest watchAll or similar).
Write some tests
Write the tests you outlined above. They will all fail as there is no code, but that’s fine. See TDD above.
Write some simple code
Finally, write some code that delivers the requirements. If you’ve followed the steps above, you’ll be surprised how little code you need to write. The test is less about writing code than it is how you work.
If your test involves front end work, use a CSS framework to make it look presentable, but focus more on functionality. Keep presentation tweaks to a minimum. Of course, if the test is about your design skills, lean into it more. The point is, don’t overwork style and presentation at the expense of delivering what the interviewers are looking for from you.
Moving forward quickly and simply is best. If you want complexity, get there in small steps. Show lots of working code and avoid rabbit holes.
It’s way better to build something small and simple that works than to go for perfect but broken. Move forward, get your tests to pass, then add a bit more complexity. Rinse and repeat. Get to the point where if you stopped coding now, it works, even if you haven’t delivered the full scope.
Stop coding when the tests pass
This is just a coding test, so stop writing code as soon as all the tests pass. Confirm to the interviewers how your code meets the requirements. Show you understand the code you have written. Say how you might improve it. Avoid overly finessing your code. See ‘adding complexity’ below.
Be humble
There will be things you don’t know or can’t do. Don’t pretend you do, and don’t assume you know everything. Interviewers smell BS and don’t want to hire jerks.
If the interviewers ask how you would do something and you don’t know the answer, say so. I suggest something like, ‘I haven’t done that before, so I wouldn’t be able to do it in this interview. However, what I think I would try is…’ and then think out loud. This shows honesty, humility, and creative thinking.
Respond positively to feedback and challenges
Throughout the interview, the interviewers will ask about your approach and look for alternate methods. They will interrupt you and challenge your work. Sometimes, it’s okay to back yourself, but often, it’s best to walk with them as they have seen something you can improve. They are watching your approach and openness to feedback. Listen and ask clarifying questions first. Be ready to change your approach.
Expect more complexity
When you think you are done, the interviewers will likely increase complexity to see how you can adapt your code before either the time runs out or you’ve reached your level of expertise. Sometimes, your chances of landing the job at the right level depend on how far they can take you in the test. Therefore it is important to get to fully working code as quickly as possible to allow the interviewers time to stretch you some more.
Respond well to questions and feedback
Everything above shows the interviewers that you can understand requirements and know what you’re doing. The most important part is how you behave as this gives insight into how easy you are to manage and how well you’ll work in a team. You’ll show this by listening, asking good questions, accepting challenges on your approach, being flexible, humility, admitting what you don’t know, and being open to feedback.
Red flags
You will fail the whole test if you start to code before understanding the requirement or if you are silent, waste time looking up basics online, take too long to get into the meat of the test, refer to StackOverflow too much, design something that’s overly complex, hesitate too long, do not deliver working code, obsess on style over substance, or do not ask enough questions. These show inexperience.
Being overly defensive of your approach or inflexible are traits of brilliant jerks, and they never last long.
I’ve seen people break all these rules and still deliver perfect, working code that meets the requirements. This doesn’t really impress me. If they don’t ask lots of questions about the requirement, zoom straight into complex code, and somehow deliver what we need, I’m left scratching my head. Was that luck? How does that translate into daily working life? Did they already know what the challenge was?
Always remember that how you work and interact with the interviewers is every bit as important as the results you deliver in the test.
Good luck!
