Sur Doctrine et PostgreSQL, la démarche va du symptôme à la cause avec des mesures, et les migrations sont conçues sans coupure. Sur Symfony et les traitements asynchrones, l'idempotence et la reprise sont maîtrisées et testées. Sur la fiabilité des flux de paiement, la candidate n'a pas de pratique mais applique les bons principes (entiers, verrou court, clé d'idempotence, journal). La conception orientée domaine part des invariants. L'usage de l'IA est encadré par la relecture et la mesure.
Emilie diagnostique une régression de 80 millisecondes à trois secondes par le plan d'exécution et les statistiques de la table, puis la ramène à 12 millisecondes avec un index partiel. Elle livre ses migrations en plusieurs déploiements sur une copie de la production. Elle dit clairement qu'elle n'a pas géré de paiements et transpose avec méthode.
Détail par exigence
Symfony et traitements asynchrones
indispensableSolide
Pose une règle d'idempotence pour l'équipe, la teste en rejouant le message et organise la reprise des échecs.
Fiabilité des flux de paiement
indispensableSolide
N'a pas géré de paiements mais raisonne juste : entiers avec devise, verrou court, clé d'idempotence, journal ajouté seulement.
Doctrine et PostgreSQL
indispensableSolide
Diagnostique par le plan et les statistiques, corrige par un index partiel mesuré et migre en plusieurs déploiements.
Conception orientée domaine
Solide
Construit les agrégats autour des invariants et relie les contextes par des événements.
Redis et cache
Solide
Met en cache les données reconstructibles, invalide explicitement et connaît le risque d'un verrou qui expire.
Usage de l'IA
indispensableSolide
Confie des petites tâches avec contexte, relit tout le diff et garde ses données et ses décisions de découpage.
Points d'appui
Lecture du plan d'exécution jusqu'à la cause (statistiques périmées), avec des chiffres.
Migrations en deux déploiements, par lots, testées sur une copie de la production.
Règle d'idempotence énoncée pour toute l'équipe et testée en envoyant deux fois le message.
Franchise sur ce qu'elle n'a pas fait en paiement, suivie d'un raisonnement juste.
Points de vigilance
Aucune expérience directe des paiements ni de la réconciliation bancaire.
Une seule utilisation d'un verrou distribué.
Sujets abordés
Symfony et traitements asynchrones · Fiabilité des flux de paiement · Doctrine et PostgreSQL · Conception orientée domaine · Redis et cache · Usage de l'IA
Entretien conduit en autonomie par le candidat, réponses transcrites puis analysées.
L'évaluation finale appartient au recruteur : Revelyum n'émet aucune décision automatisée.
En clair
Oui, il peut clairement faire ce job
Emilie sait retrouver pourquoi un service devient lent et le corriger, avec des chiffres. Elle déploie ses changements de base sans interrompre le service. Elle n'a pas encore travaillé sur des paiements et le dit simplement.
Ses points forts
Résout des lenteurs avec méthode
Changements de base sans interruption
Honnête sur ses limites
À creuser en entretien
Pas d'expérience directe des paiements
Peu de pratique de certains outils avancés
Savoir-être
Structurer sa réponse
Découpe une migration en déploiements successifs et dit pourquoi.
Apporterait de la méthode à une équipe core et dit ce qu'elle ignore, ce qui rend la revue simple.
Détail par exigence
Symfony et traitements asynchrones
indispensableSolide · 9,7/10
Handlers idempotents face aux messages rejoués · 9/10Déduplication dans la transaction.chaque message porte une clé de déduplicationRéponse
R3
Tests fonctionnels d'un flux Symfony · 10/10Test qui prouve l'idempotence.Les tests fonctionnels envoient le même message deux foisRéponse
R3
Stratégie de retry et file des messages en échec · 10/10Reprise bornée et rejeu ciblé.trois tentatives avec un délai exponentielRéponse
R3
Fiabilité des flux de paiement
indispensableSolide · 9,5/10
Représenter les montants sans erreur d'arrondi · 9/10Représentation correcte, sans pratique.un entier de centimes avec sa devise dans un objet valeurRéponse
R4
Transactions et verrous contre les doubles débits · 10/10Raisonnement juste contre le double débit.un verrou pessimiste sur la ligne du compte dans une transaction courteRéponse
R4
Doctrine et PostgreSQL
indispensableSolide · 10/10
Requêtes lentes, index et plan d'exécution · 10/10Cause trouvée dans le plan.j'ai vu que Postgres ne choisissait plus l'index parce que les statistiques de la table étaient périméesRéponse
R1
Migrations de schéma sans coupure de service · 10/10Remplissage prudent pour la réplication.je remplis par lots de dix mille lignes avec une pause entre chaqueRéponse
R2
Conception orientée domaine
Solide · 9,5/10
Agrégats et invariants métier · 10/10Agrégats déduits des invariants.Je partirais des invariantsRéponse
R5
Frontières entre contextes métier · 9/10Frontière appliquée sur un cas réel.avec un contexte chacun, et ça nous a évité beaucoup de couplageRéponse
R5
Redis et cache
Solide · 10/10
Invalidation du cache · 10/10Invalidation liée à la source.une invalidation explicite quand la donnée source changeRéponse
R7
Verrous distribués · 10/10Risque identifié.le vrai risque est le verrou qui expire avant la fin du travailRéponse
R7
Usage de l'IA
indispensableSolide · 9,5/10
Son workflow avec l'assistant : découper la demande, lui donner le contexte (fichiers, conventions), tenir la taille du contexte et le coût en tokens, itérer · 9/10Demandes courtes avec contexte.Je lui demande des petites tâches avec les fichiers voisins en contexteRéponse
R6
Comment il relit, teste et corrige le code que l'assistant produit · 10/10Vérification adaptée au risque.pour une requête SQL je regarde moi-même le planRéponse
R6