Code testing interviews - be prepared!
For many people the concept of producing working code in an interview environment is daunting… especially when every step is monitored, discussed and scrutinized by a potential employer.
Yet despite Google writing off brainteasers, and David Heinemeier Hansson (creator of the Ruby on Rails coding framework) starting a protest against ‘whiteboard’ interview practices in 2017 - we’re still commonly seeing tests used at interview, on platforms like Codility and Hackerrank; with Codility (at time of writing) reporting 5,791,556 assessments alongside significant customer growth.
We spoke with Tom Booth from Caspian One and Manager Danielle Gray, on the subject of code testing. Tom reported that with our UK clients specifically, there has been a notable increase in code testing - whether that be tests through a software platform, requests to find problems in broken code, or being asked to create code face-to-face.
This is mirrored by feedback from Danielle, who notes that with our Canadian and US clients, code testing at interview is on the rise; becoming almost a standardised part of the hiring process.
In this article our goal is to prepare you for these tests - with advice, best practice, resources and some practical exercise you can action.
If you'd prefer to speak with our team directly on this subject, contact us
Starting from the beginning…
What are code tests?
The most common explanation is also the simplest. Coding assessments are designed to add more efficiency to recruitment by discovering the capabilities of a candidate early in the process. Tests are typically seen in the first interview stages where implemented - but can also play a part in pre-interview candidate screening. For example, if a Java developer vacancy receives 100+ applicants then a test may be shared, with results considered when determining who progresses to interview.
If you were a comic book artist applying to work at Marvel Comics, you’d expect to be asked for a portfolio that demonstrated your artistic skills. No restaurateur would hire a chef without tasting their food. The same logic applies here.
What should you expect?
There are three types of testing methods most often seen:
One is a problem solving online assessment, usually multichoice in its structure, and self administered with no supervision. We use this testing style at Caspian One with our candidates. It’s also the go-to option for most employers.
Questions and tasks presented are predominantly subject and/or language specific, but generalist brainteasers are also incorporated - assessing not just a persons technical strengths, but also factors like how a problem is approached, time management and speed.
It’s important to note that ‘change the industry’ coding isn’t being asked for in these tests. The intent is to understand your capabilities in the real-world, so scenarios will reflect real life expectations. They want to understand not just your skills at coding, but also how you approach problems and the path taken to reach an answer.
“Early on in the interview process, we set candidates up with our first test...Basically, we need to see if the candidate can write any code at all. You’d be surprised how many candidates fall short when it’s time to put the cursor to the editor.
For people with any sort of decent programming chops, it will take a little effort but shouldn’t be super challenging. Consider it a “price of admission” test. The work on this test has no practical application beyond showing us if you can write any code.
If someone’s banging their head on the desk and can’t get through it, there probably isn’t a relationship in store for us. Most reasonable coders we’ve given this to have gotten through in about 20 minutes.”
- Atlassian (How and why we use coding challenges to interview developers)
The second method is a ‘build’ project. These can vary in requirement, but usually ask a candidate to create an application (or similar as suited to the position) to certain standards within a specified timeframe. If requested we typically see these tests in the latter stages of an application, and in most cases these projects are requested as homework (which can bring its own issues).
For example, we’ve recent had a group of candidates asked to develop a calculator app...
As with the online tests, clients are looking for more than just technical skills when assessing builds. In the calculator example, some candidates returned basic calculator apps that could add, subtract etc… whereas others produced scientific calculators in half the time, demonstrating both skill and commitment to the vacancy. Guess which one’s progressed.
Third is the ‘whiteboard’ interview. This live-action style of testing sees a candidate presented with a - you guessed it - whiteboard, along with a coding problem. They’re then asked to not only solve the problem, but also walkthrough the thinking and steps taken to reach the solution.
“The problem may take up to an hour to solve, and the entire interview may last a day. Still, if you’re going to work with these people, then you might as well get to know them, right? What you have to keep in mind is that while it might be called a code or whiteboard test, it is not so much a test of your code as a test of your problem solving abilities.”
- Skillcrush.com (Everything you need to know to rock your next whiteboard test)
We’re also witnessing more uptake in collaborative online coding that mirrors the ‘whiteboard’ experience; presenting someone with a coding problem via an online portal which the interviewer can then monitor, question, engage with etc… For example see Codility ‘CodeLive’.
There are other variations of the ‘code test’ but what’s true of them all, is they look for more than technical capabilities in candidates. Companies need to know you can code, but they also need to understand ‘how’ you code and ‘how’ you tackle real world problems.
What if I refuse?
You are entirely able to refuse. That is your choice. It’s true that a number of people we support are not happy having to ‘prove’ their abilities, with numerous arguments made for why they shouldn’t have to be tested.
However. The reality is that companies define their hiring plans, and if they’ve determined there is a need to test candidates, and you refuse... the likelihood is you’ll be removed from the process. The choice… is yours.
How can you prepare in advance?
Practice. Practice. Practice.
Best case scenario, you ace each and every one and feel really confident pre-interview.
Worst case scenario, you realise there are holes in your knowledge, you’re too slow and solving problems or you find coding in a test environment difficult. The good news is you now have time to correct these pre-interview. Either way it’s win:win.
Take a look at:
Codility - https://app.codility.com/programmers/
Coderbyte - https://coderbyte.com/
LeetCode - https://leetcode.com/
GeeksforGeeks - https://www.geeksforgeeks.org/
Careercup - https://careercup.com/
Codementor - https://www.codementor.io/
Plus resources such as;
Also take a look on Amazon for 2 minutes and you’ll find a wealth of books and materials written to support code test interviews, for example: https://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Dstripbooks&field-keywords=code+test+interview&rh=n%3A283155%2Ck%3Acode+test+interview
Caspian One actively support their candidates through all hiring steps, including tests - with practical advice available as required. For more information or to discuss our latest vacancies contact us at firstname.lastname@example.org
Have your say - comment below.