IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Stéphane le calme

294PARTAGES

19  1 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de pmithrandir
Expert éminent https://www.developpez.com
Le 30/03/2021 à 22:36
Ca heurte la conception carthésienne de beaucoup de dev, mais quand on recrute il n y a pas de bon moyen qui vont eviter tous les problèmes.
C'est un problème sans solution.

Le mieux que j'ai trouvé, c'est encore la discussion bienveillante avec la personne qui sert de base pour savoir ce qu'il a fait.
Ensuite on lui demande d'expliquer les sujets sur lesquels il a travaillé qui nous paraisse pertinent, en évaluant sa capacité a expliquer ce qu'il a fait.

une personne qui ne sait pas de quoi elle parle, ca se repère vite.
Des dev peuvent également, toujours avec bienveillance, creuser ces sujets en posant des questions plus techiniques . Vous avez utilisé ca, comment et pourquoi, Et cette méthode qu'en pensez-vous ? Nous on utilise cette technique plutot, vous en pensez quoi...

Comme dit plus haut, en 1h30 on sait si on a envie de bosser avec le mec, ses compétences techniques et ses compétences relationnelles. Et si on se plante vraiment, il reste la période d'essai.
13  0 
Avatar de TotoParis
Membre éclairé https://www.developpez.com
Le 30/03/2021 à 14:12
Mais quelle boite va mettre en oeuvre un processus aussi lourd ? Où sont les compétences dans les boites pour valider ce qui en sort ?
Franchement, c'est totalement délirant.
Et ceux qui ignorent totalement ce jeu ne sont-ils pas désavantagés par rapport à ceux qui en ont une bonne pratique ?
10  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 01/04/2021 à 5:20
Factorio... Le gameplay semble attrayant. Mais le candidat n'a pas non plus une demie journée à consacrer à un entretien d'embauche.

Un truc tout simple déjà pour partir sur de bonnes bases mais qui n'est pas si souvent que ça mis en pratique : associer un développeur interne au processus de recrutement. Et pas uniquement des managers et des chefs de projet.
9  0 
Avatar de coolspot
Membre éclairé https://www.developpez.com
Le 30/03/2021 à 15:18
Putain c'est devenu délirant ces putain d'entretien technique. On est passé de petite question théorique pour juste checker les base à un bouzin infame ou tu dois passer 2 à 20h dessus.

On cherche un job bordel on a pas que ca a foutre de passer de 2 a 20h sur des entretiens technique à la noix qui de toute façon ne reflètent en rien le boulot de la dite entreprise et des projet dedans. Surtout que bon c'est du travail gratuit bordel et quand on cherche une boite on a pas tout ce temps à consacrer à un entretien d'embauche. On va pas passer 2 a 20h de test d'entretien technique sur les 20 boites qu'on postule en meme temps ca n'a aucun sens.

C'est comme si on disait à des maçon de fait les mur porteur de la maison qu'on veut comme entretien technique pour savoir si on va l'embaucher pour qu'il construisent notre maison
6  0 
Avatar de Eric30
Membre actif https://www.developpez.com
Le 02/04/2021 à 8:36
Le mieux que j'ai trouvé, c'est encore la discussion bienveillante avec la personne qui sert de base pour savoir ce qu'il a fait.
Ensuite on lui demande d'expliquer les sujets sur lesquels il a travaillé qui nous paraisse pertinent, en évaluant sa capacité a expliquer ce qu'il a fait.

une personne qui ne sait pas de quoi elle parle, ca se repère vite.
Des dev peuvent également, toujours avec bienveillance, creuser ces sujets en posant des questions plus techiniques . Vous avez utilisé ca, comment et pourquoi, Et cette méthode qu'en pensez-vous ? Nous on utilise cette technique plutot, vous en pensez quoi...

Comme dit plus haut, en 1h30 on sait si on a envie de bosser avec le mec, ses compétences techniques et ses compétences relationnelles. Et si on se plante vraiment, il reste la période d'ess
Pas mieux. J'ai deux feuilles A4 écrites en Arial 10 contenant des dizaines de sujets de questions classés par thèmes. À chaque entretien technique, je pioche au hasard dedans (enfin pas toujours, car des fois je cherche quelqu'un pour des compétences précices).

Ensuite une bonne discussion qui amène des questions, et malgré tout, un petit test technique qui prend 2h, à rendre sous une semaine (no stress) et un deuxième entretien (15mn) pour débriefer, que le développeur puisse expliquer son travail. Il est intéressant de noter que nous avons déjà recruté des personnes dont le test technique était pas terrible mais qui avaient compensé sur les autres volets de l'entretien, et avec le recul, cela m'a conforté sur le fait que chercher des "métriques" et autre évaluations purement factuelles sur des êtres humains, c'est de la bêtise

Celui qui hésitait systématiquement avant de choisir une carte était le même qui devant un problème s'arrêtait attendant une intervention extérieure pour l'aider à le résoudre.
Alors tu ne m'aurais jamais recruté. Non pas que j'attende toujours une intervention extérieure, c'est juste que je ne suis pas le genre de personne à foncer tête baisser quand il y a des décisions à prendre.
6  0 
Avatar de pmithrandir
Expert éminent https://www.developpez.com
Le 02/04/2021 à 10:36
Pour l'idée d'utiliser la période d'essai, je vou rappelle juste que ca coute cher de recruter, d'intégrer, etc... et que ca fait jamais plaisir a personne de mettre quelqu'un dehors, surtout qu'il n'aura peut etre pas el chomage.

Il faut donc faire un premier tri.

Après, j'ai choisi de faire globalement confiance aux gens avec qui je discute, en creusant les sujets avec eux sans mettre de pression.
Si la personne me ment et qu'elle ne sait pas c qu'elle prétend savoir, je n'aurai aucune hésitation a le mettre dehors, mais dans le cas contraire, pourquoi lui prendre la tête avec des questions débiles stressantes.
6  0 
Avatar de Mingolito
Membre extrêmement actif https://www.developpez.com
Le 01/04/2021 à 3:04
La méthode Factorio à l'air pas mal mais du coup si ça venais à se faire et à ce savoir certains ne manquerais pas simplement de s'entrainer à Factorio et du coup le test serait faussé.

C'est comme les tests de QI, en fait on peu s'entrainer aux tests de QI et quand tu es devant le DRH qui t'annonce que t'es un vrai génie tu te dis, mais c'est pas un peu crétin un DRH ?
4  0 
Avatar de dissert
Membre averti https://www.developpez.com
Le 01/04/2021 à 8:35
Dans le contexte actuel (pénurie de développeurs, je vous rappelle), imposer plus d'une demi-journée à un candidat, pour l'équivalent d'un entretient, c'est mettre la boite sur la touche...
3  0 
Avatar de GameMaster1337
Futur Membre du Club https://www.developpez.com
Le 30/03/2021 à 15:07
Jouer à un jeu pendant 20 heures en lieu et place de l'entretien technique ? Quelle blague, si une entreprise ne sais pas comment embauché, autant passé par une agence ou autre.

Sur un poste / techno / secteur que je connais, en moins d'une heure je connais le niveau de la personne en face de moi.
2  0 
Avatar de Christian_B
Membre confirmé https://www.developpez.com
Le 08/04/2021 à 14:33
Indépendamment des objections déjà avancées contre l'idée de ce jeu de construction industrielle ayant un rapport problématique avec la programmation, je vois aussi une autre biais doublé d'un problème éthique : on favorise les candidats qui prendront plaisir (et donc seront motivés) pour massacrer des indigènes (ou au minimum ceux qui s'en foutent).
Cela écarterait ceux qui n'aiment pas ce cynisme.
Un bon test peut-être pour l'armée si elle veut embaucher des programmeurs pour des drones tueurs.
2  0