Hiring process part 3 · interview

Arseni Mourzenko
Founder and lead developer
161
articles
November 6, 2014
Tags: hiring 14

The can­di­date is in the hall, wait­ing for the in­ter­view. What should be your next steps? How to guide the can­di­date through the process of the in­ter­view?

The most valu­able ad­vice: keep hu­man re­sources away

Prob­a­bly the worst thing a com­pa­ny can do is to have a per­son from hu­man re­sources in charge of the be­gin­ning of the in­ter­view.

This is the cru­cial mis­take Azeo does. When I ar­rived, I found my­self in a room with a woman from hu­man re­sources who start­ed to show a pow­er-point pre­sen­ta­tion she sent me a few days be­fore the in­ter­view. This not very pro­fes­sion­al pre­sen­ta­tion (with a lot of mis­takes, by the way) ex­plains the ba­sic or­ga­ni­za­tion of Azeo and shows a list of their top cus­tomers and how Azeo helped them. This may be in­ter­est­ing for mar­ket­ing peo­ple (if done a bit bet­ter), but for a de­vel­op­er, this stuff is just too bor­ing.

Now, I find my­self sit­ting in this room af­ter a prac­ti­cal­ly sleep­less night, with this woman read­ing the slides I al­ready know quite well, be­cause I've stud­ied them. Fif­teen more slides. Ten more. My eyes are clos­ing...

I don't know how I avoid­ed falling asleep. I don't know why are they mak­ing their can­di­dates suf­fer this way. All I want­ed to know is the in­ter­est­ing stuff: are they us­ing the lat­est ver­sion of Vi­su­al Stu­dio, do they have dual-screen con­fig­u­ra­tion, what is the ex­am­ple of the most tech­ni­cal­ly chal­leng­ing prod­uct they had done, etc. But I was young, and I lis­tened with­out in­ter­rupt­ing.

If I was do­ing the same in­ter­view to­day, I would have asked ques­tions. Many ques­tions. Un­til the woman cracks and calls an ac­tu­al per­son who is able to an­swer whether they are us­ing Code con­tracts, do they en­cour­age their de­vel­op­ers to use func­tion­al as­pects in C# and how QA is or­ga­nized there.

In all cas­es, keep peo­ple from hu­man re­sources away from can­di­dates. Dur­ing the in­ter­view, they talk about un­in­ter­est­ing stuff and they can't an­swer any ques­tion that mat­ters.

The sec­ond most valu­able ad­vice: this is not an in­ter­view

So there is a can­di­date, in front of a group of peo­ple who ask him to pre­sent him­self and then ask him ques­tions. This is a good way to hire—I don't know—po­lice­men, or maybe sci­en­tists. De­vel­op­ers, on the oth­er hand, are not fond of such for­mal­ism. They are not fond of in­ter­views ei­ther, so don't make it an in­ter­view.

Make it a dis­cus­sion. Two peo­ple met to­geth­er to dis­cuss an op­por­tu­ni­ty for one to bring his skills and for oth­er to bring an en­vi­ron­ment where those skills can flor­ish. That's right, it's not skills vs. mon­ey, but skills vs. en­vi­ron­ment.

Many de­vel­op­ers don't care about mon­ey. This doesn't mean that you can pay them $600 per month and ex­pect them to work 50 hours a week—you ob­vi­ous­ly should pay them (and of­ten a lot), but don't con­sid­er this as the only thing you have to of­fer to a de­vel­op­er. Be­cause if this is the only thing, you won't get any tal­ent­ed per­son. No one. Nev­er.

A man­u­al work­er doesn't have to en­joy his job, and usu­al­ly, he doesn't. He works for mon­ey. De­vel­op­ers, as well as any oth­er artist, love their job. Un­less you achieve to kill any mo­ti­va­tion in your de­vel­op­ers, they are usu­al­ly en­joy­ing to go to their work­place. They may even for­get to go to lunch, or may for­get that it's 2 AM and their wife ex­pect­ed them to be at home four hours ago.

What do de­vel­op­ers look for? Most­ly an op­por­tu­ni­ty to do their job right, do it well, know that some­body uses the prod­uct they worked on and be able to solve chal­lenges, learn new things and grow.

This is why the only thing you can give them is your mon­ey, they won't be par­tic­u­lar­ly ex­cit­ed about the job. And tal­ent­ed peo­ple are usu­al­ly ac­cept­ing the job they are ex­cit­ed about.

So no, it is not an in­ter­view. An in­ter­view means that you're the boss and you're ready to throw some mon­ey if the per­son is able to work ac­cord­ing to your ex­pec­ta­tions. This is the wrong spir­it. The right spir­it is two guys talk­ing about a busi­ness op­por­tu­ni­ty which makes them both hap­py. There are no boss­es or sub­or­di­nates here, but rather busi­ness part­ners.

Tal­entSoft did ex­act­ly that. They nev­er men­tioned the word "in­ter­view". In­stead, they in­vit­ed me to talk with their R&D man­ag­er. And we talked, and this was a very in­ter­est­ing talk with a very in­ter­est­ing per­son. We talked about all sort of sub­jects: Agili­ty, Con­tin­u­ous In­te­gra­tion, tech­ni­cal debt, test­ing, and while all this was re­lat­ed to the po­si­tion, it was still a talk, not an in­ter­view.

I spent five hours at Tal­entSoft, Paris. There was the ini­tial talk, then a test, then a se­ries of ques­tions from oth­er de­vel­op­ers (de­vel­op­ers like me but, well, much more skill­ful then I am).

The in­ter­view at Irec, Poitiers, was less then an hour. No tech­ni­cal ques­tions what­so­ev­er. No tests. No oth­er de­vel­op­ers.

While the length of the in­ter­view doesn't mat­ter much, you shouldn't ex­pect an in­ter­view to be short­er than an hour. You should re­serve enough time for:

You can have ad­di­tion­al steps, but you can't re­move them. If you don't have a gen­er­al dis­cus­sion, you know noth­ing about the per­son you're about to hire. If you don't ask the per­son to write code dur­ing the in­ter­view, you can't be sure the per­son is able to write code. If you don't ask tech­ni­cal ques­tions, you have no clue about the ac­tu­al skills of the per­son.

That's what dif­fer­en­ti­ates Tal­entSoft from Irec. Tal­entSoft wants to hire peo­ple who know the stuff: pro­gram­mers who are able to write code, DBAs who know how data­bas­es work and how to ad­min­is­ter them, sys­tem ad­min­is­tra­tors who are able to set up a DNS ser­vice and know what makes a DNS ser­vice re­dun­dant or not. So Tal­entSoft is pow­ered by tal­ent­ed peo­ple, while Irec has peo­ple who know noth­ing about pro­gram­ming nor de­vel­op­ment nor data­bas­es nor man­age­ment nor sys­tem ad­min­is­tra­tion.

While hav­ing those three steps is manda­to­ry, the way to han­dle those steps may vary a lot. For ex­am­ple, tech­ni­cal ques­tions may be asked by one per­son, but they also can be asked by many per­sons. There may be mul­ti­ple in­ter­views done by sev­er­al per­sons from the com­pa­ny. There may be a talk with the boss. There may be an in­for­mal dis­cus­sion with the team the can­di­date will be part of if he's hired.

Each tech­nique has its ben­e­fits and draw­backs. For ex­am­ple, a dis­cus­sion with all team mem­bers is a good op­por­tu­ni­ty for some can­di­dates to show that they can in­te­grate well with­in this team, but there is also a risk of fright­en­ing a shy can­di­date.

The tech­nique I love par­tic­u­lar­ly is to ask the per­son be­fore the in­ter­view to send me a piece of source code he has writ­ten. There is much to tell from source code, and the ex­changes dur­ing the in­ter­view are usu­al­ly in­ter­est­ing. Ask­ing why the per­son did some­thing this way in­stead of that one can bring a dif­fer­ent view of the sub­ject.

There is so much to tell about the flow of the in­ter­view that I sim­ply can't do it in a sim­ple ar­ti­cle. In­stead, I want to come back to the ques­tion of the length of the in­ter­view, and specif­i­cal­ly an­swer the ques­tion peo­ple ask me fre­quent­ly: how long is too long?

I'm con­vinced that six-sev­en hours in­ter­views are not too long and that more in­ter­views should take the whole day. Re­mem­ber, hir­ing a per­son who shouldn't be hired is very prob­lem­at­ic, but not hir­ing a tal­ent­ed per­son is even worse. I would pre­fer spend­ing the whole day and know that I gath­ered enough in­for­ma­tion to take a wise choice than spend­ing three hours and find lat­er that I missed the op­por­tu­ni­ty to hire a per­son just be­cause we ran out of time be­fore he could pre­sent the great thing which would be de­ci­sive for me.