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

Publié : Dernière mise à jour :

Après avoir publié un article sur les erreurs les plus courantes lors du recrutement de programmeurs, nous avons reçu des questions concernant les tâches de programmation et la manière dont nous devons vérifier les compétences de codage.

Ma longue expérience professionnelle m'a permis d'acquérir une grande expérience en matière de conseil sur le processus de recrutement de programmeurs dans certaines des plus grandes sociétés informatiques basées principalement en Europe centrale et orientale.

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

Lorsque j'ai commencé à interviewer des développeurs, il n'y avait pas de temps pour la programmation active et les tests de codage. Comme nous avions beaucoup de candidats, nous devions nous en tenir à une limite d'une heure pour chaque question, qu'il s'agisse d'une évaluation technique ou non, ou encore de négociations financières. Finalement, nous avons embauché environ 5% des candidats initiaux. Après la période d'essai, environ 90% d'entre eux ont continué à travailler. C'était un assez bon taux de conversion.

Tout à fait...

Mais après avoir calculé les coûts causés par des décisions d'embauche inappropriées, nous avons réalisé que nous gaspillions beaucoup d'argent. Salaire, RH, bureau, carnets de notes, temps de démarrage des développeurs seniors, etc. Les dépenses supplémentaires aux salaires ont en moyenne presque doublé le coût final.

Trois raisons principales expliquent pourquoi les développeurs n'ont pas été engagés après la période d'essai :

  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 simple : nous ne pouvions pas ! Nous avons dû prolonger le processus d'entretien d'au moins deux heures. Mais avant de faire cela, nous avons été contraints de limiter le nombre de candidats dans un premier temps. Nous avons décidé de procéder à une présélection téléphonique de 15 minutes en posant 10 à 15 questions techniques et en nous renseignant sur leurs attentes salariales. Sur cette base, nous invitons à nouveau le candidat ou non. Le processus de filtrage nous a permis de réduire le nombre de réunions nécessaires de près de 40%, ce qui est un résultat moins bon que prévu, mais suffisant pour prolonger la durée de chaque entretien.

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 de la programmation en binôme ! Cool - nous aurons le meilleur des deux mondes. L'hypothèse était juste pour environ 70% de nos candidats. En conséquence, une session de codage d'une heure était suffisante pour voir comment une personne se comportera dans notre environnement exigeant et spécifique - à la fois en utilisant les connaissances acquises dans la pratique, en utilisant la capacité de traitement rapide de l'information, la flexibilité et aussi en tant que travailleur d'équipe, qui est parfois obligé de faire des compromis afin d'atteindre les objectifs de l'entreprise.

Simultanément, cela nous a également permis de voir comment ils utilisent les outils, mais avant tout - comment ils peuvent utiliser les principes SOLIDES dans la pratique, etc. Mais qu'en est-il des autres 30% ? En fait, il s'agissait de personnes qui ne peuvent pas du tout programmer à deux. C'était totalement contre nature pour eux. Est-ce un gros problème ? Lorsque vous réalisez qu'en pratique vous avez passé 5-10% du temps sur la programmation par paires, vous devez réfléchir si vous pouvez vivre avec de tels employés au poste que vous occupez 🙂

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.

Partager le poste

En savoir plus sur le recrutement dans le secteur des technologies

Abonnez-vous à notre Learning Hub pour recevoir des informations utiles directement dans votre boîte aux lettres électronique.

Vérifier et développer les compétences de codage de manière transparente.

Voir les produits DevSkiller en action.

Certifications de sécurité et conformité. Nous veillons à ce que vos données soient sûres et sécurisées.

Logo DevSkiller Logo TalentBoost Logo TalentScore