Dernière mise à jour:
Examen en ligne
mohamed_hassan from Pixabay

Les tests techniques

Ça ne vous aura pas échappé, aujourd’hui, lorsqu’on cherche un job ou même quand un recruteur vient vous démarcher pour un post, vous devez passer par un entretien technique.

omg

Il en existe de différentes formes. Allant de la simple discussion à la demi-journée ou journée d’intégration dans une équipe.

Une étape cruciale…

C’est une étape très importante du processus de recrutement. À la fois, elle est éliminatoire si elle ne se passe pas bien (les critères différents selon les entreprises) mais elle est aussi déterminante dans la négociation du votre future rémunération. En effet, si vous prétendez être un développeur senior, il faudra que ça se ressente lors de ce test. Encore une fois, les attentes sont très différentes d’une entreprise à l’autre. Vous pouvez être senior où vous êtes actuellement sans que ce ne soit le cas ailleurs. Tout va dépendre de ce que vous pourrez mettre en avant et des critères d’évaluations de l’entreprise cible.

…mais qui divise

On voit souvent des débats sur LinkedIn à la suite d’un sondage, Faut-il continuer les tests techniques ? Ou Faut-il pair programmer ou faire un test à la maison ? On trouve dans les commentaires toute sorte de réaction. Et il y a clairement un camp pour les tests techniques et un contre.

Ce genre de tests peut en réalité toucher des points sensibles chez bon nombre de personnes. C’est en effet un exercice où on s’expose vraiment dans notre pratique. Pour certains, ça peut être compliqué. C’est aussi un moment où on se met face à nos limites. Cela peut être un moment difficile si on n’est pas prêt à les accepter.

Mon point de vue

Pour ma part, je n’aime pas ces tests. Il me donne l’impression d’être retourné à l’école ou de repasser le permis. Ce qui me dérange, c’est le côté examinateur VS examiné. La plupart des tests techniques que j’ai passés ne m’ont pas donné l’impression d’une discussion entre collaborateurs. J’ai vraiment eu la sensation de passer un examen et d’être jugé.

Dans ces conditions, je suis généralement extrêmement mauvais en live coding et pas du tout motivé pour réaliser un projet de test sur mon temps libre. Les résultats sont assez mauvais. Je ne compte plus le nombre d’entretiens que j’ai raté à cause de ça. Même si ça parait idiot, ça peut être sacrément handicapant professionnellement.

De l’autre côté du miroir

Lorsque je dois faire passer un entretien technique, je ne suis pas à l’aise de mettre quelqu’un dans une situation que moi-même, je n’apprécie pas. Et j’ai donc bien réfléchi à comment je voudrais que ça se passe pour moi.

Premièrement, je demande à la personne si elle préfère prendre le temps de réaliser le test tranquillement chez elle ou plutôt en live avec moi. Bien évident, ce n’est pas du tout le même exercice. Le test à la maison est plus conséquent et complet que le live coding. L’objectif ici et de permettre au candidat d’être dans les bonnes conditions pour montrer son savoir-faire. Il peut tout à fait me fournir un projet déjà réalisé qu’il considère être une bonne vitrine de ses compétences.

Pour l’exercice à la maison, il s’agit d’un jeu de rôle assez simple. Je suis un client avec un besoin et le candidat, un prestataire pour la réalisation de l’application. J’adapte le sujet à chaque profil, l’idée étant de proposer une demande adapté. Le projet ne doit pas prendre trop de temps à réaliser, mais être suffisamment riche en logique métier pour permettre de s’exprimer.

Ce que je vais regarder ici, ce sont le pratique du candidat, la qualité du code, les tests, l’architecture. Comment il a réagi face à une ambiguïté. L’analyse du projet est faite sans jugement, elle sert juste à poser des questions et dirigé l’échange technique qui vient après. Même si je vois quelque chose qui ne me plaît pas, ou s’il manque une pratique que je trouve indiscutable aujourd’hui (par exemple les TUs), c’est l’échange qu’on aura derrière qui me permettra de tirer une conclusion. Je préfère nettement rencontrer quelqu’un qui a des lacunes ou des pratiques différentes des miennes tout en étant ouvert d’esprit que quelqu’un de dogmatique qui considère tout ce qui est différent avec dédain.

Concernant le live coding, je veux que le candidat soit le plus à l’aise possible et qu’il sente qu’il puisse s’exprimer librement. Il a donc le choix du langage et des outils, c’est à moi de m’adapter. J’amène le sujet, c’est souvent un Kata réadapté pour l’occasion. Je vais être attentif aux mêmes choses que pour le projet à la maison, sauf que les questions viendront en live. Lorsque la techno choisie le permet, je vais prendre le clavier et avancer sur le projet. Du fait que je prenne le rôle du driver, je laisse le candidat agir en tant navigateur. Échanger les rôles me permet de voir comment on échange sur une problématique et surtout si vraiment, je me sens à l’aise de travailler avec cette personne.

Afin que je ne puisse pas me positionner malgré moi dans le rôle du « sachant » et tomber dans un biais qui compliquerait mon objectivité, je ne choisis que des sujets que je n’ai jamais réalisé moi-même ou vu dans un passé proche. Cela me permet de partir sans a priori et d’être complétement ouvert à la solution proposée par le candidat.

À quoi doit servir un entretien technique ?

De mon point de vue, l’entretien technique ne doit pas être éliminatoire. Une recrue s’évalue sur bien plus qu’un test. La seule information qu’il peut apporter, c’est à quel niveau on peut la faire entrer. Quel investissement il va falloir pour l’intégrer dans notre équipe avec nos attentes. Est-ce que la rémunération demandée correspond à ce qu’elle sera capable d’apporter à son arrivé ? Pour faire simple, est-ce que je suis en face de quelqu’un qu’on considère être un junior, medior, senior, etc.

D2velop

Je sais que je ne suis pas le seul à ne pas être très à l’aise lors de ces entretiens (👋 syndrome de l’imposteur). C’est pourquoi, au travers de D2velop, je propose d’aider celles et ceux qui ne se sentent pas prêts ou qui appréhendent cet exercice. Parce que, comme tout, il se prépare, et une fois qu’on est prêt, il n’y a plus aucun problème. Pour bénéficier de mon aide, il vous suffit de remplir le formulaire sur d2velop.fr.

Cédric Gérard

Cédric Gérard

Je suis dans l'informatique depuis tout jeune. D'abord intéressé par le hardward (montage, overcloking), j'ai mis du temps à trouver ma voie. Je suis tombé dans le développement en 2007, je n'ai jamais arrêté depuis..

Aujourd'hui, je suis développeur web avec une plus grande appétence pour le backend. J’accorde beaucoup d’attention à la valeur apportée aux utilisateurs finaux. On ne réalise pas d'application que pour se faire plaisir, après tout.

Je mets aussi un point d'honneur à livrer du code de qualité en m'appuyant sur les bonnes pratiques du développement logiciel et je défends les valeurs du software craftmanship.

L'agilité est également un élément essentiel pour un travail fiable et efficace. Je ne parle pas de méthode, mais de l'état d'esprit prôné par l'agilité.

J'aime partager mes compétences et j'ai une appétence particulière pour l'encadrement des développeurs juniors.

Je suis également en quête de sens, aucune technologie étant une fin en elle-même, j'ai besoin de savoir pourquoi je travaille et qu'elle est la valeur produite.