Home Home

Hiring process part 3 · interview

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
September 19, 2014
Tags hiring 14

The candidate is in the hall, waiting for the interview. What should be your next steps? How to guide the candidate through the process of the interview?

The most valuable advice: keep human resources away

Probably the worst thing a company can do is to have a person from human resources in charge of the beginning of the interview.

This is the crucial mistake Azeo does. When I arrived, I found myself in a room with a woman from human resources who started to show a power-point presentation she sent me a few days before the interview. This not very professional presentation (with a lot of mistakes, by the way) explains the basic organization of Azeo and shows a list of their top customers and how Azeo helped them. This may be interesting for marketing people (if done a bit better), but for a developer, this stuff is just too boring.

Now, I find myself sitting in this room after a practically sleepless night, with this woman reading the slides I already know quite well, because I've studied them. Fifteen more slides. Ten more. My eyes are closing...

I don't know how I avoided falling asleep. I don't know why are they making their candidates suffer this way. All I wanted to know is the interesting stuff: are they using the latest version of Visual Studio, do they have dual-screen configuration, what is the example of the most technically challenging product they had done, etc. But I was young, and I listened without interrupting.

If I was doing the same interview today, I would have asked questions. Many questions. Until the woman cracks and calls an actual person who is able to answer whether they are using Code contracts, do they encourage their developers to use functional aspects in C# and how QA is organized there.

In all cases, keep people from human resources away from candidates. During the interview, they talk about uninteresting stuff and they can't answer any question that matters.

The second most valuable advice: this is not an interview

So there is a candidate, in front of a group of people who ask him to present himself and then ask him questions. This is a good way to hire—I don't know—policemen, or maybe scientists. Developers, on the other hand, are not fond of such formalism. They are not fond of interviews either, so don't make it an interview.

Make it a discussion. Two people met together to discuss an opportunity for one to bring his skills and for other to bring an environment where those skills can florish. That's right, it's not skills vs. money, but skills vs. environment.

Many developers don't care about money. This doesn't mean that you can pay them $600 per month and expect them to work 50 hours a week—you obviously should pay them (and often a lot), but don't consider this as the only thing you have to offer to a developer. Because if this is the only thing, you won't get any talented person. No one. Never.

A manual worker doesn't have to enjoy his job, and usually, he doesn't. He works for money. Developers, as well as any other artist, love their job. Unless you achieve to kill any motivation in your developers, they are usually enjoying to go to their workplace. They may even forget to go to lunch, or may forget that it's 2 AM and their wife expected them to be at home four hours ago.

What do developers look for? Mostly an opportunity to do their job right, do it well, know that somebody uses the product they worked on and be able to solve challenges, learn new things and grow.

This is why the only thing you can give them is your money, they won't be particularly excited about the job. And talented people are usually accepting the job they are excited about.

So no, it is not an interview. An interview means that you're the boss and you're ready to throw some money if the person is able to work according to your expectations. This is the wrong spirit. The right spirit is two guys talking about a business opportunity which makes them both happy. There are no bosses or subordinates here, but rather business partners.

TalentSoft did exactly that. They never mentioned the word "interview". Instead, they invited me to talk with their R&D manager. And we talked, and this was a very interesting talk with a very interesting person. We talked about all sort of subjects: Agility, Continuous Integration, technical debt, testing, and while all this was related to the position, it was still a talk, not an interview.

I spent five hours at TalentSoft, Paris. There was the initial talk, then a test, then a series of questions from other developers (developers like me but, well, much more skillful then I am).

The interview at Irec, Poitiers, was less then an hour. No technical questions whatsoever. No tests. No other developers.

While the length of the interview doesn't matter much, you shouldn't expect an interview to be shorter than an hour. You should reserve enough time for:

  • The general discussion with the candidate,
  • A whiteboard test,
  • Technical questions.

You can have additional steps, but you can't remove them. If you don't have a general discussion, you know nothing about the person you're about to hire. If you don't ask the person to write code during the interview, you can't be sure the person is able to write code. If you don't ask technical questions, you have no clue about the actual skills of the person.

That's what differentiates TalentSoft from Irec. TalentSoft wants to hire people who know the stuff: programmers who are able to write code, DBAs who know how databases work and how to administer them, system administrators who are able to set up a DNS service and know what makes a DNS service redundant or not. So TalentSoft is powered by talented people, while Irec has people who know nothing about programming nor development nor databases nor management nor system administration.

While having those three steps is mandatory, the way to handle those steps may vary a lot. For example, technical questions may be asked by one person, but they also can be asked by many persons. There may be multiple interviews done by several persons from the company. There may be a talk with the boss. There may be an informal discussion with the team the candidate will be part of if he's hired.

Each technique has its benefits and drawbacks. For example, a discussion with all team members is a good opportunity for some candidates to show that they can integrate well within this team, but there is also a risk of frightening a shy candidate.

The technique I love particularly is to ask the person before the interview to send me a piece of source code he has written. There is much to tell from source code, and the exchanges during the interview are usually interesting. Asking why the person did something this way instead of that one can bring a different view of the subject.

There is so much to tell about the flow of the interview that I simply can't do it in a simple article. Instead, I want to come back to the question of the length of the interview, and specifically answer the question people ask me frequently: how long is too long?

I'm convinced that six-seven hours interviews are not too long and that more interviews should take the whole day. Remember, hiring a person who shouldn't be hired is very problematic, but not hiring a talented person is even worse. I would prefer spending the whole day and know that I gathered enough information to take a wise choice than spending three hours and find later that I missed the opportunity to hire a person just because we ran out of time before he could present the great thing which would be decisive for me.