January 10, 2022

Test technique lors du recrutement

J’ai récemment passé en tant que candidat un certain nombre d’entretiens (pour des postes type "SRE") et j’ai donc pu voir un peu ce qui se faisait comme tests techniques aujourd’hui. Voici mon avis sur la question.

Le test technique

Comment juger les capacités techniques d’un candidat ? Les entreprises font généralement passer aux candidats un test technique.
Je me demande parfois si il est vraiment possible d’avoir un test technique pertinent et d’une durée raisonnable. Est-il vraiment possible de juger quelqu’un sur quelques exercices ?

Mais quoi qu’on en pense ces tests sont là, sous différentes formes, et voici ce que j’ai rencontré sur le marché de l’emploi en 2021.

Test d’algorithmie

On entend souvent parler de ce genre de tests: on vous expose un problème et vous devez proposer une solution (ou plusieurs, la solution évoluant pendant l’interview) pour résoudre ce problème.
Ces tests ont été popularisés par les grandes entreprises tech américaines et ce sont des tests que l’on retrouve aujourd’hui un peu partout, et notamment dans les grosses boîtes tech.

Je ne vois personnellement pas vraiment l’intérêt de ce genre de test. Pouvoir réussir ces tests d’algorithmie demande en effet qu’une seule chose: de la préparation et du bachotage. Ils ne jugent donc que d’une chose: avez-vous passé vos 6 derniers mois à faire tous les exercices décrits dans le livre "Cracking the coding interview" ? Cela montre une motivation certaine mais ne nout dit pas grand chose sur les capacités de la personne.

De nombreuses personnes échouent à ce test, et c’est normal. Vous pouvez d’ailleurs généralement retenter votre chance après une certaine durée (6 mois par exemple) chez les GAFAM après échec, donc à force d’insister cela peut finir par passer.
Je trouve ça personnellement étrange, vous n’êtes pas pris mais 6 mois après vous êtes soudainement au niveau parce que ce coup ci l’intervieweur vous a posé un problème qui, coup de chance, est semblable à un que vous avez résolu durant votre entraînement la veille.

J’ai toujours aimé l’algorithmie. J’avais quand j’étais étudiant pris toutes les options d’algo disponibles durant mon Master, j’ai donc quelques bases correctes. Avec le temps j’ai bien sûr oublié pas mal de choses mais les bases restent et je sais reconnaître certains problèmes et où chercher pour les résoudre.

je pense néanmoins que ces tests ne sont pas pertinents et donc je préfère éviter les entreprises avec ce genre de tests à l’entrée. Vous avez passé des années sur des problématiques de code et d’infrastructure complexes, mais vous avez raté votre inversion de binary tree à l’interview donc vous n’êtes pas pris.

EDIT: je ne dis pas que l’algorithmie et les structures de données ne sont pas des sujets importants, mais qu’utiliser cela comme premier test pour filtrer des candidats en masse en les exposant à des problèmes fantaisistes n’est pas ma tasse de thé.
Une personne très compétente peut très bien bloquer sur un problème, comme une autre tomber sur un problème comme je disais rencontré la veille.
Et est ce que ces tests sont vraiment représentatifs de notre métier ? Ne pouvons-nous pas tester autrement ce type de connaissance ?

Test technique interminable

J’avais reçu après un premier entretien dans une startup un test technique à faire à la maison surprenant.

Je devais écrire une application Python type CRUD (je ne fais pas de Python mais passons) stockant ses données dans PostgreSQL, et gérer ensuite son packaging et son déploiement.

Le déploiement devait se faire sur le cloud de Google (GCP) où je devais déployer l’application sur Kubernetes, puis PostgreSQL en statefulset sur Kubernetes également en mode master/replicas (sans tricher: pas d’operators ou de trucs tout faits). L’application devait parler à un proxy PostgreSQL qui devait se charger de faire la bascule sur le réplica en cas de panne du master. Tout cela devait bien sûr être automatisé avec des outils d’infrastructure as code.

On m’annonçait 12 heures pour la durée de ce test, je l’estime personnellement à plus surtout que je connais mal Python et pas du tout GCP.

j’aurai très bien pu faire ce test (techniquement ça ne n’impressionnait pas plus que ça, c’est juste pénible) mais là aussi je ne vois aucun intérêt à faire un test aussi long, donc j’ai préféré décliner.
Les entreprises doivent comprendre que le temps libre des candidats est aussi limité et qu’on ne peut pas passer des jours à réaliser des tests.

Test écrit

Le test technique que j’ai le plus apprécié était un test théorique. Je devais répondre en quelques heures chez moi (on m’avait indiqué 3 heures maximum, j’ai fait un petit peu plus) à quelques questions et mises en situation autour d’aspects SRE, d’architecture et de performance.

C’était volontairement des questions très ouvertes mais c’est au final la force du test: voir le raisonnement du candidat et les questions et hypothèses qu’il va poser. j’ai vraiment eu le sentiment de pouvoir expliquer ma façon de réfléchir pendant ce test qui était purement écrit, bien plus que lorsqu’on me demande de pondre un rôle Ansible ou un module Terraform.
Je m’en fiche personnellement de savoir si quelqu’un maîtrise Ansible, au pire il ou elle apprendra. Cet exercice écrit permettait de discuter de concepts et pas seulement de technologies, et c’est cela que je recherche dans un test technique.

Une fois le test réalisé un entretien de débriefing était organisé pour discuter du résultat et creuser certains points.

Et vous, que pensez-vous des tests techniques en entretien ?

Add a comment








If you have a bug/issue with the commenting system, please send me an email (my email is in the "About" section).

Top of page