Mes 7 conseils pour réussir son passage devant un jury d'école

Cela fait aujourd'hui plus de deux ans que je suis régulièrement juré pour des écoles de code un peu partout en France (principalement Tours, Nantes et Paris pour l'instant) pour les titres professionnels DWWM et CDA.

Il m'arrive très souvent de redonner les mêmes conseils aux étudiants pour leur soutenance, alors j'ai décidé de regrouper, une fois pour toutes, tous ces conseils en un seul article de blog :

#1 - Ne pas avoir peur des jurés

On rencontre régulièrement des étudiants qui tremblent, perdent leurs moyens, se mélangent les pinceaux et qui sont à la limite de l'auto-sabotage à cause du stress engendré par la présentation devant un jury.

Souvenez-vous que les jurés ne sont là que pour valider les compétences que vous leur présentez en fonction du référentiel qui leur a été confié, et rien d'autre ! Leur job n'est pas de vous faire peur, de vous rabaissez ou de vous pointer du doigt, bien au contraire.

Je n'ai encore jamais rencontré de juré dont l'objectif n'était pas de tirer les étudiants vers le haut !

#2 - Relire et faire relire son dossier

Même après relecture on peut laisser une ou deux coquilles ici ou là, mais laisser une faute à chaque ligne ou paragraphe donne vraiment une impression que l'étudiant.e n'a pas accordé suffisamment de soin à son dossier, et peut même parfois rendre la lecture et la transmission d'informations difficiles !

Dans l'idéal, faites-le relire par au moins deux autres personnes en plus de vous.

#3 - Numéroter ses slides

C'est un petit détails mais qui a son importance ! Lorsque vous présentez vos slides, si l'un des jurés a une question, il doit attendre la fin de votre présentation, et si la question porte sur une slide en particulier, il ne pourra pas noter l'emplacement exact de cette dernière.

De votre côté, lorsque vous aurez à retourner dessus, vous passerez 5 minutes à la retrouver, plombant par la même occasion le rythme de la soutenance !

Numérotez vos slides aidera le juré ainsi que vous-même, une pierre deux coups !

#4 - Faire des captures de code lisibles

On aime (presque) tous utiliser notre éditeur de code en mode sombre, mais faire des captures de votre code dans votre éditeur n'est pas du tout adapté, ni à votre rapport, ni à vos slides !

• Trop d'encre utilisée et l'impression n'est souvent pas top
• Les contrastes du projecteur rendent le code illisible

Plutôt que de faire une capture d'écran de votre éditeur, optez-plutôt pour un outil spécialisé comme je présente dans l'article ci-dessus, et choisissez un thème clair !

#5 - Ajouter des slides cachées

Les slides cachées sont des slides disponibles à la fin de votre diaporama, après la slide de remerciement qui vous permettent de positivement surprendre le jury, mais aussi de vous aider dans votre présentation.

Voici quelques exemples de slides cachées qui peuvent être intéressantes :

• Anticiper des questions sur un point que vous n'avez pas montré pendant votre présentation par manque de temps
• Vous aider à répondre à des questions complexes (sécurité par exemple)
• Montrer des diagrammes ou du code qui auraient alourdi la présentation initiale
• ...

Lorsque vous arrivez au sujet en question, hop, vous sortez votre slide cachée et c'est en général une très bonne surprise !

#6 - Savoir dire "je ne sais pas"

Il m'est arrivé plusieurs fois que des étudiants se justifient d'avoir choisi une technologie en particulier parce que c'est "plus rapide" ou parce que c'est "mieux que le reste", sans vraiment connaitre le fonctionnement interne ou les performances de l'outil en question.

N'ayez pas peur de dire "je ne sais pas", ou "on a fait ce choix car cela nous a semblé être le mieux mais sans connaitre toutes les alternatives" ! Ou alors, sortez le benchmark de la technologie que vous utilisez, et là vous pourrez dire "parce que c'est plus rapide" !

Vous êtes étudiant, vous n'êtes même pas encore développeur junior, vous avez le droit de ne pas connaitre de nombreuses choses.

Le plus important est de montrer que vous voulez apprendre ce que vous ne connaissez pas encore !

#7 - Ne pas rejeter la faute sur les autres

Même si vous êtes étudiant, vous devez avoir un comportement professionnel, alors dire "c'est la faute d'un camarade" ou "c'est parce que le formateur..." ou même rejeter la faute sur l'école ne fera rien avancer.

Vous pouvez indiquer à quel endroit il y a eu un dysfonctionnement, sans blâmer une personne ou une entité en particulier.

Le but d'un développeur est de résoudre des problèmes, vous pouvez donc prendre sur vous le fait d'avoir rencontré un problème (organisation, transmission de connaissances, etc...) de n'avoir pas trouvé de solution, et d'expliquer ce que vous auriez pu faire pour le résoudre à posteriori !