Démo Voir côté candidat

Mathieu Roussel

Développeur PHP Symfony mid, plateforme fintech (H/F) · test filmé du 20/10/2026 · 16 min
Hors document · non imprimé
Verdict À considérer
Score du test 5,3/10 couverture 100 % Usage de l’IA : 5/10 Communication : 5,3/10 · 3 critères sur 4 · non prouvé : précision du vocabulaire
Signaux à regarder Aucun signal relevé Indicatifs, non décisionnels. Ils disent où regarder dans la vidéo, pas quoi décider.
Sur cette offre 28e sur 30 testés Suivant : Audrey Colin →
Prochaine étape proposée par l’analyse

Sur Symfony et les traitements asynchrones, il comprend le besoin mais a surtout travaillé avec cron. Sur la fiabilité des flux de paiement, le raisonnement s'arrête à la transaction, ce qui laisse un risque de double débit. Sur Doctrine et PostgreSQL, la démarche par le plan d'exécution est bonne. La conception orientée domaine est abordée par la couche de domaine testée. Sur Redis, le cache est cohérent. L'usage de l'IA est encadré.
Offre : 48 000 – 56 000 € brut / an PHPSymfonyDoctrinePostgreSQLRedisRabbitMQ
La pièce à transmettre Part telle quelle chez votre client : sans score, sans verdict, sans signal.

Revelyum

Rapport d'entretien technique

Établi pour Nordlys Conseil

Développeur PHP Symfony mid, plateforme fintech (H/F) · Mathieu Roussel · 20/10/2026

Synthèse

Le candidat a une vraie culture du test et du diagnostic SQL, acquise sur une API de crédit sans framework. Il croit qu'une transaction de base de données suffit à empêcher un double versement, ce qui est le point faible de l'entretien. Il connaît Symfony peu mais en parle sans détour.

Détail par exigence

Symfony et traitements asynchrones indispensable Partiel
Voit bien l'intérêt d'une file de traitement mais a pratiqué un cron plutôt que Messenger, et reste vague sur le rejeu et les tests Symfony.
Fiabilité des flux de paiement indispensable Partiel
Compte sur la transaction de base de données pour éviter un double versement, sans verrou ni clé d'idempotence, ce qui ne suffit pas en cas de requêtes simultanées.
Doctrine et PostgreSQL indispensable Partiel
Lit un plan d'exécution et crée l'index composite adapté, sans expérience de Doctrine.
Conception orientée domaine Partiel
Isole le domaine du reste du code et le teste sans base, ce qui prépare la conception orientée domaine sans la nommer.
Redis et cache Partiel
Met en cache un calcul coûteux avec une durée de vie et le purge quand les taux changent, sans verrou distribué.
Usage de l'IA indispensable Partiel
Délègue la production de cas de test, relit et lance la suite, garde le calcul des taux hors de l'assistant.

Points d'appui

  • Suite de tests solide : domaine isolé, base jetable dans Docker, environ quatre cents tests en six minutes.
  • Index composite trouvé avec EXPLAIN, de douze secondes à moins de trois cents millisecondes.
  • Cache de simulation avec invalidation sur changement de taux.

Points de vigilance

  • Pense qu'une transaction seule protège des doubles débits, sans verrou ni clé d'idempotence.
  • Peu d'expérience de Symfony et de Doctrine.
  • Verrous distribués jamais posés en production.

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.

Afficher la transcription

Chargement…