Lorsque l’on cherche un nouveau job, un premier job, une alternance ou même un stage dans le développement web, il est très fréquent que la demande d’un test technique pointe le bout de son nez.

De la même manière, lorsque l’on souhaite recruter une nouvelle personne dans son équipe, nous voulons faire le bon choix et s’assurer que le profil correspondra au besoin.

Le test technique :


Un bon test technique ne doit pas forcément être long, mais surtout précis. Il est d’ailleurs préférable de l’optimiser au maximum afin de ne pas faire perdre trop de temps aux candidats, mais aussi de pouvoir avoir un retour du candidat plus rapide.

Tout test pouvant être exploité par l’entreprise, autrement que pour évaluation des compétences, est à proscrire. Il ne doit pas y avoir le moindre doute.



Concevoir ou aborder un test technique :


La première étape pour concevoir ou aborder un test technique est d’analyser le contexte du recrutement.
Quelles compétences cherchons-nous / Quelles compétences sont recherchées par l’entreprise ?

Exemple : Un profil maîtrisant une technologie précise pour intervenir sur un projet ciblé, un profil ayant une bonne capacité d’adaptation sans forcément d’expertise dans un domaine en particulier, etc.

Candidats : Essayez d’obtenir un maximum d’informations sur les besoins de l’entreprise, afin de préparer au mieux votre évaluation technique. Bien comprendre les qualités recherchées par l'entreprise est important. Cette collecte commence dès la préparation de l’entretien.

Vient ensuite la nécessité de comprendre la finalité du test technique.
Pourquoi réaliser ce test ? Comment en tirer quelque chose ?

Proposer un test technique ou devoir en passer un ne doit pas être anodin. Il doit permettre de vérifier/démontrer des compétences, attitudes, etc, bien définies.

Chaque entreprise a des besoins différents, il est donc compliqué de catégoriser proprement les types de tests techniques, mais nous allons tout de même essayer ! Deux catégories de tests se dessinent :

Les tests de compétences opérationnelles


Le test technique permettant de valider des compétences précises devant répondre à un besoin spécifique.

Exemple : Une ESN a besoin d’un développeur FRONT-END Angular, opérationnel immédiatement, pour pouvoir intervenir chez le client X au plus vite.

Dans ce cas, l'entreprise doit s’assurer que le profil ciblé soit en mesure de répondre, sans aucun doute, au besoin.

Le test pourra donc prendre la forme d’un court projet à réaliser, avec des contraintes précises, permettant donc de valider ou non les compétences requises.

Candidats : vous n'avez qu’à suivre les consignes, normalement bien cadrées afin de réaliser le test.

Ce test est le moins compliqué à concevoir, à passer, mais aussi à évaluer.

Les tests de compétences évolutives


Le test permettant de valider certaines compétences, mais aussi et surtout une attitude face à un problème, la capacité d’adaptation et tout simplement que le profil est dans la même dynamique que ce dont a besoin l’entreprise.

Exemple : Une société Y, éditrice de solutions web dans la proptech, souhaite renforcer son équipe de développeurs afin d’assurer sa croissance et de répondre de manière optimale aux besoins de ses clients.

Dans ce cas, l’entreprise doit s’assurer que le profil ciblé a un socle de compétences techniques minimal, mais aussi une bonne capacité d’analyse et d'adaptation et que le profil sera capable de faire des choix techniques pertinents, en rapport avec le besoin.

Le test pourra cette fois-ci être beaucoup plus ouvert, afin d’analyser la manière dont le candidat réagit face à la problématique. Plus on laisse de liberté, plus le test sera intéressant à analyser et ainsi, plus d'informations s’en dégagent.

Candidats : ce type de test technique est plus complexe à réaliser, car l’entreprise analysera vos choix technologiques, vos architectures et votre conception dans son ensemble. D'où l'importance de bien analyser le contexte du recrutement en amont.

TIPS en pagailles :




Maîtriser ses choix techniques :


Un candidat se doit de maîtriser certaines décisions techniques non imposées dans le cadre du test. Du moins, dans une certaine mesure, dépendant du niveau recherché.

Recruteurs : Il est toujours intéressant de questionner un candidat sur ses choix techniques pour s’assurer qu’il maîtrise ce qu’il fait ou du moins qu’il y a une raison (valable ?) derrière.

Candidats : Tout choix concernant les différentes composantes de votre test doivent pouvoir être justifiées. Pas de place pour le hasard. Avant de rendre votre travail, posez-vous des questions : Pourquoi avoir choisi tel framework ? Pourquoi avoir fait ce choix d’architecture ? Pourquoi stocker ces informations de cette manière ?

Penser présent, mais aussi futur :


Bien que ce soit un exercice et que le code produit n'ira pas plus loin après l’entretien, pensez tout de même au futur. Il est toujours important d’anticiper les évolutions futures dans ses développements, sinon, on perd du temps. C’est pourquoi il peut être intéressant de montrer à l’entreprise que vous êtes attentif à de potentielles évolutions et que demain, si vous êtes pris, cette qualité ne pourra être que bénéfique pour elle.

Utiliser Git :


L’utilisation de Git permet (outre le fait de confirmer ses compétences sur l’outil) d’en apprendre beaucoup sur l’organisation, la rigueur et bien d’autres points d’un candidat.

Recruteurs : Demander un rendu sur Git permettra souvent (en plus de faciliter le rendu) de mesurer la rigueur d’un candidat. Généralement, un développeur soigné et rigoureux, tiendra un répertoire propre, avec des noms de commits qui ont du sens et des branches adaptées.

Candidats : Soignez votre Git et maitrisez votre workflow. Cela passe par :

  • Des commits faits aux bons moments
  • Des noms de commit qui ont du sens
  • La création de branches de travail (master -> dev -> feat/feat_x)
  • L’utilisation de `pull requests`
  • Un workflow réfléchit (pas forcément complexe, mais avec du sens)


Développer des tests unitaires :


Que l’on soit pour ou contre les tests unitaires, un développeur qui sait faire des tests unitaires sera toujours plus à même de ne pas en faire que l’inverse. C’est pourquoi, il est recommandé d’accompagner ses fonctionnalités avec des tests unitaires, dans le doute.

Commenter son code (ou pas) :


Question qui revient souvent, doit-on commenter son code lors d’un test technique ? Libre à vous de le faire ou non, tant que vous pouvez le justifier. Je ne suis, personnellement, pas pour les commentaires (ni contre), car je pars du principe que si un code est bien découpé, que les variables et fonctions sont bien nommées, nul besoin de commentaire, le code se lit aisément.


De manière générale, essayez de considérer le test technique comme un projet classique, avec tout son sérieux et tous les éléments qui gravitent autour. Pensez également aux “plus” qui pourraient faire la différence : par exemple, déployer son application pour la rendre accessible depuis le web, mettre en place un peu de devOps, etc.

Plutôt que de voir le test comme un obstacle, voyez le comme un tremplin : servez-vous-en pour démontrer vos compétences et votre talent.

Bon courage à tou.te.s !