1) Entretien préliminaire avec le recruteur technique 2) Discussion avec deux SDET (entretien technique) 3) Test technique à domicile (une semaine pour le réaliser) 4) Entretien avec le VP test Les deux premières étapes se sont très bien passées. Le recruteur technique était super, très sympathique et avec une excellente communication. Le deuxième entretien avec les deux SDET s'est bien déroulé aussi, ils étaient sympathiques et nous avons discuté de quelques aspects techniques. En revanche, le test technique (réalisé à domicile) a été une vraie déception. Il s’est avéré d’une qualité nettement inférieure à ce que l’on pourrait attendre d’une entreprise à la pointe de la data science. L'exercice imposait de réinitialiser la base de données à chaque exécution des tests API, une demande incompréhensible et fondamentalement erronée sur le plan technique. Cette approche provoque des interférences évidentes entre les tests en cas de runs parallèles, un problème basique de gestion de concurrence que tout professionnel du test devrait reconnaître. C'est une erreur évidente qui n'aurait pas dû se retrouver dans un test technique sérieux. Après avoir pris le temps d'expliquer en détail pourquoi cette approche était problématique lors d'un entretien avec un responsable des tests, il est apparu clairement qu’il y avait une réelle déconnexion entre ce qui est attendu des candidats et les meilleures pratiques en ingénierie des tests. Bien que le responsable ait été à l’écoute, il n’a pas officiellement reconnu les problèmes, malgré les arguments factuels (il a parlé de potentiel post mortem, mais bon, à voir). En effet, même dans des environnements professionnels, comme ceux de Dataiku par exemple, il est impensable de réinitialiser la base de données à chaque test, car cela perturberait les tests. Un autre point fondamental que j'ai soulevé concerne la validation des données via des tests API, ce qui n'est pas leur rôle. Cette tâche incombe aux tests d’intégration. L'erreur ici est que l'exercice ne respectait pas la pyramide des tests, ce qui aboutit à une structure inefficace où la validation se fait au mauvais niveau. Ignorer ce principe démontre une mauvaise compréhension de la conception des tests. (On peut faire ces vérifications coté API si on a pas de tests d'intégration, mais reprocher aux candidats de respecter la pyramide n'a aucun sens). Enfin, j’ai constaté une certaine incohérence au niveau des compétences techniques lorsque des difficultés ont été rencontrées pour exécuter le projet ultra simple alors qu'il a un fichier ReadMe et trois commandes à copier-coller. Cela est inquiétant, surtout venant d’une entreprise censée être à la pointe de la technologie et spécialisée dans la data science. En conclusion, cette expérience a été décevante. Le temps et l'effort exigés pour cet exercice ne correspondent pas à la qualité des retours et des attentes. Si l'entreprise est sérieuse quant à son processus de recrutement, il est crucial qu'elle prenne en compte ces critiques et corrige les erreurs dans ses exercices techniques. Sinon, elle risque de passer à côté de candidats qualifiés, et de continuer à utiliser des tests qui n'ont aucun sens sur le plan technique.