Recruter un ingénieur senior par une revue de conception

Un entretien de revue de conception pour un ingénieur senior consiste à examiner une proposition technique fournie, à hiérarchiser les modifications nécessaires et à expliquer comment avancer concrètement. Donnez les mêmes exigences à chaque candidat et évaluez son raisonnement selon des critères annoncés. Ce qui vous renseigne, c’est sa capacité à relier une décision à ses conséquences.

Ce format correspond à une responsabilité précise : examiner la proposition d’un autre ingénieur avant que l’équipe s’engage. Vous disposez ainsi d’un sujet concret, sans demander au candidat d’inventer un système entier ni d’apporter des documents confidentiels d’un ancien employeur.

Le guide de Michael Lynch pour rédiger un document de conception logicielle efficace a suscité une nouvelle discussion sur Hacker News cette semaine. Dans cet article de juin 2026, il défend des documents centrés sur les décisions lourdes de conséquences, avec un effort proportionné au travail envisagé. Cela suggère une question utile en entretien : cette personne sait-elle repérer les décisions à examiner en priorité ?

L’exercice ci-dessous est un exemple original et fictif à adapter. Les durées, les données du scénario et la grille de notation sont des suggestions éditoriales, pas un test de recrutement validé. Nous ne formulons aucune affirmation sur sa précision prédictive ni sur les résultats des recrutements.

Partez des responsabilités de conception du poste

Utilisez une revue de conception si l’examen de propositions fait partie du travail réel. Le seul intitulé « senior » ne dit pas si la personne devra évaluer des contrôles d’accès, des chaînes de traitement de données, des interactions d’interface ou des changements d’infrastructure.

Rédigez une phrase avec le responsable du recrutement : « Cet ingénieur examinera les modifications proposées pour la partie serveur de notre application destinée aux clients et aidera l’équipe à décider ce qui peut être mis en production. » Précisez ensuite les décisions qu’il devra savoir prendre dès son arrivée et le contexte que vous comptez lui enseigner.

Les recommandations de l’Office of Personnel Management américain sur l’analyse des postes relient les décisions de sélection aux tâches réelles et aux compétences nécessaires pour les accomplir. Appliquez ce principe au poste concerné. S’il porte surtout sur le développement d’interfaces produit, remplacez l’exercice d’export côté serveur, même si vos évaluateurs aiment parler de files d’attente.

De même, les recommandations de l’OPM sur les échantillons de travail précisent que les compétences évaluées doivent être celles attendues dès l’entrée en poste. Ne faites pas de la connaissance d’une convention interne une condition de réussite implicite si vous prévoyez de l’enseigner après le recrutement.

Traduisez cette responsabilité en critères observables avant d’inviter qui que ce soit. Notre guide pour définir le profil du candidat idéal peut vous y aider. Limitez suffisamment l’exercice pour qu’un évaluateur puisse expliquer à quelle partie du poste annoncé correspond chaque critère.

Fournissez un dossier complet aux candidats

Donnez le contexte nécessaire pour construire une réponse argumentée. Le dossier doit présenter l’objectif, les contraintes, l’approche proposée, la réponse attendue et les conditions de réalisation.

Pour un premier essai, vous pouvez proposer 30 minutes de préparation et 30 minutes d’échange. Ce sont des durées à tester avec des collègues, pas des temps d’exécution mesurés. Si le dossier demande davantage de travail que ce que vous annoncez, raccourcissez-le avant de le soumettre à des candidats.

Précisez que de brèves notes suffisent et que vous ne noterez ni la présentation des diapositives, ni la qualité rédactionnelle, ni le nombre de commentaires. Proposez une version texte accessible. Expliquez comment demander un aménagement du format ou de la durée et indiquez une personne à contacter en cas de question.

Énoncez les règles concernant la documentation, la recherche sur le Web, l’assistance par IA et la collaboration. Si un outil précis est obligatoire, donnez-y accès. Un échange peut faire apparaître d’autres éléments du raisonnement ; il ne prouve pas qui a produit la réponse et n’empêche pas de bénéficier d’une aide extérieure.

Utilisez des données synthétiques et une proposition fictive. Ne demandez pas les documents de conception internes d’un ancien employeur et n’utilisez pas l’exercice pour faire résoudre les problèmes en attente dans votre produit. Pour les décisions concernant l’effort demandé, la rémunération et la communication, consultez notre article sur la structuration des exercices de code.

Essayez cette proposition fictive d’export de données clients

Demandez au candidat d’examiner une proposition délimitée plutôt que de concevoir une plateforme d’export à partir de zéro. Tout le contenu de cette section doit figurer dans le dossier, y compris les contraintes qui permettent de défendre des réponses différentes.

Le contexte fourni

Votre entreprise fictive exploite une application professionnelle. Chaque organisation cliente possède ses propres données. Les administrateurs clients autorisés souhaitent exporter les données de leur organisation dans un fichier CSV, un format texte qu’ils peuvent ouvrir dans un tableur.

La première version doit respecter les exigences et contraintes suivantes :

• Un administrateur peut demander un export des données de son organisation.
• Le fichier contient des informations privées sur les clients. Être connecté ne suffit pas à autoriser l’accès aux données de toutes les organisations.
• Le plus gros client actuel possède 200 000 lignes de données. Vous n’avez mesuré ni le temps de génération de l’export ni le pic d’utilisation de la mémoire.
• Les clients acceptent d’attendre jusqu’à dix minutes avant que le fichier soit prêt. Ils n’ont pas besoin d’exports programmés dans la première version.
• L’application dispose déjà de processus de traitement en arrière-plan et d’un stockage privé de fichiers.
• Deux ingénieurs ont une semaine pour réaliser la première version. Ils peuvent en réduire le périmètre initial s’ils en expliquent les conséquences pour les clients.
• L’équipe n’a pas défini la durée de conservation des fichiers ni ce qui se passe lorsqu’un administrateur perd son accès après avoir demandé un export.

Ces chiffres définissent le scénario inventé. Ils ne constituent pas des recommandations sur la taille de votre application, vos engagements de livraison ou vos effectifs.

La proposition à examiner

Ajoutez un bouton Exporter au tableau de bord client. Le navigateur envoie un identifiant d’organisation à un nouveau point d’accès. Celui-ci vérifie que le demandeur est connecté, charge les données de cette organisation, crée le CSV et le transfère vers le stockage de fichiers avant de renvoyer une URL de téléchargement.

Enregistrez l’URL dans le profil de l’utilisateur pour que le tableau de bord affiche son dernier export. L’URL reste valide indéfiniment. Si la requête dépasse le délai autorisé, affichez une erreur et demandez à l’utilisateur de cliquer à nouveau sur Exporter.

Incluez tous les champs disponibles pour éviter les demandes ultérieures. Ajoutez un test montrant qu’un utilisateur connecté reçoit un lien de téléchargement. Après le lancement, ajoutez les exports récurrents et un outil de création d’exports configurable.

La proposition est volontairement incomplète. Dites-le explicitement aux candidats. Vous leur demandez de l’améliorer, pas de deviner si l’évaluateur la considère secrètement comme déjà correcte.

La réponse attendue

Demandez quatre éléments :

1. Identifiez les trois modifications à traiter en priorité avant cette première version. Expliquez à quelle conséquence chacune répond.
2. Recommandez une approche de livraison compatible avec les contraintes fournies. Précisez ce que vous laisseriez de côté.
3. Citez une question en suspens dont la réponse pourrait modifier votre recommandation.
4. Décrivez les éléments que vous souhaiteriez obtenir avant d’approuver la modification, notamment les tests ou les mesures.

Aucune implémentation n’est demandée. Les candidats peuvent utiliser un schéma, une liste ou un court document. Ils peuvent formuler explicitement des hypothèses, mais ne doivent pas modifier discrètement une exigence fournie pour l’adapter à leur architecture préférée.

Cherchez des priorités ancrées dans la proposition

Une revue utile distingue ce qui bloque la livraison d’une question, d’une amélioration ou d’un travail futur. Repérer douze problèmes n’est pas nécessairement plus convaincant qu’en identifier trois aux conséquences importantes et proposer une réponse cohérente.

Dans ce dossier, l’accès pose un problème concret. La proposition fait confiance à un identifiant d’organisation envoyé par le navigateur et ne décrit qu’une vérification de connexion. Le candidat doit relier cette lacune à l’exigence selon laquelle les administrateurs n’accèdent qu’aux données de leur organisation. « Ajouter de la sécurité » renseigne moins qu’une explication des endroits où vérifier les autorisations.

La génération du fichier pendant la requête Web mérite aussi un examen. Le nombre de lignes fourni et l’absence de mesures ne prouvent pas que la génération synchrone échouera. En revanche, la proposition n’établit pas qu’elle peut aboutir de manière fiable dans les limites de la requête. Observez si le candidat distingue un problème constaté d’un risque qui demande des éléments de preuve.

Le lien sans expiration et l’absence de règle en cas de perte d’accès révèlent une décision produit manquante. Une bonne revue peut soulever la question de savoir qui doit pouvoir télécharger un fichier terminé et pendant combien de temps. Elle ne doit pas inventer une règle de conservation et présenter cette préférence comme une exigence déjà fournie dans le dossier.

Les recommandations de Google sur la revue de code invitent à examiner la conception, le fonctionnement, les cas limites et la complexité, y compris le travail superflu consacré à d’éventuels besoins futurs. Ces points sont pertinents ici. Ces recommandations portent sur les revues techniques, pas sur la validité de cet exercice de recrutement.

Dans ce cas, l’outil de création d’exports configurable peut attendre : il n’est pas demandé pour la première version. Un candidat qui consacre la revue à le concevoir doit expliquer pourquoi ce sujet mérite du temps avant les questions d’accès et de livraison déjà posées.

Acceptez plusieurs plans de livraison défendables

Notez l’adéquation entre le plan et les contraintes, pas sa conformité à votre implémentation préférée. Consignez des solutions plausibles avant les entretiens pour éviter que les évaluateurs transforment une préférence implicite en exigence.

Un candidat peut proposer une génération en arrière-plan avec les processus existants, un suivi de chaque demande d’export, un stockage privé et une route de téléchargement avec vérification des autorisations. Il peut expliquer le traitement des demandes répétées, la manière d’informer l’utilisateur quand le fichier est prêt ou en cas d’échec, et les mesures qui permettront de vérifier l’objectif de dix minutes.

Un autre peut d’abord proposer une version plus limitée, réservée aux clients en dessous d’un seuil de taille explicite, puis mesurer la génération avant de décider quelle part du travail doit passer en arrière-plan. Cette réponse doit reconnaître une limite : elle ne sert pas encore le plus gros client. Le candidat doit demander un accord sur cette réduction de périmètre plutôt que prétendre satisfaire l’exigence initiale.

Les deux plans nécessitent les vérifications d’accès appropriées et une décision explicite sur l’accès aux fichiers dans le temps. Une implémentation plus simple n’excuse pas l’oubli d’exigences. Une implémentation plus élaborée ne mérite pas de points supplémentaires simplement parce qu’elle comporte davantage de composants.

Comparez les raisonnements. Le candidat explique-t-il ce qui peut mal se passer, qui s’en apercevrait et quels éléments pourraient modifier la décision ? Précise-t-il le coût de sa propre recommandation ? Ces observations sont plus utiles qu’un décompte de termes d’architecture.

Vous pouvez aussi consigner un désaccord argumenté. Si un candidat conteste l’objectif de dix minutes ou le délai d’une semaine, demandez ce qu’il dirait au responsable produit et quelle alternative il proposerait. Remettre en question une contrainte n’est pas la même chose que l’oublier.

Gardez les mêmes questions centrales pour l’échange

Préparez la discussion avant de lire la réponse du candidat. Conservez des questions centrales identiques, tout en posant des questions de clarification pour comprendre le raisonnement effectivement présenté.

Les recommandations de l’OPM sur les entretiens structurés décrivent des questions prédéfinies et des règles communes de notation. Pour cet exercice, vous pouvez appliquer ce principe avec un court guide d’échange :

• Quel problème traiteriez-vous en premier, et pourquoi avant les autres ?
• Qu’est-ce qui vous ferait choisir une autre approche de livraison ?
• Où votre plan dépend-il d’informations que nous n’avons pas fournies ?
• Que demanderiez-vous à un autre spécialiste d’examiner ?

Donnez ensuite la même information supplémentaire à chaque candidat : « L’équipe produit confirme que les administrateurs qui perdent leur accès ne doivent plus pouvoir télécharger les exports déjà générés. » Demandez ce que cela change dans son plan et ce qu’il faut tester.

Prévenez les candidats que l’échange inclura une exigence supplémentaire. Il s’agit de leur permettre de réviser une décision, pas de les piéger pour observer leur réaction. Notez s’ils expliquent un changement, identifient une protection existante ou demandent davantage d’informations.

N’improvisez pas des scénarios de plus en plus difficiles pour les candidats qui vous impressionnent. Si vous soumettez une panne régionale à une personne et un changement de formulation à une autre, les notes obtenues décrivent des exercices différents.

Appuyez les notes sur vos observations

Définissez la signification de chaque note avant le bilan collectif. Un critère doit produire une observation qu’un autre évaluateur peut examiner, plutôt qu’une étiquette comme « posture senior ».

Le tableau ci-dessous est une base de travail. Adaptez les dimensions au poste et testez les repères de notation. La mention « éléments insuffisants pour juger » doit rester disponible lorsque l’exercice ou l’échange ne permet pas de conclure.

Une observation peut être : « A identifié la nécessité d’une vérification des autorisations pour l’identifiant d’organisation ; a demandé un test avec un administrateur d’une autre organisation. » Une autre : « A recommandé une file d’attente, sans la relier à la durée de la requête ni expliquer la gestion des échecs. »

Séparez ces observations de la décision finale de recrutement. Un exercice ne porte que sur une partie du poste. Il ne permet pas de conclure sur les capacités de programmation, toutes les compétences de collaboration ou l’aptitude à assumer chaque responsabilité senior. Notre guide des grilles d’évaluation structurées explique comment organiser les critères sur l’ensemble du processus.

Harmonisez les pratiques des évaluateurs avant les entretiens

Vérifiez que les évaluateurs comprennent le dossier et appliquent les repères de notation de manière cohérente. Faites réaliser l’exercice à des collègues, relevez le temps réellement consacré et notez leurs réponses séparément avant d’en discuter.

En cas de désaccord, examinez-en la cause. Un évaluateur a-t-il récompensé la mention d’un service précis ? Un autre a-t-il supposé une exigence absente du dossier ? La réponse était-elle ambiguë, ou le descriptif de la note trop général ? Corrigez l’exercice ou le guide avant que les candidats rencontrent le même problème.

Conservez la version du dossier et du guide d’échange utilisée pour chaque évaluation. Si vous modifiez les exigences entre deux entretiens, consignez le changement et demandez-vous si les notes précédentes restent comparables. N’améliorez pas discrètement les consignes au milieu d’une campagne de recrutement.

Demandez aux participants à l’essai où le contexte leur a manqué et quelles consignes leur ont fait perdre du temps. Supprimez le travail qui ne contribue à aucun critère annoncé. Cet essai aide à améliorer le déroulement de l’évaluation ; il ne prouve ni sa validité prédictive ni son absence de biais.

Choisissez des évaluateurs qui comprennent les décisions examinées. Si l’exercice devient une épreuve spécialisée en sécurité, faites intervenir un évaluateur compétent et annoncez cette exigence, ou réduisez le périmètre. Le responsable du recrutement doit veiller à la cohérence entre le poste, l’exercice et le jury.

Organisez l’étape de revue de conception dans Kit

Reliez le sujet, les critères et les observations des évaluateurs à l’étape du candidat. L’équipe de recrutement reste responsable de la pertinence de l’exercice et des conclusions qu’elle tire des éléments recueillis.

Dans Kit, placez le document fourni dans le sujet privé d’une mise en situation et recueillez la critique écrite du candidat sous forme de fichier ou de lien. Affectez des évaluateurs et des critères de notation, puis programmez la discussion dans une étape Entretien. Les critères peuvent comporter des descriptions, des pondérations et des échelles ; votre équipe rédige la grille.

Pendant un tour d’évaluation actif, les évaluateurs remettent leur propre évaluation avant de voir celles de leurs collègues. Cela organise l’ordre des contributions ; cela ne garantit ni l’équité ni la justesse des avis. Kit ne fournit pas de test de revue de conception validé et ne juge pas automatiquement une architecture.

Finalisez le sujet de la mise en situation et la grille avant d’inviter les candidats : les conditions de l’évaluation se figent lorsque le premier candidat atteint cette étape. Si vous configurez une rémunération, Kit suit la demande de paiement ; votre équipe envoie l’argent.

Partez d’une responsabilité, d’une proposition fournie et d’une courte liste de décisions que le candidat doit pouvoir expliquer. Testez l’exercice avec les évaluateurs, corrigez les passages confus et annoncez précisément aux candidats le travail demandé.