Des tests de codage en milieu naturel [étude de cas] : un succès retentissant

Par 26 août 2015 #!31lun, 18 Mai 2020 05:15:13 +0200p1331#31lun, 18 Mai 2020 05:15:13 +0200p-5Europe/Warsaw3131Europe/Warsawx31 18 31 -31lun, 18 Mai 2020 05:15:13 +0200p5Europe/Warsaw3131Europe/Warsawx312020lun, 18 Mai 2020 05:15:13 +0200155155 lundi=254#!31lun, 18 Mai 2020 05:15:13 +0200pEurope/Warsaw5#mai 18th, 2020#!31lun, 18 Mai 2020 05:15:13 +0200p1331#/31lun, 18 Mai 2020 05:15:13 +0200p-5Europe/Warsaw3131Europe/Warsawx31#!31lun, 18 Mai 2020 05:15:13 +0200pEurope/Warsaw5# Test de codage, Entretien technique

After publishing a post concerning most common don’ts of hiring programmers we received some questions regarding programming tasks and the way we should verify coding compétences.

From my long-term work experience I’ve got a lot of consulting practice on recrutement process of programmers in some of the biggest IT companies based mostly in central-eastern Europe.

Nous avons beaucoup écrit sur les entretiens techniques. Consultez Le guide ultime de l'entretien technique.

Les défis des entretiens avec les développeurs

When I started interviewing developers there was no time for active programming and tests de codage. 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.

Tout à fait...

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:

  1. ils n'ont pas pu travailler dans l'équipe,
  2. ils n'avaient que des connaissances théoriques,
  3. ils travaillaient beaucoup plus lentement que prévu.

La raison pour laquelle nous n'avons pas pu découvrir tous ces inconvénients est que nous avons sauté les tests de codage actifs pendant l'interview. Engager des développeurs de logiciels sans vérifier s'ils peuvent vraiment coder rapidement et intelligemment est similaire à acheter une voiture sans vérifier si le moteur fonctionne.

Alors comment pouvons-nous vérifier toutes ces faiblesses en seulement 60 minutes ?

La réponse est la suivante 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.

Nous avons essayé de trouver une solution pour vérifier si chaque candidat est sur la même longueur d'onde que l'équipe et s'il peut utiliser les langages de programmation que nous utilisons habituellement au quotidien. Indépendamment des compétences requises en matière de codage dans le travail des programmeurs, nous mettons l'accent sur leur façon de penser, en particulier parce que cela affecte leur capacité à communiquer avec les autres.

La programmation en binôme est-elle une solution ?

L'idée était de faire une programmation en binôme ! Cool - on aura le meilleur des deux mondes. L'hypothèse était juste pour environ 70% de nos candidats. En conséquence, une heure de session de codage a suffi pour voir comment quelqu'un va agir dans notre environnement exigeant et spécifique - à la fois en utilisant les connaissances possédées en pratique, en utilisant la capacité d'information rapide traitementElle est aussi un travailleur d'équipe, qui est parfois obligé de faire des compromis pour atteindre les objectifs de l'entreprise.

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 programme 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 employés  at the position you are filling 🙂

Comment pouvons-nous vérifier leurs compétences en matière de codage ? Laissez-les simplement poursuivre la tâche que nous avons commencée. Mais seuls. Sans que les enquêteurs ne surveillent par-dessus leur épaule et ne commentent chaque ligne d'un code.

Il est également important de recréer les conditions naturelles pour chaque développeur - IDE favori installé, accès à StackOverflow.com, documentation, etc. Si le candidat pose des questions sur l'utilisation de son propre ordinateur portable, la réponse devrait toujours être "oui" : "N'hésitez pas. Faites tout ce qu'il faut pour vous sentir à l'aise dans le codage". L'environnement naturel est un élément indispensable pour tous les types de tests destinés à vérifier les compétences en matière de codage, tant pour la programmation en binôme que pour les entretiens individuels.