🚨 33% off all courses for Black Friday + THREE brand new courses: Intro to Python, Python for the Web + Shaders for the Web!

Ask a Coder #1: How Do I Do Well in a Coding Test?

Posted by

Rik Lomas

Published on

August 5th 2020

Here at SuperHi, we get a lot of questions from our amazing and creative students. What we've realized: learning and growing doesn't stop after you complete a course or learn a new skill. It's an ongoing series of ups and downs, challenges and blurry lines, doubts and insecurities, a sometimes muddy mess of hows, whys, what ifs and what nows? We see these questions and we hear you: it's tough out there.

Welcome to our third edition of a 6-part series with our resident advice columnist (or as our UK constituent of the team calls it, “Agony Aunt”), where we aim to get real, get deep, and get practical with your most burning questions about life and career in the creative industries. Today, we’re saying hello to Rik Lomas, founder and CEO at SuperHi, as he takes on the mantle to answer your code and career questions.

Hi, I’m Rik Lomas, the CEO and founder of SuperHi.

On today’s Ask a Coder, I’ve been asked, “How do you do well in a coding interview, especially if they ask you to code in front of them?”

Firstly, I just want to say that I’m not a fan of coding tasks where you’re put in front of someone. I think it puts unneeded pressure on the person applying for the job. Also, it’s incredibly unrealistic to be put in front of that position. You’re not ever really under that amount of pressure. Actually, one of the best ways I’ve heard of realtime a code task is done by Sanctuary Computer. Their process is they’re given a task, and the interviewer goes away, and they check in every now and again. But that interviewee is given time and space to think.

But let’s say you’re put in front of a whiteboard or a laptop and someone’s watching you. What I would want to hear is someone talk through this process. I don’t really care if they’re getting the code wrong, but I want to see this way of working.

A bug in your code is a lot less of a problem than getting the process wrong.

You can fix bugs by Googling them or using Stack Overflow or asking the SuperHi community.

Let’s take an example problem: for example, coding up a lightbox on the website. So the first thing I want you to see is the process to how to solve the problem in normal human language. So in English, for me, I want to know exactly what a lightbox does. When a user clicks a link, something happens. Well, what happens? Well, a box pops up with some content. What content is that? Well, it depends on what was clicked originally. How does a user get rid of the lightbox? Well, they click the close button, and that lightbox goes away.

Let’s write this out in plain English. So when you use a click to a particular link, some code is run. This code gets the relevant content to style up the tag and show it to a user. We might have other things pop up as well, such as a close button, maybe a background. When the user clicks this close button, for instance, this tile tag disappears.

So this process is what a hiring manager like me would be looking for.

I don’t really care if you’re using a certain library, unless it’s really part of the job description. I want to see you get this process correct.

Writing this out at the start will give you a lot less pressure towards the end of the task, because if you’ve run out of time, a hiring manager will still know what process you would have taken and what approach you would have taken.

Don’t be afraid to say, “I don’t know,” to a question, too. Some of these hiring processes can have some gotcha questions in there on purpose to see how you react under pressure. I’d rather see you say that you don’t know, but that you do know where to look up the answer, than just bullshit your way through a question, for instance.

Lastly, you may not get the job. Some companies have a lot of people applying for the same role, and it can be nearly impossible to pick between people. At SuperHi, for instance, we’ve had 3000 people apply for one job role once, and we’re just a small company. That didn’t mean there was just one good person. We actually had to turn down a lot of fantastic and talented people that we would have loved to have on board.

Then know it doesn’t mean that you failed. If you do make it to a code test and get a no, ask for feedback from the hiring team. They may not give you the feedback, but there’s no harm in asking, and that could really help you out for future applications.

Good luck with all of these interviews!

Rik is a Mancunian coder, teacher and CEO of SuperHi. He was the co-founder of Steer (a code school in London) and has taught several thousand people to code. If you have any creative career questions you’d like answered, you can ask here.

Illustration by Gustavo Pedrosa