Interviewing technical candidates requires preparation and knowledge of the subject matter – there’s nothing more frustrating for a Java developer to be interviewed by someone who knows nothing about development or Java.  When we interview someone, we are doing so for three purposes:

1. Can this person do the job we need them to do?
2. Will this person fit into our organisation – do they have the right sort of personality?
3. Does this person want the job – are they going to have the drive and enthusiasm that we need?

To do this effectively, you need to plan, and have a set of fixed questions that you ask every candidate – the questions need to cover the candidates’ ability to do the job, and should be forward facing rather than a retrospective on their CV. Obviously you can ask additional questions as needed, but asking everyone a set of standard questions will provide you with a benchmark against which to evaluate people.

Can this person do the job we need them to do?

All jobs share two fundamental principles: communication and collaboration. These can easily be tested – I’ve interviewed thousands of candidates, and those that are poor at communicating are easily identifiable – they give short, often mono-syllabic answers, and rarely elaborate on a topic. For some jobs, it’s less important than others, but these days good communication skills are increasingly sought – the days of a surly developer typing with their head down and headphones on are numbered.

Collaboration can be tested in a number of ways – by asking for examples of projects where collaboration and or leading a team has been important; for developers, a pair programming test can be highly effective in determining how they work with others*.

Technical questions by necessity vary by the particular skills needed for an individual role, but should aim to probe knowledge and determine the extent to which a candidate has knowledge of a particular (and relevant) subject. Where a candidate demonstrates that they have knowledge of, for example, Kubernetes, they should be pushed to show the limits and depths of that knowledge.

Technical testing may be done through a written or verbal test or whiteboarding exercise. There are merits to both, but any test should be generic and designed to test general principles, and not an exercise on resolving a particular problem for the company – I’ve known companies who have had gained a reputation for using their technical tests as an opportunity for free labour, and they’ve struggled to attract candidates. Bear in mind that your candidates are probably interviewing at a number of places and so won’t take kindly to being asked to do a test that will take eight hours to complete. Reviewing code that they’ve created for a personal project on GitHub can act as a good alternative to a coding test.

Once you’ve established that a candidate has sufficient coding abilities then probe their problem-solving experience

Personality and Fit

Recruiting people who are all of the same mould won’t benefit the company, but having people who don’t share the company’s values will cause problems down the line. What are you looking for in a candidate’s personality and why? It’s important to determine this at the outset, and recognise your unconscious biases whilst interviewing – consistent studies have shown that diverse companies are more successful.

Does this person want the job?

They might be technically good, and they might fit with your company, but do they want the job? If they don’t really want the job, they are likely to be less motivated and more likely to leave quickly – which will impose additional recruitment costs on the business when you have to recruit someone else. You shouldn’t make assumptions here – ask and question candidates’ motivation directly.

What should you watch out for?

Enthusiasm: candidates don’t need to be the Energizer bunny, but it’s important that they both show an interest in your company and in they work that they do. Someone that isn’t interested is likely to have a demoralising effect on their team.

Flexibility: everyone has their favourite tools and languages, but that obsession with Trello won’t help if you use Jira, nor will a determination to only use Vue.JS be useful if you’ve developed the UI in React.

Heads-Down Developers: Does the candidate get involved in the full SDLC, or are they simply and mindlessly building code? It’s important to have developers that get the bigger picture and understand the needs of the business as well as being able to write code.

Tips

Don’t overload on theoretical questions – not all good developers know the answers off the top of their head. Rather look at their ability to analyse a problem and produce a solution, and look at how they code instead of whether a piece of code written quickly and under pressure is flawless.

Always test out questions on your colleagues first and make sure you understand the answer that you’re expecting – there’s nothing worse than getting stumped out by your own question in an interview.

And Finally…

We’re in a candidate-driven marketplace, and there’s strong demand for good tech talent. You need to sell your company to candidates, and that means making sure that candidates have a good experience from start to finish. Keep the interviewing process swift and friendly – and bear in mind that interview experiences get shared on Glassdoor and across social media.

*Not all developers have experience of pair programming, and it can be daunting to be exposed to it for the first time at interview – bear this in mind!