Mistakes – The Dreaded Tech Test

Whether you’re applying for your first role in test automation, or you’re a seasoned veteran who’s on his fiftieth contract position, having to do a technical test is just part of the process when going through an interview.

Technical tests are a necessary evil, they filter out those who lie about or exaggerate their experience on their CV and they determine suitability for the role based on a number of factors such as approach to problem solving, quality of code etc. Unfortunately though, companies often have inappropriate tests for the roles they are advertising for, which can often mean highly skilled candidates are being turned away because they are being asked to do something that isn’t part of the role.

However, whether the companies are giving the most suitable technical tests or not, the fact remains that they are just something you will have to deal with in this line of work.

I’ve done so many technical tests in my career, most of them at the very start when I was an aspiring games developer. I’ve experienced all kinds from having to write code by hand on a whiteboard, do a coding challenge with people watching you the whole time, being left for an hour to write a year worth of code and being sent a challenge to do in your own time at your own pace (within reason). The most daunting of those listed are the ones where people are watching your every keypress, as its amazing what simple things you can forget under that kind of pressure.

Which ever test it is you’re being asked to do, these small pieces of advice I’m about to give applies. I’ve made all the mistakes I’m about to talk about and more.

Be Prepared
This might sound obvious, but you’ll be surprised at just how much preparation you can do before doing a technical test. If a recruitment agent put you forward for the role, speak to them to find out what they know from previous candidates they’ve placed or who might have gone for the role before you. This isn’t cheating, they won’t be giving you the answers or a copy of the test, but they can help with the feedback they’ve had from previous candidates about what was expected, what candidates did well and what they didn’t do so well and what sort of things the company really don’t want to see.

If you applied for the role directly, make sure you understand what it is the company does and what the particular role you’re applying for is doing. Understanding this will help you narrow down the context of what the test might be. For example, if you’re applying for a test automation role in an API team, chances are, you won’t be asked to write a Selenium WebDriver test, and instead, you’ll want to make sure your backend coding is up to scratch.

Don’t Panic
This mostly applies to face to face tests, and again, this might seem obvious but it’s important to emphasise this point, do not panic. If the task seems daunting and far too big for the time allocated, then don’t stress and feel that you absolutely have to do everything right now and you’ll never manage. Like with any code you write, take the task and break it down into smaller bits, and if you know 100% that you will not be able to complete the task in the time, take these smaller bits and do as many of them as you can well as opposed to attempting all of them badly.

I’ve been sat in on technical tests where we’ve asked candidates to do a stupidly big task that is virtually impossible to do in the hour we give, but we are looking for candidates to do bits well and see how they handle time management. Candidates would be rewarded more for doing the bare minimum of what was required to get the program building and running well as opposed to doing everything and it being very poor code.

Think Ahead
One of the best pieces of advice I can give when it comes to getting through a technical test is don’t be afraid to think ahead with your code. When writing classes or methods, think about how the code you’re writing could be reused if it was being used in a broader project.

For example, let’s say the technical test is asking you to write a set of tests for a companies web page. It would be very easy to write methods that have hard coded values in or don’t use parameters because they are for a specific purpose and won’t be used for anything outside of this particular scenario.

Show the interviewers that you think ahead and you write good quality code. Use parameters to make your methods flexible, use smart locators that would still work in the event of a different scenario being tested. When writing classes, think of using things like base classes for certain object types so that they can be reused or added to later on.

I can’t stress enough how much this approach will be rewarded. I’ve marked numerous tests where the code might not be of the highest quality in terms of it being the most efficient, but the thought process behind their class design or the modularity of the code meant that they got through it.

Write Tidy Code
When you’re pushed for time and under pressure, you might put the tidiness of your code a bit lower down the list of priorities than you normally would, but don’t.

Leaving unused usings or variables scattered around your code gives a bad first impression of the sort of code you’ll be writing if you were to get the job. Spelling mistakes in your method or variable names is a big no go as well. This might sound unfair but remember, the test may not be all about finishing the task at hand, it’s more to do with the code you write and how you approach it. If they think that you write sloppy code in a small test, then it would be harsh but fair to assume that you probably write sloppy code all the time.

Take the time to make sure your code looks presentable, if white space or indentation is off, take a minute to fix it. If you’ve written something that you no longer need, remove it. Don’t leave commented code everywhere

Don’t Try and Show Off
This happens a lot and it’s frowned upon in a big way. If you’ve been asked to do something, then do that and do that only. Don’t write extra code that has no benefit to what it is you’re trying to do, just to show off your understanding of something that you think might impress them. Not only are you robbing yourself of time that could be used to improve your code, you’re also likely to rub someone up the wrong way if they don’t understand why they are looking at irrelevant chunks of code.

Do what’s expected, and do it well. If you have time to spare, document your code or see if there’s room for improvement. Don’t be tempted to try and show off.

Understand Your Code
This only really applies if you’re doing a test in your own time, and like a few of the other points, it should be obvious. If you absolutely do have to get help via Stackoverflow or other online resources, at least make sure you understand the code that it is you’re using. If you don’t understand it, don’t use it.

I’ve been in the awkward position a few times of having to ask candidates to explain their code when it’s clear that they’ve just copied and pasted a lot of it. It’s clear almost immediately that they’ve done it when they can’t explain easily what the code is doing or more importantly, why they chose to do it that way.

Even if the code is 100% yours, have a few practise runs to yourself or to someone you know, going through your code and talking about why you approached the task in this way and what you’ve done. If you can do that and sound confident about it, it will go a long way in convincing someone hiring that you know what you’re doing.

Hopefully someone will benefit from this article and help you prepare for a test, or even better get through one. But while it’s important to talk about preparing for a test, it’s also important to stress that if you do take a test, but fail to get through, don’t be disheartened.

Like anything in life, there are lessons to take from failure, so don’t be afraid to ask for feedback. If you are able to understand where you went wrong, you’ll be able to address it in the future. Having experience of taking a few tests under your belt will only benefit you when doing them in the future as well when it comes to nerves or knowing what to expect.