
Un développeur estime que le jeu qui parle 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[/ndlr. procédé de raffinage du pétrole]...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.