These tips are offered with humility. There’s every chance that I will, in a future technical interview, fail in my endeavours. We all can. Performance on the day is a combination of multiple variables and it’s easy to mess up. I recall a particular organisation that managed to banjax me in two consecutive interviews, with a brain-teaser style test, that I honestly got snarled up in. Twice! Different ones!
Types of Tech Test
- Live, unsupervised – with a tool like Codility or Hackerank, these present you a problem, you choose a language and start coding, with automated tests to give you some immediate feedback, then a final set of hidden tests to test the edge cases you should have thought of
- Live, semi-supervised – you’re coding on a computer with a real IDE and someone’s there to ask questions and then review your code when you’ve done
- Pairing – you’re writing code interactively with the interviewer
- Take home – you’re given a project to do over a longer period of time and present it when complete
Each of these comes with different challenges. Let’s take them in order and look at how to do well/badly.
The Live Test
You’re often working against the clock in some way. You have a problem to solve. Often there’s the stub of the function you’re meant to write, and if you’re lucky there are tests.
- Read the question and consider the shape of the problem
- Then see if you can imagine the movement of any data, or the way the numbers may flow in the algorithm – it’s important to visualise the way things happen dynamically to discover any edge cases
- Start by writing a little code that’s going to fail the test, but maybe set the scene for your algorithm
- Work incrementally
- If something’s making it harder, stop right away
- Similarly, though, find a thing you can basically stick with, so you don’t get lost in options paralysis
- Make a thing that nearly works and debug it
- Don’t forget how to structure code
- Where possible add any tests cases that help you – there’s often a test data input in online tests for you play with, or you can write unit tests if there’s an IDE
It’s easy to forget how to code. We are allowed, even in coding tests to:
- Name variables – included the inputs to the function provided (unless in a named parameters scenario – rate)
- Create helper functions
- Write comments to help ourselves
- Use data structures that partially solve the problem for us
- Write more tests
- Do some debugging – which can be putting logging messages in to explain what’s going on, if necessary
On the whole don’t panic. You can do this. You need to relax, work through the problem methodically, don’t get lost in your own head. Occasionally check the time, but try to ignore it.
I find these very stressful and head melting.
The aim of a pairing interview is 80% collaboration/style and 20% code. You can blow the interview by not being able to write code, but you’ll blow it more if you ignore the advantage of having a pair partner present.
- Think out loud
- Seriously, LISTEN to the other person
- Ask questions
- Make suggestions
- Experiment on a small thing and ask for input
- Don’t try and talk your way out of writing working code or tests – do the work, but with a dialogue as you do it
If you’re good at pairing, this is for you. If you’re not good at pairing, consider the interviewer to be there to help you, lower your guard and work with them.
If you want to mess it up, then stay silent, be defensive, and forget how to use a computer.
Take Home Test
On the one hand this is most in your favour. You get to spend as long as you like on the code (up to the deadline at least). You can use your favourite tools and the internet as much as you want. You get to polish something until you’re happy with it.
The flip side is that these can be very big time commitments, and can potentially be unbounded in size. Perhaps you’ll under do it, perhaps you’ll overdo it in a way which wastes your time, or which puts the interviewer off you. Nobody wants to see overengineering… but then what’s their minimal standard of engineering?
It’s genuinely tricky to find a balance.
- Be yourself – on the whole do it the way you’d do it professionally – no point in putting on a false methodology, only to be told they didn’t like it…
- Do it properly – if there are shortcuts you know you shouldn’t take, but do occasionally, then be a little more on your best behaviour
- Look for clues in the question about how they want it done – perhaps the language of the question gives clues about the method
- Use names from the question in your domain model – make it look like you’ve recognised the business language
- Test it properly
- Produce enough of a README to enable someone to navigate your code and build, but don’t go crazy
I’m in two minds about the home test. I’ve done one recently which was a great experience, followed up by a pairing test. I’ve also seen the home test lose the best candidates from a hiring process because the home test puts up resistance to entry, and good candidates are in such demand that they may prefer easier processes available to them.
A home test that requires many hours of work is a double edged sword too. It’s a bit like working for free… except nobody is going to use your work. You have to decide if it’s a good enough investment in your time for the potential reward of the job at the end.
A Good Sized Challenge
A good test should be easily completed in an hour, and small coding task challenge should be one that can be done in about 20 minutes.
One of my favourite live, semi-supervised tests, was something that I could build in about 15 – 20 minutes. The candidate was given 90 minutes to write it at least once, with a bonus challenge of optimising their first solution in a second attempt. Full access to the internet and the interviewer was given. The candidate was even encouraged to ask “Remind me: what’s that method that does X”.
Candidates who couldn’t get anywhere in 90 minutes, on a relatively straightforward coding test, were demonstrating either an inability to code, or a desperate lack of the above methodology in an interview situation. We used to go over their code, ask them about it, and even see if, given more clues, they could figure out how to fix any errors in it, or improve it further.
The candidates who both knew their stuff, and knew how to listen and think in an interview, did the best.