Entretiens de pair programming : ce qu'on évalue quand vous n'êtes pas seul
On suppose par défaut qu'on vous observe. En réalité, on travaille avec vous, et presque tout ce qui marque des points découle de cette nuance.
L'erreur qui coûte le plus cher
La plupart arrivent en supposant que l'examinateur est un juge qui se trouve dans la pièce : il faudrait donc jouer la compétence et ne laisser voir aucune lacune. Sous cette hypothèse, on ne pose pas de questions, car demander ressemble à ne pas savoir. Et on ne réfléchit pas à voix haute, car une idée à moitié formée paraît mal dégrossie.
C'est exactement l'inverse. Dans un tour de pair programming, l'examinateur est un collègue pendant quarante minutes, et ce qu'on mesure, c'est ce que ça fait de travailler avec vous. Votre silence n'est pas du sang-froid : c'est quelqu'un avec qui il est difficile de coder à deux.
Servez-vous de lui, à voix haute
Une session à deux vous donne ce qu'un tour en solo n'a pas : un second cerveau qui connaît déjà la réponse. Ceux qui en tirent parti font trois choses, encore et encore.
Ils vérifient les hypothèses avant de construire dessus. « Je pars du principe que ces identifiants sont uniques — c'est sûr ? » Dix secondes, et vingt minutes dans la mauvaise direction évitées.
Ils proposent un choix au lieu de deviner. « Je peux le faire avec un dictionnaire ou en triant d'abord. Le tri se lit plus facilement, le dictionnaire est plus rapide. Qu'est-ce qui compte le plus ici ? » Ce n'est pas de l'indécision : c'est ainsi que le travail se fait réellement.
Et ils acceptent les indices sans discuter. Quand quelqu'un demande « et si la liste est vide ? », la réponse n'est pas une défense. C'est « bien vu » et une clause de garde.
Taper n'est pas le travail
Un schéma classique : le candidat tape sans interruption pendant trente minutes, produit quelque chose qui marche presque, et reçoit un retour négatif. L'examinateur n'a pas pu suivre le raisonnement, il ne restait donc à évaluer que le résultat — et le résultat était incomplet.
Le schéma inverse marque mieux : moins de code, plus de narration, des points de contrôle fréquents. « Voilà, le chemin principal est couvert. Avant d'aller plus loin — je traite les entrées mal formées, ou le cas nominal suffit pour l'instant ? »
Cette question fait un vrai travail. Elle montre que vous connaissez le cas, elle respecte l'horloge, et elle fait de l'examinateur un participant aux décisions de périmètre plutôt qu'un spectateur.
Quand vous n'êtes pas d'accord
Ça arrive : l'examinateur propose quelque chose que vous jugez faux. Les deux extrêmes perdent. Obtempérer en silence se lit comme une absence d'avis. S'arc-bouter se lit comme quelqu'un d'épuisant en équipe.
Le bon geste est de rendre le désaccord concret et bon marché. « Je pense que ça casse si l'entrée est déjà triée — je peux l'essayer sur ce cas ? » C'est devenu une expérience de deux minutes au lieu d'une dispute, et quel que soit celui qui a raison, vous avez montré comment vous réglez un désaccord technique. Ce qui est à peu près la question réellement posée.
Les cinq dernières minutes
La plupart passent la dernière ligne droite à taper plus vite, en espérant finir. Ne pas finir est normal et rarement fatal ; ne pas expliquer l'est davantage.
Meilleur usage du temps : arrêtez-vous et dites où vous en êtes. « Ça marche pour le cas standard. Avec dix minutes de plus, je traiterais les doublons, en gardant ici un ensemble des éléments déjà vus. »
Vous venez de montrer que vous savez ce qui manque et comment vous le termineriez — ce qui est l'essentiel de ce que finir aurait prouvé de toute façon.
Ce qu'ils notent
Dans ces tours, l'examinateur évalue en général selon une grille courte, et il y est rarement question de l'algorithme. Les items récurrents sont la communication, la collaboration, la gestion du retour et le débogage sous pression.
Communiquer n'est pas être disert. C'est que la personne qui regarde puisse prédire votre coup suivant. Si elle le peut, vous êtes lisible ; sinon, tout ce que vous faites a l'air d'une devinette, même quand ça n'en est pas une.
La gestion du retour est ce que les candidats sous-estiment le plus. L'examinateur vous interrompra au moins une fois, souvent avec quelque chose que vous saviez déjà. Ce qui est noté, c'est si l'interruption vous a mis sur la défensive, et à quelle vitesse la conversation est revenue au travail.
Le débogage est la partie qu'ils espèrent voir
Un tour à deux comporte presque toujours un moment où le code ne fait pas ce que vous attendiez. Ce moment n'est pas un accroc dans l'entretien — c'est souvent son objet.
La version faible consiste à changer des choses jusqu'à ce que la sortie ait l'air correcte. La version forte consiste à formuler une hypothèse avant de toucher à quoi que ce soit : « Le compteur est trop haut de un, et la boucle va de zéro à n inclus — je pense que c'est la borne. Je vérifie avec n égal à un. »
Dites l'hypothèse, puis testez-la. Deux phrases, et vous avez montré une méthode plutôt qu'un réflexe.
Mettre en place les deux premières minutes
Avant d'écrire quoi que ce soit, faites trois choses à voix haute : reformulez le problème, confirmez la forme de l'entrée, et dites ce que vous allez faire en premier. Quatre-vingt-dix secondes, et le ton de toute la session change.
Cela donne aussi à l'examinateur une occasion précoce de vous réorienter. Il le fera en général si vous le laissez faire — et une correction à la deuxième minute est gratuite, alors que la même à la vingtième vous coûte le tour.
Si l'énoncé est ambigu, cette ambiguïté est en général voulue. Poser la question n'est pas un retard : c'est la première chose évaluée.
Où un copilote s'insère
Interview Copilot suit le tour en temps réel et affiche une structure sur votre écran pendant que l'autre personne parle encore : ce que la question demande vraiment, la contrainte qui compte, et le compromis qui mérite d'être dit à voix haute. Pas un script à lire : un échafaudage depuis lequel vous parlez avec vos propres mots.
FAQ
Qu'est-ce qu'un entretien de pair programming ?
Un tour où vous construisez quelque chose aux côtés de l'examinateur plutôt que d'être observé en train de résoudre une énigme. Il peut écrire du code lui aussi, suggérer des directions ou jouer un coéquipier. Ce qui est évalué, c'est la collaboration : expliquez-vous, écoutez-vous, êtes-vous en désaccord de façon utile, intégrez-vous ce qu'on vous apporte.
Qu'évalue-t-on vraiment dans un tour de pair programming ?
Si travailler avec vous est productif. Concrètement : énoncez-vous votre intention, utilisez-vous ce que votre binôme propose, objectez-vous avec une raison plutôt que de céder ou d'ignorer, et votre code reste-t-il compréhensible pour quelqu'un d'autre en temps réel.
Dois-je contredire l'examinateur si je le pense dans l'erreur ?
Oui, avec une raison et une proposition. « Ça marche, mais ça fait un parcours supplémentaire de la liste — on peut le faire en une seule passe ? » est la réponse recherchée. Obtempérer en silence et passer outre en silence sont tous deux mal notés.
Combien devrais-je taper ?
Moins que vous ne le pensez. Ce qui est évalué n'est pas la frappe, ce sont les décisions. De longues plages de frappe silencieuse ne produisent aucune preuve : commentez au fil de l'eau ce que vous écrivez et pourquoi.