Entretien de pair programming : à quoi s'attendre et comment se préparer

Si vous vous êtes surtout préparé avec des puzzles d'algorithmique, un entretien de pair programming peut sembler déroutant. Cette section explique en quoi il diffère et comment cela change votre préparation. En résumé, vous êtes évalué comme un futur coéquipier, pas comme quelqu'un qui résout des puzzles.

La session se déroule généralement de l'une de ces trois façons : un éditeur partagé dans le navigateur, votre propre IDE pendant que vous partagez votre écran, ou le prolongement d'un projet à faire chez soi que vous avez déjà réalisé. La tâche ressemble souvent au travail quotidien, comme ajouter une règle de validation, corriger un test qui échoue, ou refactoriser une fonction. Certaines entreprises font échanger les rôles, si bien que vous passez une partie de la session comme « driver » qui tape le code et une autre comme « navigator » qui guide.

• Questions de clarification. Si vous confirmez le besoin et ce que « terminé » signifie avant d'écrire du code.
• Penser à voix haute. Si votre binôme peut suivre votre raisonnement sans avoir à demander.
• Progression incrémentale. De petites étapes fonctionnelles plutôt qu'un seul gros changement à la fin.
• Les tests. Si vous écrivez ou lancez un test pour prouver que le changement fonctionne.
• La lecture de code. À quelle vitesse vous vous repérez dans du code que vous n'avez pas écrit.
• La prise en compte des retours. Comment vous réagissez à un indice ou à une idée différente de votre binôme.

Les autres formats de test de code, y compris le tableau blanc, le projet à faire chez soi et les entretiens d'algorithmique en direct, sont comparés dans le guide des types d'entretiens.

Un ingénieur backend qui passait un entretien pour un poste intermédiaire dans une startup de logistique a dû ajouter une règle de remise à un module de commande existant. Avant de taper, il a demandé si les remises pouvaient se cumuler et ce qui devait se passer pour les commandes déjà en cours. Il a lu les tests existants, écrit un test qui échoue pour la nouvelle règle, l'a fait passer avec le changement le plus simple possible, puis a demandé à son binôme si la règle devait aller dans la classe de tarification ou dans un objet de politique séparé. Quand le recruteur a suggéré une approche différente, il l'a essayée et a expliqué le compromis. Il n'a pas terminé l'exigence bonus, mais le retour est quand même resté centré sur la facilité de travailler avec lui.

Ce déroulé — clarifier, tester d'abord, faire de petits changements et discuter de la conception — est exactement ce que la plupart des entretiens de pair programming cherchent à observer.

Faites du pair programming avec un ami sur une petite tâche dans un dépôt que vous ne connaissez pas, et entraînez-vous à commenter à voix haute pendant que vous avancez. Préparez votre environnement à l'avance si vous utilisez votre propre IDE : le projet doit se compiler et les tests doivent passer avant le début de l'appel. L'outil d'entretien simulé aide pour les parties conversationnelles, comme expliquer un choix de conception ou un projet passé.

Soyez réaliste sur les outils en direct ici. Le pair programming repose beaucoup sur le partage d'écran, et tout ce que vous partagez est visible par votre binôme ; votre recruteur vous regarde aussi coder en temps réel. SubcueAI transcrit le recruteur et rédige des pistes de réponse pendant les parties discussion d'un entretien vidéo, depuis l'application de bureau ou l'extension de navigateur, sans bot dans l'appel. Le code lui-même reste entièrement à votre charge, et les environnements surveillés et les appareils gérés par l'entreprise ne sont pas pris en charge. Les détails d'installation se trouvent sur la page tutoriel.