I’ve been a software engineer for about ten years, and here’s something I learned: hiring software engineers is hard. One of the main challenges is to get the most information about the candidates in the minimum amount of time. You want to know if they will be a good fit for your team, and you want to know it quickly, without wasting their time.
In this article, I’ll go through a list of the various techniques I’ve seen, describe the one we are using at Tanker, and why it works best.
A tour of existing techniques
The whiteboard
Let’s start with the infamous whiteboard. You ask the candidates to write some code from scratch on a whiteboard to solve a given problem. This can give you an idea of how they think or how they approach new challenges, but bear in mind the whiteboard can get very intimidating for some developers, so they may appear less bright than usual.
All in all, the whiteboard is a peek into the reasoning abilities of the candidate. Still, it doesn’t give any information about the ability to work in a team, understand a new codebase, or their skills with a given programming language.
The homework
Another technique is to ask the candidate to implement a project “from scratch” at home. This technique avoids some of the above pitfalls, and you can quickly gauge the candidate’s level of competence.
Note that you only get to see how they work alone and when writing code from scratch. Moreover, either it means a big-time investment for the candidate or the project is too small to correctly judge their skills.
None of these techniques match our needs: we are a team with a flat organization in which each member has the right to contribute to important decisions. Besides, we already have a pretty large codebase, so future recruits will mostly work on existing code.
For these reasons, we use a refactoring exercise, a technique I learned about during an episode of Ruby Tapas presented by Nickolas Means.
As the name implies, the candidates will have to refactor some code. They also will have to demonstrate other abilities like reasoning about new features and dealing with tests.
Here’s how it works.
The Refactoring Exercise
Before meeting the candidate
First, take a simple problem and implement it. The code does not have to be very long, but you should make sure there’s room for improvement: leave out some duplication, use functions with lots of parameters, or other anti-patterns. However, do use features you want the candidate to be familiar with.
Then write some basic tests and think about a new feature to add, but don’t implement it. This will be important later on.
Running the exercise
Remember, your goal is to gather the most valuable information about the candidates: you want to see how they work when they are at their best.
For instance, it’s crucial to tell the candidate about the refactoring exercise, so it’s not a surprise for them to make sure they bring their own development machine.
When the candidate arrives, show them the code and tell them about the problem it’s solving.
At this point, the code should be in a state that makes it hard to implement the new feature without refactoring.
Then announce the new requirements and wait. Make it clear that the code should be production-ready.
- Do they ask for existing tests?
- Do they try and refactor first?
Your goal is to see if they think about those “good practices” without a prompt from your end. But if they start writing the new code directly, it’s not a red flag per se.
You do want to see how they refactor and use tests, though, so if they skip all of the above, just gently nudge them in the right direction with questions like “Is there something you want to do before implementing the new feature?” or remarks like: “By the way, there are some tests if you think that’s helpful.”
Your goal is to keep them comfortable, so don’t make them think they have failed if they did not ask about tests or refactoring right away. It happens.
The rest is straightforward: watch the candidate do the refactor, implement the solution, and add tests. Note that the whole session should last about 30 minutes.
What running the exercise tells you
Let’s recap what you’ve learned during the refactoring session:
- You have a pretty good idea about the candidates’ skills and knowledge in your programming language
- You can see how they make decisions about adding features, adding tests, and architecture of their code
- You make sure that they can convert requirements into code
- You know how it would be like to pair-program with them
At Tanker, we’ve been using this technique for quite some time, and it has worked very well. It gives us a good idea of how candidates will do all day, every day — and all of that in 30 minutes — not bad!
Interested in joining us? Have a look at our job openings.
Previously behind a paywall: https://medium.com/tanker-blog/the-quest-for-a-better-hiring-process-d237b36f682f
