Conception système et les scénarios lead classiques

Format un : concevoir un système pour testeurs

Vous aurez des prompts comme « concevez un système de gestion des données de test » ou « concevez un exécuteur de tests distribué ». Répondez à n'importe lequel de la même façon calme : clarifiez ce qu'il faut, esquissez les composants, nommez les compromis. Personne n'attend la perfection — on veut voir comment vous pensez.

Dit simplement, les pièces sont :

• Une file de shards qui découpe la suite en morceaux.
• Un pool de workers parallèles qui tirent chacun un morceau.
• Un environnement isolé par worker — ses propres données de test ensemencées, pour que les exécutions ne se marchent pas dessus.
• Un agrégateur de résultats qui rassemble tout en un seul tableau de bord.

Le compromis à proposer avant qu'on ne le demande est vitesse vs isolation vs coût :

• Plus de workers finissent plus tôt mais coûtent plus.
• Partager les données entre workers est moins cher mais cause des collisions inter-tests — la source classique d'instabilité.
• Une base de données séparée par worker donne une isolation propre mais ajoute du temps de setup et de teardown.

Format deux : le scénario comportemental

Ceux-là testent le tempérament. Répondez avec structure, jamais avec du blâme :

1. « Un bug critique s'est échappé en production. » D'abord restaurez le service — c'est votre MTTR qui tourne. Puis faites un post-mortem sans blâme qui demande pourquoi le filet l'a raté. Puis ajoutez un test de régression pour qu'il ne puisse pas revenir. Rapportez-le comme un point de donnée d'échec de changement, pas une chasse aux sorcières.
2. « Les développeurs résistent à écrire des tests. » Rendez la bonne chose la chose facile : des tests rapides, de bonnes fixtures, des tests branchés dans le gate de PR pour que ce soit routinier plutôt qu'héroïque.
3. « L'automatisation est plus lente que notre sprint. » C'est une odeur de pyramide — trop de tests E2E lents. Poussez les vérifications vers le bas, exécutez-les en parallèle, et déplacez la suite lente en nocturne.

Avancé — où chaque réponse devrait atterrir

Quel que soit le format, terminez sur les deux mêmes mots : résultats et personnes. Pas « j'ajouterais plus de tests » mais « voici le résultat que ça protège, et voici comment l'équipe reste entière pendant qu'on y arrive ». C'est la note qui se lit comme du niveau lead.

Basé sur le cadrage MTTR / réponse aux incidents de DORA (dora.dev) et l'architecture standard de test distribué