Expliquer votre propre projet quand le recruteur creuse les détails

C’est votre projet. Vous avez écrit l’essentiel du code, vous avez corrigé le pire bug à deux heures du matin, et personne dans la pièce ne le connaît mieux que vous. Alors quand le recruteur demande pourquoi le cache est invalidé de cette façon, c’est un choc d’entendre une réponse qui semblait évidente se défaire au milieu de la phrase.

Les psychologues ont mesuré cet écart, et savoir comment il fonctionne aide beaucoup à s’y préparer.

Pourquoi votre propre travail est difficile à expliquer

Dans une série d’études connue, Leonid Rozenblit et Frank Keil ont demandé à des étudiants de troisième cycle de Yale de noter, sur une échelle de sept points, à quel point ils comprenaient des objets du quotidien comme une fermeture éclair, une chasse d’eau, une serrure à cylindre ou un hélicoptère. Les étudiants ont rédigé une explication pas à pas du fonctionnement de chacun et noté à nouveau leur compréhension. Les notes ont baissé. Elles ont baissé encore après une question de diagnostic qui demandait une vraie connaissance du mécanisme, par exemple comment crocheter une serrure à cylindre. Quand les étudiants ont enfin lu l’explication d’un expert et repensé à ce qu’ils savaient auparavant, les notes sont restées basses. Leur première impression de compréhension était tout simplement trop haute (Rozenblit et Keil, 2002).

Les auteurs appellent cela l’illusion de profondeur explicative. Elle était bien plus forte pour les explications que pour les faits, les procédures ou les histoires, et les raisons qu’ils avancent s’appliquent presque trop bien à un projet logiciel. Pendant que vous travaillez, le système est sous vos yeux, alors pouvoir vérifier quelque chose donne l’impression de le savoir. Vous comprenez le niveau supérieur et supposez les niveaux du dessous. Et vous avez rarement à expliquer le tout du début à la fin, si bien que vous ne découvrez jamais où votre explication casse.

Un entretien pose justement cette question de diagnostic.

Ce que les recruteurs creusent

Les recruteurs d’Amazon sont directs sur le manque le plus fréquent. Les candidats ne vont pas assez en profondeur. Pour chaque question, ils veulent un récit détaillé d’une situation, avec les chiffres, les personnes qui ont travaillé sur le projet et les résultats obtenus. Ils demandent aussi de décrire les actions à la première personne, car l’entretien porte sur ce que vous avez fait (recruteurs d’Amazon). L’un des principes de leadership de l’entreprise, Dive Deep, demande de rester en prise avec les détails (Amazon).

Attendez-vous à la même forme partout où vous passez un entretien. Vous donnez une vue d’ensemble courte, et le recruteur pose question après question, chacune un niveau plus bas. La vue d’ensemble est la partie facile. Vous êtes jugé sur les relances.

Une présentation en deux minutes

Ouvrez sur le problème et sur les personnes qu’il gênait, en une ou deux phrases qui incluent la contrainte qui le rendait difficile.

La recherche sur notre portail patients prenait près d’une seconde, et les demandes au support à ce sujet avaient doublé après la version du printemps.

Dites en une phrase ce dont vous étiez responsable et dans une autre ce qu’ont fait les autres. L’essentiel des deux minutes revient à deux ou trois décisions, et pour chacune nommez l’option que vous avez écartée. Une décision accompagnée d’une alternative rejetée montre du jugement. Une liste d’outils ne montre rien.

Nous aurions pu ajouter des réplicas. J’ai choisi un index précalculé parce que la partie lente était le classement, et les réplicas n’aident que pour les lectures.

Terminez par le résultat, un chiffre et ce que vous changeriez.

Le p95 est passé d’environ 800 millisecondes à moins de 200. Si c’était à refaire, je donnerais dès le départ un mécanisme de contre-pression à la tâche de reconstruction.

Arrêtez-vous là et laissez le recruteur choisir le fil.

Préparez l’échelle des relances

Quelques relances reviennent dans presque toutes les plongées dans un projet, et chacune mérite une phrase ou deux écrites avant l’entretien. Le recruteur vous demandera pourquoi vous avez choisi cette conception face à l’alternative évidente, quel a été le bug le plus difficile et comment vous l’avez trouvé, comment vous saviez que cela fonctionnait et ce que vous avez mesuré. Il vous demandera aussi ce qui se passe quand une dépendance tombe, qu’une tâche redémarre à mi-chemin ou que l’entrée devient dix fois plus grande, quelles parties vous avez écrites, décidées ou relues vous-même, et ce que vous feriez autrement.

Le test de Rozenblit et Keil fonctionne tout aussi bien sur vous-même. Prenez le parcours central du projet, une requête ou une tâche du début à la fin, et écrivez-le pas à pas sans ouvrir le code. Ajoutez une question de diagnostic à son sujet, par exemple ce qui se passe si le service redémarre au milieu, et répondez-y. Chaque endroit où vous hésitez est une relance qui vous attend. Ouvrez le code, comblez le manque et écrivez la réponse sous forme d’une phrase que vous pourriez dire à voix haute.

Les erreurs qui coulent de bons projets

L’erreur la plus fréquente consiste à citer des technologies là où il faudrait décrire des décisions. React, Node, Postgres et Redis ne disent rien au recruteur sur votre façon de penser. Juste derrière vient le fait de parler au nom de toute l’équipe du début à la fin, alors que vous êtes là pour parler de votre partie. Beaucoup de présentations ne citent aucun chiffre. Latence, utilisateurs, argent, temps gagné ou taux d’erreur, un seul suffit. Certains candidats revendiquent plus qu’ils n’ont fait, et la question suivante descend d’un niveau. D’autres expliquent chaque composant. Choisissez les deux qui portaient les décisions les plus intéressantes et gardez le reste pour les questions.

Laissez les fichiers faire une partie du travail

Nous avons construit Prepped en partie pour cela. Ajoutez le dossier du projet ou le dépôt GitHub à un entretien dans Prepped, et sa préparation lit les fichiers et rédige des réponses aux questions qu’on vous posera probablement sur le code, en citant le fichier d’où vient chaque réponse. Ce que les fichiers n’étayent pas est signalé, pour que vous sachiez quoi vérifier. La banque de questions propose aussi une structure de projet, avec le problème, votre rôle, les décisions clés et le résultat, pour répéter la présentation jusqu’à ce qu’elle tienne en deux minutes.