« J’ai dû réapprendre à coder pour passer le cap des nouveaux entretiens »

Je ne suis pas un étudiant à la recherche d’un premier job. Je travaille depuis 15 ans comme développeur et stratégiste dans de grandes banques d’investissement et je cherche un nouveau poste.

C’est un cauchemar.

Ces dernières années, les entreprises recrutant des développeurs ont adopté toutes sortes de processus de tests afin de se couvrir en préalable à toute décision de recrutement. Être en mesure de prouver ses références ne suffit plus : il faut maintenant passer par un test Hackerrand ou autre du même acabit. C’est devenu courant dans le secteur bancaire, mais les entreprises tech s’y mettent aussi : Facebook utilise maintenant directement des entretiens techniques de 45 mn en vidéo plutôt que de vrais tests de codage pour ses recrues potentielles.

J’ai donc passé ces derniers mois à réviser la programmation en Python, C++ et SQL. J’ai démarré de zéro pour apprendre C#/dot net et je suis me suis replongé dans les cours de maths de l’école. Mes compétences techniques étaient déjà très solides. Elles se sont considérablement améliorées.

Mais voilà, tout cela prend du temps, et je suis convaincu que c’est du temps sagement investi. Tout ce que j’ai fait a été d’apprendre comment résoudre certains problèmes (si vous restez suffisamment longtemps sur Hackkerrank, vous constaterez que ce sont toujours les mêmes qui reviennent). Avec un peu de chance, cela me permettra de décrocher un job, mais si je suis recruté sur cette base, je pense que ce sera pour de mauvaises raisons.

Par le passé, alors que je faisais moi-même passer des entretiens, je trouvais chaque fois beaucoup de candidats brillants. De temps à autre pourtant, je tombais sur quelqu’un d’exceptionnel, capable d’aborder les problèmes différemment, et invariablement, ces candidats s’avéraient toujours être les meilleures recrues. Dans ce nouveau système, ils auraient été éliminés lors du filtrage.

L’entraînement aux questions de type Hackerrand a clairement contribué à renforcer mes compétences techniques, mais je crois que les entreprises qui utilisent ces tests faussent la donne en faveur des candidats qui a) ont le temps de s’entraîner et b) sortent tout juste de l’école et ont l’habitude de genre de format. Il est très difficile de se préparer à ces tests en travaillant à plein temps quand on a une famille. Ces tests constituent aussi une bonne occasion de se dédouaner d’une forme de jeunisme. Lors d’une évaluation l’autre jour, on m’a demandé de coder quelque chose que je n’avais pas vu depuis 30 ans. Si j’avais eu la possibilité de potasser le sujet, je m’en serais bien sorti.

Les jeunes non plus ne sont pas avantagés par ces tests. Pour réussir dans ce processus d’évaluation, il vous faut utiliser la programmation défensive sur des cas particuliers. D’abord visualiser comment résoudre le problème, puis trouver une solution qui fonctionne, mais pour proposer les meilleurs résultats, votre solution doit s’exécuter efficacement et produire la bonne réponse dans tous les cas de figure (p. ex. la répétition de paramètres vides ou des nombres négatifs, des volumes de données énormes) ; ils ont généralement des tests cachés auxquels ils procèdent pour vérifier. Les tests consistent donc avant tout à exclure des candidat plutôt qu’à identifier les jeunes aussi brillants que non-conformistes présentant un fort potentiel.

Ce serait bien de laisser tomber ces tests. Mais cela paraît peu probable. Pour l’instant donc, l’expérience semble compter pour du beurre : tout dépend combien de temps vous pouvez passer sur Leetcode.

Thomas Jackson est un pseudonyme.