Les entretiens techniques ne seraient pas aussi efficaces que jouer à Factorio avec quelqu'un.

Un développeur estime que le jeu d'automatisation apporte des métriques beaucoup plus intéressantes

Erik McClure : « l'entretien de programmation le plus efficace que nous ayons actuellement est généralement une sorte de projet à emporter, où un candidat est invité à corriger un bogue ou à implémenter une petite fonctionnalité en quelques jours. Ce n'est pas génial, car cela prend beaucoup de temps et ils pourraient recevoir une aide extérieure (ou, si la fonctionnalité est suffisamment courante, la rechercher sur Google). D'un autre côté, certaines grandes entreprises ont plutôt doublé les entretiens de style tableau blanc en soumettant les ingénieurs potentiels à plusieurs évaluations de codage en ligne d'une heure, avec différents niveaux de surveillance invasive. Toutes ces méthodes d'interview font pâle figure face à une métrique très simple : jouer à Factorio avec quelqu'un ».

Pour le développeur Jon Evans, l'entretien technique en entreprise est tout bonnement ridicule. Sa réussite tient plus à la chance qu'aux compétences réelles du développeur. Pour lui, beaucoup de bons développeurs ont été injustement mis à l'écart à cause de cette pratique. Selon lui, la façon ultime d'embaucher la bonne personne est avant tout de juger ses capacités par quelque chose qu'il a déjà produit. Les projets réalisés par le candidat sont dans ce cas d'une très grande aide. L’entretien doit être un moment d’échange avec le candidat, au lieu de poser les questions techniques, le recruteur devrait essayer de savoir les outils déjà utilisés par celui-ci, les décisions qui l’ont poussé vers ceux-ci, les problèmes techniques déjà rencontrés et comment ils ont été résolus, etc.

Dans un billet, l’ingénieur Thomas Ptacek a estimé que « l’entretien de l’ingénieur logiciel ne marche pas. Les entreprises devraient cesser de s’y fier. Les équipes avisées vont supplanter leurs pairs en concevant des programmes alternatifs d’embauche. Dans des années, nous verrons l’entrevue du développeur en 2015 comme un anachronisme qui s’apparente à embaucher un violoncelliste d’orchestre avec un test de personnalité et un questionnaire sur sa théorie de la musique plutôt qu’une audition en aveugle ».

S'il fallait profiter des alternatives aux tests techniques qui seraient à la fois profitables au candidat, mais également à l’entreprise, Laszlo Bock, qui était alors le Vice-Président aux ressources humaines chez Google, indique : « au lieu de cela, ce qui pourrait bien fonctionner ce sont des entretiens comportementaux structurés où vous avez une rubrique cohérente pour la façon dont vous évaluez les candidats (…) les entretiens comportementaux peuvent également marcher – où vous ne posez pas une question hypothétique, mais vous commencez avec une question du genre ‘donnez-moi un exemple d’une fois où vous avez du résoudre un problème analytique difficile’. L’une des choses les plus intéressantes avec l’entretien comportemental est que lorsque vous demandez à quelqu’un de parler de sa propre expérience et vous creusez dans ce sens, vous obtenez deux genres d’informations. L’une qui vous permet de voir comment le candidat réagit en situation réelle et l’information précieuse ‘meta’ que vous obtenez est de prendre connaissance de ce que le candidat considère comme difficile ».


Factorio, une alternative intéressante aux tests techniques ?

Dans un billet de blog, le développeur Erik McClure explique :

« L'entretien de programmation le plus efficace que nous ayons actuellement est généralement une sorte de projet à emporter, où un candidat est invité à corriger un bogue ou à implémenter une petite fonctionnalité en quelques jours. Ce n'est pas génial, car cela prend beaucoup de temps et ils pourraient recevoir une aide extérieure (ou, si la fonctionnalité est suffisamment courante, la rechercher sur Google). D'un autre côté, certaines grandes entreprises ont plutôt doublé les entretiens de style tableau blanc en soumettant les ingénieurs potentiels à plusieurs évaluations de codage en ligne d'une heure, avec différents niveaux de surveillance invasive.

« Toutes ces méthodes d'interview font pâle figure face à une métrique très simple : jouer à Factorio avec quelqu'un. Passer en revue toute une série de Factorio est presque la meilleure indication possible de la façon dont quelqu'un gère les problèmes techniques courants. Vous pouvez même modifier le jeu en fonction de l'ancienneté du poste pour lequel vous embauchez pour avoir une meilleure idée de la façon dont ils évolueront dans ce rôle ».

Factorio est un jeu qui parle d'automatisation. La meilleure introduction est probablement cette bande-annonce, mais votre travail consiste essentiellement à construire une usine automatisée capable de lancer une fusée dans l'espace :


Auto-direction

Le jeu commence sans but et pratiquement dans aucune direction. Pour Erik, un développeur senior doit être en mesure d'explorer l'interface utilisateur et de déterminer un objectif, puis d'établir un plan pour atteindre cet objectif. Un développeur junior doit être en mesure d'exécuter une tâche qu'un développeur senior lui a confiée. On s'attend à ce qu'un stagiaire ait besoin d'un peu de mentorat, mais un développeur junior devrait être en mesure de résoudre les problèmes de base avec son propre code avant de demander l'aide du développeur principal. Un développeur intermédiaire doit être capable de fonctionner de manière indépendante une fois qu'une tâche est confiée, mais il n'est pas censé faire de conception d'architecture.

Plus concrètement, Erik estime que vous pouvez vous attendre à ce qui suit:

• On s'attend généralement à ce qu'un stagiaire soit capable de remplir un plan préplacé et d'utiliser des ceintures pour connecter son plan à autre chose, comme un patch de minerai.
• Un développeur junior devrait être capable de construire une ligne de production par lui-même, même si ce ne sera probablement pas très optimal. Il peut avoir besoin de l'aide du développeur principal pour savoir comment acheminer correctement les courroies vers toutes les machines d'assemblage intermédiaires.
• Un développeur intermédiaire doit être capable de concevoir une ligne de production quasi optimale (sans balises) une fois la direction donnée, avec un minimum de supervision.
• Le développeur senior n'a pas besoin de direction et est capable de déterminer les objectifs à atteindre et de concevoir un plan d'action, puis de déléguer ces tâches à d'autres développeurs.

Travail d'équipe

Un aspect critique du développement logiciel est la capacité de travailler en équipe. Cela signifie coordonner vos efforts avec d'autres personnes, prendre en compte les besoins des conceptions des autres et coopérer avec l'équipe, au lieu de simplement refuser d'ajuster votre conception pour qu’elle puisse s'intégrer au travail de quelqu'un d'autre. Erik note que cela se produit tout le temps dans Factorio, car les conceptions de mise en page de base sont limitées par l'espace physique. En conséquence, vous devez examiner attentivement ce que font les autres et parfois ajuster votre conception pour vous adapter aux contraintes de taille ou gérer la conception de quelqu'un d'autre qui a pris plus de place que prévu.

« Quiconque commence à faire les choses lui-même ou à résoudre des problèmes sans le dire aux gens va rapidement provoquer la colère de ses collègues joueurs, pour les mêmes raisons que les programmeurs cow-boys. Heureusement, Factorio inclut un équivalent intégré à git blame, en vous montrant le dernier joueur qui a modifié une entité. Ainsi, lorsque les gens proposent des solutions temporaires et n'informent pas l'équipe du problème qu'ils résolvaient, si leur solution temporaire venait à planter, les gens sauraient qui en est le responsable. Si les gens veulent gagner leur match, ils devront apprendre à bien coopérer avec leurs coéquipiers ».

Débogage

L'une des compétences les plus importantes pour tout développeur est sa capacité à déboguer les problèmes. Erick pense qu’il s’agit là peut-être du parallèle le plus évident entre Factorio et l'ingénierie logicielle réelle. Quelque chose peut mal tourner très loin de la source réelle du problème. Être capable de se concentrer rapidement sur le problème réel est une compétence essentielle, et le processus de réflexion est presque identique à la recherche de la cause d'un plantage dans un programme réel. Si une machine d'assemblage a cessé de fonctionner, vous devez d'abord voir s'il y a plusieurs sorties qui ont été sauvegardées. Ensuite, vous devez vérifier quel ingrédient il manque. Ensuite, vous devez retracer l'ingrédient dans votre usine pour savoir où vous le fabriquez et répéter l’opération autant de fois que nécessaire.

« Le débogage de Factorio se complique assez rapidement. Dès que vous commencez à travailler sur le traitement de l'huile, vous devrez faire face au craquage [ndlr. Procédé de raffinage du pétrole], où vous avez affaire à trois sorties différentes et si l'une d'entre elles est sauvegardée pour une raison quelconque, tout s'arrête. Il y a des cas où toute votre usine peut s'arrêter parce que vous avez commencé à rechercher quelque chose qui ne nécessite pas de science jaune, qui a cessé d'utiliser des robot frames, qui a cessé d'utiliser des moteurs électriques, qui a cessé d'utiliser du lubrifiant, qui a cessé de consommer de l'huile lourde, qui a sauvegardé et arrêté la production de pétrole, qui vous a fait manquer de pétrole, qui a provoqué le plantage des circuits rouges, qui a provoqué le plantage du reste de l'usine. Les joueurs chevronnés anticiperont des scénarios comme celui-ci et utiliseront des circuits pour faire un craquage d'huile autoéquilibré afin de s'assurer que le système est équilibré. Un nouveau joueur qui est un bon développeur, quand on lui présente une usine qui s'est effondrée, sera généralement en mesure de retracer le problème à la source, de réaliser ce qui s'est passé et d'essayer rapidement de trouver une solution. D'un autre côté, si quelqu'un fait simplement tomber quelques réservoirs de stockage, à moins qu'il ne puisse fournir une bonne raison, alors c'est un drapeau rouge pour la façon dont ils abordent la résolution de problèmes dans leurs programmes.

« Des situations comme celles-ci permettent à Factorio d'imiter étroitement les interdépendances complexes avec lesquelles les développeurs traitent régulièrement, et la complexité augmente simplement avec l'ajout de concepts de gameplay. Cela suit de près la complexité accrue que des couches d'abstraction supplémentaires introduisent lors de la tentative de débogage d'un plantage qui aurait pu se produire au plus profond de l'un des frameworks que vous utilisez ».

Revues de code

Souvent, les conceptions initiales doivent être modifiées pour les performances ou le débit. Les bons développeurs accepteront non seulement la critique de leurs conceptions, mais incorporeront ces commentaires dans leur travail futur. S'ils ne sont pas d'accord avec un changement proposé, ils fourniront une raison concrète pour expliquer pourquoi ils ne sont pas d'accord afin que l'équipe puisse peser plus précisément les avantages et les inconvénients du changement proposé.

Résister aux commentaires sans fournir de bonnes raisons est un drapeau rouge bien connu, mais ce qui peut également être problématique, c'est un développeur qui accepte à contrecœur les modifications proposées, mais refuse d'ajuster les conceptions futures en conséquence. Ils finissent par exiger des rappels constants pour adhérer à une manière standard de résoudre un problème sans donner aucune raison pour laquelle ils ne semblent pas aimer la façon dont l'équipe fait les choses. Ceux-ci peuvent être des bombes à retardement dans les organisations, car lorsqu'ils ne sont pas supervisés, ils peuvent rapidement accumuler des dettes techniques pour les autres membres de l'équipe. Ce genre de problème est quasiment impossible à déceler dans un entretien traditionnel, à moins qu'il ne s'agisse d'un stage.

Conclusion

Dans son billet, Erik McClure aborde encore d'autres thématiques comme le style de codage et les frameworks, le multithreading, l'évolutivité, les microservices et les architectures de plugin ou encore les systèmes distribués. Il conclut son exposé en ces termes :

« Collectivement, l'industrie du logiciel n'a tout simplement aucune idée de la façon d'embaucher des développeurs de logiciels. Factorio est probablement la meilleure interview technique que nous ayons en ce moment, et c'est embarrassant. Elle est également extrêmement peu pratique, prenant plus de 20 heures dans une première partie multijoueur, ou 8 heures si vous avez beaucoup de monde et que vous savez ce que vous faites. Quelle est la chose à retenir ? Je ne sais pas. Nous ne pouvons certainement pas passer à l'utilisation de Factorio comme méthode d'entrevue – vous pouvez tout aussi bien confier à un candidat une mission à emporter.

« Mais au moins, nous pouvons faire mieux que les entretiens sur tableau blanc ».

Source : billet Erik McClure

Et vous ?

Êtes-vous pour ou contre les entretiens techniques ? Pour quelles raisons ?
Si vous êtes contre, pouvez-vous proposer un processus de sélection alternatif qui serait plus productif selon vous ?
Que pensez-vous de la proposition de Factorio comme alternative au processus de sélection traditionnel ?
Estimez-vous avoir déjà été injustement mis à l'écart avec le processus d'embauche traditionnel ?

Voir aussi :

Sondage : quelles sont les pires erreurs à éviter dans le cadre d'un entretien d'embauche dans la filière informatique ? Partagez vos avis
Les entretiens d'embauche dans le secteur des technologies évaluent l'anxiété et non les compétences en développement de logiciels, d'après une étude de l'université de Caroline du Nord et Microsoft