Huit questions d’entretien, décodées

« Parlez-moi d’un projet qui s’est mal passé »

Ce qui est mesuré : votre capacité à décrire un échec sans le minimiser ni jouer la contrition. Le travail de déploiement échoue de façon visible et devant des clients, et quelqu’un qui ne peut pas en parler calmement sera un poids dans une pièce.

Comment les bons candidats échouent : en choisissant un échec imputable à quelqu’un d’autre, ou si mineur que rien n’était en jeu. Choisissez-en un où votre jugement était faux, dites ce que vous croyiez à l’époque et pourquoi c’était raisonnable, puis ce que vous feriez autrement. C’est la part « raisonnable à l’époque » qui distingue une leçon apprise d’une leçon répétée.

« Un client dit que le système ne marche pas. Que faites-vous ? »

Ce qui est mesuré : si votre premier geste est de défendre ou de comprendre. La question est un piège pour les ingénieurs, dont le réflexe est d’établir si l’affirmation est vraie.

La réponse qui porte commence par prendre la phrase au sérieux assez longtemps pour découvrir à quoi elle renvoie. « Ne marche pas » désigne presque toujours quelque chose de précis, et le précis se corrige. Les candidats qui commencent par expliquer que le système fonctionne correctement ont techniquement raison et ont raté la question.

« Expliquez comment vous obtiendriez l’accès aux données d’un client »

Ce qui est mesuré : si vous l’avez déjà fait. La question semble procédurale et se révèle la plus discriminante de la boucle, parce que la vraie réponse est ingrate d’une façon que seule l’expérience produit.

Les réponses faibles décrivent une demande adressée à la DSI. Les bonnes parlent de trouver qui détient réellement le système plutôt que qui en est nominalement responsable, de ce qu’on fait pendant qu’une validation dort dans une file, et du fait que celui qui peut aider est souvent jeune et sans obligation de le faire. Quiconque a mené un déploiement décrira l’attente, parce que l’attente est le sujet.

« Le client veut une fonctionnalité qui ne l’aidera pas »

Ce qui est mesuré : votre capacité à refuser sans abîmer la relation, et votre assurance suffisante pour essayer.

Deux façons d’échouer, et les examinateurs guettent les deux. La construire parce que le client l’a demandée est la plus courante, et c’est ainsi qu’un projet de six semaines en devient un de six mois. Refuser sèchement est plus rare et coûte la confiance sur laquelle le projet repose. La réponse qui fonctionne passe généralement par comprendre pourquoi il la veut, la demande étant souvent le substitut de quelque chose de réel et de moins coûteux à régler.

« Comment décidez-vous par quoi commencer ? »

Ce qui est mesuré : si vous séquencez selon ce qui débloque la décision suivante plutôt que selon ce qui est techniquement fondamental.

Les ingénieurs répondent instinctivement par l’architecture : la couche de données, puis la logique, puis l’interface. Dans un déploiement, la meilleure séquence met souvent quelque chose d’imparfait devant un utilisateur rapidement, parce que sa réaction contient une information qu’aucune planification ne produit. Le dire, et savoir dire quand ce serait le mauvais choix, est une réponse forte.

« Le projet bloque pour des raisons hors de votre contrôle »

Ce qui est mesuré : si vous devenez passif. On pose cette question parce que c’est la façon la plus courante dont un déploiement meurt discrètement, et parce que la passivité est un comportement parfaitement raisonnable qui se trouve être fatal ici.

La réponse attendue est un exemple concret de la plus petite chose qui pouvait encore avancer. Écrire la transformation contre un ancien export pendant que l’accès est en attente. Mener les conversations d’adoption plus tôt. N’importe quoi qui fasse que la semaine ait produit quelque chose. Les candidats qui décrivent une escalade et une attente ont décrit le bon processus et le mauvais réflexe.

« Décrivez un système que vous avez construit pour un seul utilisateur »

Ce qui est mesuré : votre aisance avec un travail qui ne se généralise pas, seul et unique grand ajustement pour un ingénieur produit.

Les examinateurs écoutent si vous vous en excusez. Un candidat qui décrit une solution codée en dur puis explique spontanément comment il aurait fallu la construire proprement annonce qu’il passera son premier déploiement à construire la version générale. La bonne réponse assume la spécificité comme le bon choix et dit comment la décision a été prise.

« Pourquoi ce métier plutôt que l’ingénierie produit ? »

Ce qui est mesuré : si vous savez ce que vous choisissez, et si vous le voudrez encore au quatrième mois, la nouveauté passée.

La réponse qui ne marche pas est que vous aimez travailler avec les gens, que tous les candidats donnent. Celle qui marche est précise sur l’échange : nommer ce que vous abandonnez, la revue par les pairs, l’accumulation, ou la profondeur sur une technologie, et dire pourquoi l’échange en vaut la peine à vos yeux. On recrute le candidat qui a déjà réfléchi au coût.

Ce que la boucle mesure vraiment

Lues ensemble, ces questions forment une seule évaluation : cette personne peut-elle être seule dans une pièce à nous représenter, face à un client mécontent, et prendre une décision que nous assumerions. Chaque épreuve technique établit un socle. Tout le reste est cette question unique, posée de huit façons.

La conséquence pratique est que la préparation ne consiste pas à répéter des réponses. Elle consiste à disposer de deux ou trois projets réels dont vous puissiez parler en détail, y compris ce qui s’est mal passé, qui était difficile, et ce que vous avez décidé sans autorisation. Les candidats qui arrivent avec cette matière franchissent des boucles pour lesquelles ils étaient techniquement sous-dimensionnés. Ceux qui ne l’ont pas échouent à des boucles pour lesquelles ils étaient surdimensionnés, ce qui est le cas le plus fréquent et le plus frustrant.