I’ve been a software developer for over 15 years and I very much like it. Like any other job it’s got its ups and downs. But I got to expand my interests, continue to learn about new technologies and I learnt how to navigate technical interviews.
Looking for a new job? Browse Techworld Jobs here.
The first technical test I did was in 2003. It got me a pretty boring job making bespoke websites as a LAMP developer. Thankfully I quite quickly moved on from my boring job, and since then I have no idea how many technical tests I’ve done and also given. It’s a lot.
Here’s the truth: when hiring developers, people are scared. They’re scared that even though your CV looks good, and even though you may have experience and you come across as as sensible person when they talk to you, when it comes down to it you can’t actually do your job - you’re not very good at coding, and you’re not very good at problem solving.
So what do they do? They come up with technical tests designed to work out whether you can actually do a job or not (whether these are successful at this or not, is a different matter).
Some examples of the most common technical tests are: take home coding challenges, technical quizzes, whiteboard challenges and technical conversational interviews. I’ll get into them a bit more and share some of my tips for each:
Take home coding challenges are tasks given to developers to complete at home. Usually they're given a document describing the problem and what’s expected of them. They write and return their code, which is reviewed. Sometimes, (but not always), the reviewer then discusses the code with them. It’s useful to know that sometimes the discussion about the code is as important as the code itself.
My Tip: The first thing you need to think about whether accepting a take-home challenge is the timing aspect. Make sure you’re clear on:
- When you need to hand in the challenge.
- When you believe you’ll be able to do it (this might be a tough one if you have a full life).
- How long you believe it'll take to do it (and as with all estimates, assume you’re grossly underestimating because you probably are).
If the timing sums don’t add up then please go back and negotiate your deadline. You will fail at the challenge unless you do.
Technical quizzes involve the interviewer asking developers a series of questions with factual answers. Like a quiz. For example: “What’s the performance of looking up an element from a hashmap vs. a linked list?”, “What’s the difference between final, finally, and finalize in Java?”
My Tip: One of the reasons companies ask quiz questions is because they’re easily standardised and comparable, meaning they can ask everyone the same questions, and it’s easy to see which candidate answered the questions the best.
Unfortunately this doesn’t make for an interesting experience for the candidate.
If you’re anything like me, when you get bored you get tempted to spice things up a little bit, and try and throw little spanners in the works. For example, during one of these quizzes aimed at a Java developer, I decided to start a conversation about removing inheritance from Java and just using interfaces for polymorphism, and I also decided to argue design patterns were language smells. The poor guy interviewing me was just confused and he thought I was too challenging (probably true)!
My advice is this: if you do get bored, don’t try and spice things up, try and view it as a necessary tick-boxing exercise that should be approached with good grace and cheer.
A whiteboard challenge is where the interviewer describes a fairly chunky problem to solve, and the developer is told to explain a solution on a whiteboard. The interviewer is there to discuss the problem with you, give you hints, and sound out ideas as you go along. Usually on the whiteboard itself you are producing bits of code and diagrams.
A “pair programming” challenge is a different type of whiteboard challenge only with a computer instead of a whiteboard - your interviewer is there to discuss things with you. They describe a problem to solve, as they would for a whiteboard challenge. You then solve it by writing code at the computer.
My tip: Just the idea of a whiteboard challenge is enough to strike fear into many people. The challenges can be practical ones related to your job, practical ones not-related to your job, or even completely abstract puzzles.
Very important: if you are nervous of whiteboards, practice! Get on the internet and find some puzzles and challenges, recruit a friend to pretend to be your interviewer, and pin a big piece of paper on the wall, and give it a whirl. Try to replicate the situation as best as you can anticipate it.
Your first job is to be absolutely crystal clear on the problem. You can’t solve a problem you can’t understand and if you attempt to start on a solution and hope that the details of the problem will become clear as you go along you’re bound to fail.
A technical conversational interview is where you interviewer aims to get you to demonstrate your technical knowledge by attempting to draw it out of you as part of a conversation. For example they may ask “I see you’ve done X with technology Y, what would you do if you could make that decision again?” and hope that you start demonstrating your knowledge of technology Y, and it’s competitors. They’re a blend between a classic interview, and technical test as they’re trying to get more information out of you than just your technical knowledge.
My tip: There’s an old fashioned notion of an interviewer who tries to grill you, put pressure on you, and put you through your paces. Although this style of interview does still take place it’s becoming increasingly rare - especially in a world where there is a lot of competition for good developers. Usually your interviewer will be attempting to gain the information they need to make their decision, whilst trying to build a good rapport with you, and giving you a positive view of their company.
For this reason many interviewers use questions that are designed to extract information, and give you ample opportunity to enjoy yourself and show-off a bit. For example if they ask you to talk about something you’re proud of, they’re hoping to gain more information about your strengths but also they’re giving you an opportunity to talk about something that you’re enthusiastic about and makes you light up.
If they ask you to explain to them a technology that you have had a lot of experience in and they haven’t, they’re of course hoping you demonstrate your technical communication skills and knowledge, but also they want to give you the opportunity to shine by giving you the floor to talk about an area you’re familiar with, and build a genuine rapport by putting you in the position where you’re teaching them about something.
You can think of questions like these as interview gifts. Recognise and embrace them and use them as an opportunity to talk about the stuff that makes your techy toes twirl.
The difficult thing about technical tests is that as they’re designed to test whether you would be good at a job, this suggests that if you fail them in some way you would be bad at a job. A big component that influences the outcome of a technical test is the emotions around i. Going into an interview with the right frame of mind sometimes makes all the difference.
Written by Emily Green, a platform engineer at Pusher. She's been a developer for about the last 15 years, and very much likes it. She's interested in big data, databases, functional programming, and programming languages in general. Prior to Pusher she worked for SoundCloud.