Sur la fiabilité des flux de paiement, la réconciliation, le verrouillage et les montants sont expliqués avec une pratique évidente. Sur la conception orientée domaine, les frontières et les événements sont issus d'une expérience corrigée. Sur Symfony et les traitements asynchrones, l'idempotence est testée. Sur Doctrine et PostgreSQL, le verrouillage est détaillé. Redis est utilisé simplement, et l'usage de l'IA est bordé par la lecture du plan.
Hugo explique la réconciliation bancaire avec l'image de deux cahiers pointés chaque nuit, et chaque décision humaine y est elle-même enregistrée sans effacer la ligne d'origine. Il choisit entre verrou pessimiste et optimiste selon la probabilité de conflit et a retiré une table partagée entre services après en avoir mesuré le coût. Ses réponses sont un peu longues mais précises.
Détail par exigence
Symfony et traitements asynchrones
indispensableSolide
Écrit des handlers rejouables et prouve l'absence de double mouvement par un test fonctionnel.
Fiabilité des flux de paiement
indispensableSolide
Rapproche les paiements chaque nuit, verrouille selon le risque et arrondit selon une règle écrite et testée.
Doctrine et PostgreSQL
indispensableSolide
Contrôle le plan d'exécution des requêtes générées et comprend les verrous Doctrine.
Conception orientée domaine
Solide
Définit les frontières par la propriété des données et relie les services par événements.
Redis et cache
Solide
Met en cache des référentiels rares à changer avec expiration et invalidation, sans pratique des verrous Redis.
Usage de l'IA
indispensableSolide
Confie les jeux de données et la documentation, relit tout et contrôle le plan des requêtes générées.
Points d'appui
Réconciliation expliquée à un non-spécialiste en trois cas, avec journal des décisions humaines.
Verrous Doctrine choisis selon la probabilité de conflit, transaction courte sans appel réseau.
Frontières entre services fixées par la propriété des données, erreur de table partagée corrigée.
Test fonctionnel qui envoie deux fois le même virement.
Points de vigilance
Réponses parfois longues, qui demandent une relance pour aller à l'essentiel.
Pas de pratique de Redis pour les verrous distribués.
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
Hugo explique clairement comment on s'assure qu'aucun paiement n'est perdu ou compté deux fois, avec des images simples. Il a guidé une équipe de six sur un back-office bancaire. Ses réponses sont parfois longues.
Ses points forts
Explique simplement des sujets complexes
Fiable sur le contrôle des paiements
Corrige ses erreurs de conception
À creuser en entretien
Réponses parfois un peu longues
Pas de pratique des verrous Redis
Savoir-être
Expliquer
Utilise l'image de deux cahiers pour expliquer la réconciliation.
Serait un bon relais entre l'équipe technique et les métiers, à condition d'aller droit au but.
Détail par exigence
Symfony et traitements asynchrones
indispensableSolide · 10/10
Handlers idempotents face aux messages rejoués · 10/10Idempotence transactionnelle.je garde l'identifiant du message traité dans la même transaction que l'effetRéponse
R5
Tests fonctionnels d'un flux Symfony · 10/10Test de la régression redoutée.un test fonctionnel qui envoie deux fois le même virementRéponse
R5
Fiabilité des flux de paiement
indispensableSolide · 9,8/10
Rapprocher les paiements avec les relevés bancaires · 10/10Rapprochement expliqué simplement.un traitement lit le cahier de la banque et pointe chaque ligne contre la nôtreRéponse
R1
Transactions et verrous contre les doubles débits · 10/10Verrou adapté aux comptes sollicités.avec LockMode::PESSIMISTIC_WRITE dans une transaction courteRéponse
R2
Représenter les montants sans erreur d'arrondi · 9/10Représentation correcte.Des entiers de centimes, associés à une devise dans un objet valeurRéponse
R3
Traçabilité et journal des opérations · 10/10Traçabilité des décisions.chaque décision d'un humain est elle-même enregistréeRéponse
R1
Doctrine et PostgreSQL
indispensableSolide · 10/10
Requêtes lentes, index et plan d'exécution · 10/10Habitude née d'un incident.je regarde systématiquement le planRéponse
R6
Conception orientée domaine
Solide · 9/10
Frontières entre contextes métier · 9/10Frontière nette.un service est seul à écrire dans sa baseRéponse
R4
Événements de domaine et effets de bord · 9/10Couplage par événement.publie un événement de domaine quand l'ordre est acceptéRéponse
R4
Redis et cache
Solide · 10/10
Invalidation du cache · 10/10Invalidation à la mise à jour.une invalidation quand un administrateur les met à jourRéponse
R7
Durées de vie et données périmées · 10/10Durée adaptée au référentiel.avec une expiration d'un jourRéponse
R7
Usage de l'IA
indispensableSolide · 10/10
S'il code avec un assistant IA (Copilot, Cursor, Claude Code, ChatGPT…) : quelles tâches de développement il lui confie, et lesquelles il garde · 10/10Tâches déléguées.pour écrire des jeux de données de test, pour documenterRéponse
R6
Un cas vécu où un assistant IA a changé son code ou son délai, et ce qu'il en a retenu · 10/10Cas vécu et réflexe retenu.une requête générée marchait sur mes données de test et faisait un parcours completRéponse
R6