The need to expand your development team is a fantastic opportunity to bring in new skills, new expertise and new thinking to your existing team.

Finding the right person to join a group of developers who already work well together is a daunting task and one way I’ve found to make sure that everyone is on board with the new team member is to make the existing team part of the recruitment process.

But how to go about ensuring you pick the right person for the job? Simple steps like starting with a phone interview, asking questions around the role (and not fantastically complex logic puzzles – like, how would you move a mountain) and bringing members of the existing team in for the face-to-face interview are all great, but none of that actually tell you what sort of a coder they really are.

One way to solve this is with a simple coding challenge. Something that can test their ability to solve problems but also allows them to show you what they can do, and whether they tick some of the starter-for-ten boxes in terms of software development.

What you’re actually getting is a great indication of how they put something together from scratch

In all my previous team management roles, I’ve used the same challenge – ask the applicant to write some code that connects to a public facing API, consume some data from that API, do something with it, and present your findings to the person running the app.

Now that’s tremendously vague, and it’s supposed to be. If they’re applying for a web developer role then you should expect something web-like, if it’s a dev-ops role then it might be something like a command-line script.

What you’re actually getting is a great indication of how they put something together from scratch – are they using modern dev techniques, are they including tests, or handling user inputs properly. Do they include a readme in their repository, do they baulk at the idea of source-control and want to send you a compressed file of their project instead. Is it properly object-orientated or are there global variables everywhere?

If they haven’t realised that this is their chance to show you what they can do, and if you feel that they could do better, tell them that. Give them a second chance – there’s no rule that says you can’t.

Once they’ve submitted their code, offer it up to the existing team to run – is the readme sufficient, what feedback do they have for the developer? This might seem harsh, but seeing how a potential team member deals with constructive feedback is key to understanding how they’ll deal with a peer-led code review.

Often a really good submission will be followed up with a great face-to-face interview, but sometimes you will wonder how the developer in front of you submitted a fantastic set of code. Just don’t forget to take into account nerves at the face-to-face stage. To help ease the nerves ask them about their submitted app, this will ground them as they discuss something they’ve recently written much more easily than something from a project a few months or years ago.