From my long-term work experience I’ve got a lot of consulting practice on recruiting process of programmers in some of the biggest IT companies based mostly in central-eastern Europe.
We have written a lot on technical interviews. Check out The ultimate guide to the technical interview.
Challenges in interviewing developers
When I started interviewing developers there was no time for active programming and coding tests. We had a lot of candidates, so we had to stick to one hour limit for every issue – soft and technical assessment as well as financial negotiations. Finally we were hiring around 5% of initial candidates. After trial period about 90% of them continued working. It was quite good conversion rate.
But after calculating costs that were caused by inappropriate hiring decisions we realized we were wasting a lot of money. Salary, HR, office, notebooks, senior developers time for kick-start, etc. Expenses additional to salary were on average almost doubling final cost.
There were three major reasons for not hiring developers after trial period:
- they were unable to work in the team,
- they had only theoretical knowledge,
- they were working much slower than expected.
The reason why we weren’t able to find out all those disadvantages was skipping active coding tests during the interview. Hiring software developers without checking if they really can code fast and smart is similar to buying a car without verifying if the engine works.
So how could we check all of these weaknesses in just 60 minutes?
The answer is simple – we couldn’t! We had to extend interviewing process by at least two hours. But prior to doing that we were forced to limit the number of candidates at first. We decided to make 15 minutes phone screening by asking 10-15 technical questions as well as getting to know their salary expectations. On that basis we’re inviting candidate again or not. Screening process allowed us to reduce number of next necessary meetings by almost 40%, which was worse result than we expected, but good enough for extending the time of every single interview.
We’ve been trying to find a solution to verify if each candidate is on the same wavelength with the team as well as if they can use the programming languages we usually use on a daily basis. Independently of required coding skills at programmers work we put emphasis on the way they are thinking, especially as it affects their ability to communicate with others.
Is pair programming a solution?
The idea was to do pair programming! Cool – we’ll get the best of both worlds. The assumption was right for around 70% of our candidates. As a result one-hour coding session was sufficient to see how someone will act in our demanding and specific environment – both in using possessed knowledge in practice, using ability of quick information processing, flexibility and also as a teamworker, who sometimes is forced to make compromises in order to achieve company’s goals.
Simultaneously, it also allowed us to see how they use tools, but first of all – how they can use SOLID principles in practice etc. But what with the other 30%? In fact these were people who can’t program in pairs at all. It was totally unnatural for them. Is it a big problem? When you realize that in practice you spent 5-10% of the time on pair programming you have to think through if you can live with such employees at the position you are filling 🙂
How can we check their coding skills? Just let them continue the task we’ve started. But alone. Without interviewers watching over their shoulder and commenting every single line of a code.
What is also important we should recreate natural conditions for every developer – favorite IDE installed, access to StackOverflow.com, documentation etc. If candidate asks about using his own notebook – the answer always should be: “Feel free. Do everything you need to feel comfortable in coding”. Natural enviroment is an absolut must have for all kind of tests verifing coding skills as well in pair programing as in individual interviews.