Sur FastAPI à fort trafic, les réponses couvrent le dimensionnement, la concurrence et la limitation de débit. Sur les microservices communiquant par Kafka, la production, les groupes de consommateurs et l'évolution du format sont décrits avec leurs limites. Les analytics temps réel distinguent vitesse et exactitude. Les profils MongoDB et l'API de recommandation sont bien traités, sans mesure d'effet. L'usage de l'IA est encadré par la relecture.
La pièce à transmettrePart telle quelle chez votre client : sans score, sans verdict, sans signal.
Revelyum
Rapport d'entretien technique
Établi pour Nordlys Conseil
Développeur API Python, plateforme média streaming (H/F)
· Quentin Hubert · 10/10/2026
Synthèse
Quentin a construit des API d'écoute audio en FastAPI avec des consommateurs Kafka et des statistiques en temps réel dans Redis. Ses réponses donnent des mécanismes précis, comme la limitation de débit et l'évolution compatible des événements. Il reconnaît ne pas avoir mesuré l'effet des recommandations, ce qui relevait d'une autre équipe.
Détail par exigence
FastAPI à fort trafic
indispensableSolide
Dimensionne les workers à la mesure, parallélise les appels et protège l'API par une limitation de débit.
Microservices communiquant par Kafka
indispensableSolide
Publie des événements ordonnés par utilisateur et les fait évoluer sans casser les consommateurs.
Analytics temps réel
Solide
Compte en direct dans Redis, agrège dans MongoDB et accepte l'approximation à l'affichage.
Profils utilisateurs dans MongoDB
Solide
Sépare le profil de l'historique pour éviter un document qui grossit et pose les index utiles.
API de recommandation
Solide
Prévoit une réponse de repli, sans avoir mesuré l'effet des recommandations.
Usage de l'IA
indispensableSolide
Confie à l'assistant les tests et le code répétitif, relit tout et garde la facturation et l'architecture.
Points d'appui
Parallélisation des appels avec asyncio et piège de la boucle bloquée identifié.
Limitation de débit par clé dans Redis avec réponse adaptée.
Évolution des événements par ajout de champs optionnels, sans casser les anciens consommateurs.
Distinction entre chiffres rapides et chiffres facturables.
Points de vigilance
Choix du nombre de partitions fait à l'estime.
Pas de registre de schémas pour les événements.
N'a pas mesuré lui-même l'effet des recommandations.
Sujets abordés
FastAPI à fort trafic · Microservices communiquant par Kafka · Analytics temps réel · Profils utilisateurs dans MongoDB · API de recommandation · 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 faire ce job
Quentin a l'habitude des services à forte audience, où chaque lecture envoie des messages entre services. Il explique comment les chiffres d'écoute s'affichent vite et comment les chiffres facturés sont recalculés ensuite. Il dit clairement ce qu'il n'a pas mesuré.
Ses points forts
Expérience de services à forte audience
Bonne maîtrise des échanges entre services
Clarté sur ses limites
À creuser en entretien
N'a pas mesuré l'effet des recommandations
Quelques choix faits à l'estime
Savoir-être
Expliquer
Décrit un piège de la boucle bloquée avec son symptôme.
Partage ce qu'il a vu en production et dit ce qu'il aurait fait autrement.
Détail par exigence
FastAPI à fort trafic
indispensableSolide · 8/10
Nombre de workers Uvicorn · 8/10Réglage fondé sur l'observation.on ajustait à la mesureRéponse
R1
Appels concurrents avec asyncio · 8/10Appels concurrents avec délai.je lançais les appels en parallèle avec asyncio.gatherRéponse
R1
Mettre en cache une réponse de recommandation · 8/10Cache sans invalidation à gérer.une clé qui contient la version du modèleRéponse
R2
Limiter un client trop bavard · 8/10Limite de débit par client.On limitait le débit par clé d'API avec un compteur dans RedisRéponse
R2
Microservices communiquant par Kafka
indispensableSolide · 7/10
Produire un événement de visionnage · 7/10Ordre préservé par utilisateur.avec l'identifiant de l'utilisateur comme cléRéponse
R3
Groupes de consommateurs · 7/10Un groupe par besoin.un groupe de consommateurs par usageRéponse
R4
Faire évoluer le format d'un événement · 7/10Évolution compatible.on ajoutait des champs optionnels, jamais de suppressionRéponse
R4
Analytics temps réel
Solide · 7,5/10
Compteurs de vues dans Redis · 7/10Compteurs par fenêtre.incrémentait des compteurs Redis par titre et par minuteRéponse
R5
Exactitude ou rapidité des chiffres · 8/10Arbitrage assumé.la vitesse comptait plus pour l'affichageRéponse
R5
Profils utilisateurs dans MongoDB
Solide · 7,5/10
Historique qui grossit sans fin · 7/10Évite la croissance du document.l'historique dans une collection séparée pour ne pas faire grossir le document sans finRéponse
R6
Index pour les requêtes fréquentes · 8/10Index adapté à la requête.un index sur l'utilisateur et la dateRéponse
R6
API de recommandation
Solide · 7/10
Réponse de repli si le moteur tarde · 7/10Repli défini.on renvoyait une liste de titres populaires comme solution de repliRéponse
R6
Mesurer l'effet d'une recommandation · 7/10Limite reconnue.Je n'ai pas mesuré l'effet des recommandations moi-mêmeRéponse
R6
Usage de l'IA
indispensableSolide · 7,3/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 · 7/10Tâches répétitives.Je lui confie des tests, des schémas Pydantic et du code répétitifRéponse
R7
Comment il relit, teste et corrige le code que l'assistant produit · 7/10Relecture et contrôles.Je relis tout et je lance les tests et le linterRéponse
R7
Ce qu'il ne confie jamais à l'assistant : données confidentielles, sécurité, décisions d'architecture, cas où il s'est trompé · 8/10Limite claire.Je ne lui confie pas la logique de facturationRéponse
R7
Un cas vécu où un assistant IA a changé son code ou son délai, et ce qu'il en a retenu · 7/10Erreur trouvée en relecture.il avait écrit un consommateur qui n'était pas idempotentRéponse
R7