Symfony et test technique lors d'un entretien d'embauche

Chaque société, voire même chaque équipe, a son process de recrutement. Le candidat doit avoir ce qu'on appelle désormais des soft-skills en adéquation avec la culture de la société. Mais cela ne fait pas tout. Notre profession est souvent testée techniquement. Certaines sociétés organisent des demi-journées en Peer Programming, pour d'autres ce sont des tests devant un tableau blanc, quand d'autres se contentent d'un QCM de 20 questions. J'ai eu à plusieurs reprises à recruter pour des postes de développeur Symfony récemment, et voici en quoi Symfony m'a aidé.

Préambule : Comment s'articule le test technique que je donne au candidat ?

Avant d'envoyer le test technique, j'ai systématiquement un call avec le candidat. Outre l'appréciation de la personnalité et de l'intérêt du candidat, ce premier entretien me permet de voir entre autres les technos utilisées en interne que le candidat ne connaît pas forcément. Si ce premier entretien est concluant, je propose un test technique qui durera environ 4h. J'adapte le test en fonction du profil. 4h pour un junior, ce n'est pas pareil que 4h pour un dev Senior ou pour un lead. Il a une semaine pour le faire, à son rythme.

J'ai eu à recruter pour des postes de développeur NodeJs et des postes de développeur Symfony. Lorsque je recrutais des profils JS, le candidat perdait un temps précieux à bootstrapper un projet. Aujourd'hui avec Symfony, il a tout ce qu'il faut pour se lancer directement dans le test.

Et si on améliorait ce processus ?

On peut créer un projet de base pour le candidat. L'idée est de s'occuper pour lui de tout ce qui est essentiel pour un vrai projet, mais qui n'apporte que peu d'intérêt dans le cadre de ce test. C'est le cas par exemple de la sécurité. On a la chance d'avoir un écosystème très fourni et on peut facilement gérer la connexion / inscription des utilisateurs avec FOSUserBundle. On veut tester les facultés du candidat sur une API REST ? On configure ApiPlatform, et le tour est joué.

Tips de recruteur :

Si une société vous met à disposition ce type de dépôt déjà bootstrappé, et sauf si cela est demandé, ne le forkez surtout pas. il vaut mieux le cloner en local et changer les remote de git pour que origin pointe sur un repo propre à votre compte. Sans cela votre test technique sera visible des autres candidats.

Alors que reste-t-il à tester ?

Sécurité

Dans mon cas, je souhaite appréhender ses notions de sécurité informatique (comme par exemple ne jamais faire confiance aux inputs utilisateurs) : on peut lui demander d'exécuter une commande shell avec un paramètre qui provient de la Request. Un des tests que j'aime bien proposer est de faire un mini Github. C'est à dire qu'avec une API Rest, on va pouvoir exécuter un merge dans des repos git stockés en local.

• S'il effectue une veille sur l'écosystème Symfony, le candidat utilisera le composant Process.
• S'il est juste conscient des enjeux de sécurité, il utilisera escapeshellcmd ou apparenté.
• S'il n'échappe pas ses paramètres, … aïe…

Conception de base de données à partir d'une demande light

Dur de trouver un gif sur les bases de données. À la place, j'ai préféré illustrer avec le chargement des tableaux…

Cette partie du test se décompose en quelques implémentations de base (ajouter un champ sur une entité, ajouter une liaison many to many porteuses de propriétés entre 2 entités, …). Doctrine nous aide beaucoup, certes, mais cet exemple est assez parlant :

un utilisateur inscrit peut enregistrer une marque d'intérêt sur une campagne en précisant le montant qu'il souhaite investir

Si le candidat prend le temps de regarder notre site et donc notre activité en amont, il comprendra que j'attends une liaison N..N, qui ne peut pas être modélisée par un ManyToMany car on a une information supplémentaire sur la liaison (le montant). J'ai eu je pense toutes les interprétations possibles de cette phrase :

• le montant remonté au niveau de l'utilisateur avec une ManyToMany
• idem, mais avec le montant placé au niveau du projet
• pas de montant du tout car le candidat ne savait pas comment faire

Dans ce cas, cela nous permet de valider, en plus des compétences techniques, la réaction d'un candidat dans la vie de tous les jours d'un développeur : coder avec des specs light.

Concept métier

J'attends d'un développeur qu'il soit partie prenante au produit, qu'il suggère des évolutions autant que peuvent le faire ses utilisateurs, qu'il comprenne les impacts de son développement sur le quotidien des utilisateurs et notamment en terme d'UX. Le premier entretien téléphonique m'a déjà permis de filtrer les candidats qui ne portent pas d'intérêt pour notre métier. Les candidats qui arrivent donc au test technique ne sont pas des experts, mais ont tout du moins quelques notions sur le sujet. L'implémentation d'un concept de notre métier peut revêtir différentes formes : lorsque je travaillais à Wheeliz, il pouvait s'agir d'un calcul de tarifs via un algo de yield management ; aujourd'hui, à Anaxago, ce sont plutôt des questions financières (taux d'intérêts, capitalisation, …). Le développement de cette partie reste tout de même ardue pour un candidat, et cela permet de comprendre son approche :

• est ce qu'il va me poser des questions pour bien comprendre ce que j'attends de lui ?
• aura-t-il cherché une librairie ?
• et surtout, comment va-t-il architecturer son code par rapport à la structure Symfony ?

Conclusion

Vous avez vu, il n'y a pas beaucoup de code dans cet article. Mais les tests techniques sont proposés à l'image de Symfony. Ils permettent de se consacrer à l'essentiel. Pour moi ce sera la sécurité, la modélisation de base de données, les APIs (Rest, GraphQL, …), et on voit qu'en creusant chacun de ces sujets, la code review avec le candidat est très intéressante, factuelle, et surtout représentative de quel onboarding sera nécessaire pour l'accueillir dans les meilleures conditions.

Post-scriptum

Le candidat vient de consacrer 4h de son temps à répondre au test technique, il est donc légitime de faire une code review avec lui, quelle qu'en soit l'issue.

• Il faut donc en profiter pour lui montrer les bons développements, et lui indiquer des axes d'amélioration ;
• Ne pas porter de préjugés sur ses choix techniques, et plutôt préférer le questionnement ;
• Ne pas se focaliser sur les détails de type code guideline (Ex : propriétés css par ordre alphabetique, longueur maximum d'une ligne, …) car ces points seront plutôt adressés par des outils en interne, au moment du commit éventuellement, et ne préjugent en rien des qualités du candidat.