Après avoir publié un article sur les principales erreurs à ne pas commettre lors de l'embauche de programmeurs, nous avons reçu quelques questions concernant les tâches de programmation et la manière dont nous devrions vérifier les compétences en matière de codage.
Mon expérience professionnelle à long terme 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 entreprises 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.
Difficultés liées aux entretiens avec les développeurs
Lorsque j'ai commencé à interviewer des développeurs, nous n'avions pas le temps de faire de la programmation active et des tests de codage. Comme nous avions beaucoup de candidats, nous devions nous en tenir à une limite d'une heure pour chaque question - évaluation technique et psychologique, ainsi que négociations financières. Finalement, nous avons embauché environ 5% de candidats initiaux. Après la période d'essai, environ 90% d'entre eux ont continué à travailler. Il s'agit d'un très bon taux de conversion.
Tout à fait...
Mais après avoir calculé les coûts engendrés par des décisions d'embauche inappropriées, nous avons réalisé que nous gaspillions beaucoup d'argent. Salaire, RH, bureau, ordinateurs portables, temps de travail des développeurs seniors pour le démarrage, etc. Les dépenses qui s'ajoutent au salaire doublent en moyenne le coût final.
Les trois principales raisons pour lesquelles les développeurs n'ont pas été embauchés après la période d'essai sont les suivantes :
- ils n'ont pas pu travailler au sein de l'équipe,
- ils n'avaient que des connaissances théoriques,
- ils travaillaient beaucoup plus lentement que prévu.
La raison pour laquelle nous n'avons pas été en mesure de découvrir tous ces inconvénients est l'omission des tests de codage actif au cours de l'entretien. Embaucher des développeurs de logiciels sans vérifier s'ils sont réellement capables de coder rapidement et intelligemment revient à acheter une voiture sans vérifier si le moteur fonctionne.
Comment pouvons-nous donc 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 cela, nous avons été contraints de limiter le nombre de candidats dans un premier temps. Nous avons décidé de faire une sélection téléphonique de 15 minutes en posant 10 à 15 questions techniques et en cherchant à connaître leurs attentes en matière de salaire. C'est sur cette base que nous réinvitons ou non le candidat. Le processus de présélection 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 allonger 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, nous mettons l'accent sur la façon dont les programmeurs pensent, notamment en ce qui concerne 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 la bonne pour environ 70% de nos candidats. Par conséquent, une séance de codage d'une heure a suffi pour voir comment une personne se comporterait dans notre environnement exigeant et spécifique - à la fois en mettant en pratique les connaissances acquises, en utilisant la capacité de traitement rapide de l'information, la flexibilité et aussi en tant que travailleur d'équipe, qui est parfois contraint de faire des compromis pour 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 SOLID dans la pratique, etc. Mais qu'en est-il des autres 30% ? En fait, il s'agissait de personnes qui ne pouvaient pas du tout programmer par paires. Ce n'était pas du tout naturel pour eux. Est-ce un gros problème ? Quand vous réalisez qu'en pratique vous avez passé 5-10% du temps sur la programmation en binôme, vous devez vous demander 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 ? Il suffit de les laisser poursuivre la tâche que nous avons commencée. Mais seuls. Sans que les enquêteurs ne surveillent leur épaule et ne commentent chaque ligne du code.
Il est également important de recréer des conditions naturelles pour chaque développeur - son IDE préféré installé, l'accès à StackOverflow.com, la documentation, etc. Si un candidat demande à utiliser son propre carnet de notes, la réponse devrait toujours être : "N'hésitez pas. Faites tout ce dont vous avez besoin pour vous sentir à l'aise dans le codage". Un environnement naturel est absolument indispensable pour tous les types de tests visant à vérifier les compétences en matière de codage, que ce soit dans le cadre d'un programme en binôme ou d'un entretien individuel.
