Sur FastAPI à fort trafic, la concurrence, les tests et la limitation sont corrects. Sur les microservices et Kafka, le format évolue par champs optionnels avec un registre. Sur les analytics temps réel, les fenêtres et l'exactitude sont maîtrisées. Sur les profils dans MongoDB, la croissance de l'historique est la vraie faiblesse. Sur l'API de recommandation, la préparation à l'avance joue le rôle de repli. L'usage de l'IA est encadré.
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)
· Alice Prevost · 14/10/2026
Synthèse
La candidate transpose avec méthode son expérience de chaînes de données vers une API à fort trafic : tout ce qui coûte est préparé à l'avance. Son code asynchrone est testé avec pytest, y compris le cas d'un appel trop lent. Elle reconnaît ne pas savoir gérer la croissance d'un historique dans MongoDB.
Détail par exigence
FastAPI à fort trafic
indispensableSolide
Prépare tout ce qui coûte à l'avance, parallélise avec un délai maximum, teste le cas lent et limite chaque client par clé.
Microservices communiquant par Kafka
indispensableSolide
Publie des événements partitionnés par profil, regroupe les consommateurs par service et fait évoluer le schéma par ajouts.
Analytics temps réel
Solide
Agrège par minute dans Redis, consolide chaque heure et distingue l'affichage du reporting.
Profils utilisateurs dans MongoDB
Solide
Place les derniers visionnages dans le profil mais ne sait pas gérer l'historique complet qui grossit.
API de recommandation
Solide
Sert des résultats préparés en avance, ce qui joue le rôle de repli si le moteur tarde.
Usage de l'IA
indispensableSolide
Utilise l'assistant pour les requêtes et les squelettes, compare à ses propres requêtes et garde les données et la structure des tables.
Points d'appui
Sépare ce qui répond vite de ce qui est préparé à l'avance.
Teste le cas d'un appel lent avec des faux services et un délai choisi.
Limitation par clé avec 429, journal des dépassements et prévenance des partenaires.
Comparaison d'une requête générée avec celle qu'elle écrit elle-même sur un échantillon.
Points de vigilance
Historique qui grossit dans MongoDB : seuil et migration inconnus.
Pratique de MongoDB limitée, elle vient de PostgreSQL.
Pas de cas vécu sur un trafic à grande échelle.
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
Alice sait préparer à l'avance ce qui coûte cher pour qu'une API réponde vite, et teste même le cas où un appel est trop lent. Elle connaît bien les messages entre services. Elle ne sait pas encore gérer un historique qui grossit dans MongoDB.
Ses points forts
Prépare à l'avance les calculs coûteux
Teste les cas lents
Compare les requêtes générées par l'assistant aux siennes
À creuser en entretien
Historique qui grossit dans MongoDB
Peu de pratique du fort trafic
Savoir-être
Structurer sa réponse
Sépare ce qui répond vite de ce qui peut attendre.
Renforcerait l'équipe sur les tests et l'ingestion, avec un besoin d'appui sur MongoDB.
Détail par exigence
FastAPI à fort trafic
indispensableSolide · 7,5/10
Appels concurrents avec asyncio · 8/10Appels concurrents avec délai maximum.J'utilise asyncio.gather avec un client httpx asynchroneRéponse
R2
Nombre de workers Uvicorn · 8/10Réglage par la mesure.Je commencerais avec un nombre égal aux coeurs disponibles, puis je mesureraisRéponse
R3
Limiter un client trop bavard · 7/10Limitation par client.Je limite par clé d'API, avec un compteur dans RedisRéponse
R4
Mettre en cache une réponse de recommandation · 7/10Réponse servie depuis un cache.tout ce qui coûte est préparé en avance et servi depuis RedisRéponse
R1
Microservices communiquant par Kafka
indispensableSolide · 7,3/10
Produire un événement de visionnage · 7/10Événement complet.un identifiant d'événement, un horodatage et les identifiants du profil et du contenuRéponse
R5
Faire évoluer le format d'un événement · 7/10Évolution contrôlée.j'ajoute seulement des champs optionnels, et je documente le schéma dans un registreRéponse
R5
Groupes de consommateurs · 8/10Groupes par service.Les consommateurs sont regroupés par serviceRéponse
R5
Analytics temps réel
Solide · 7/10
Compteurs de vues dans Redis · 7/10Compteurs par fenêtre.Des incréments Redis par minuteRéponse
R7
Agrégation par fenêtre de temps · 7/10Consolidation horaire.un job qui consolide dans PostgreSQL toutes les heuresRéponse
R7
Exactitude ou rapidité des chiffres · 7/10Exactitude pour le reporting.Pour des chiffres de reporting, je recalcule depuis les événementsRéponse
R7
Profils utilisateurs dans MongoDB
Solide · 7/10
Index pour les requêtes fréquentes · 7/10Index de base.avec un index sur l'identifiantRéponse
R6
Historique qui grossit sans fin · 7/10Point faible reconnu.je ne saurais pas dire à partir de quelle tailleRéponse
R6
API de recommandation
Solide · 8/10
Réponse de repli si le moteur tarde · 8/10Aucun calcul lourd à la demande.l'API ne lit que des tables prêtesRéponse
R1
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 · 8/10Tâches déléguées.Copilot pour les requêtes SQL et les squelettes de tâches AirflowRéponse
R8
Comment il relit, teste et corrige le code que l'assistant produit · 7/10Contrôle par comparaison.Je compare toujours le résultat d'une requête générée à celui d'une requête que j'écris moi-mêmeRéponse
R8
Ce qu'il ne confie jamais à l'assistant : données confidentielles, sécurité, décisions d'architecture, cas où il s'est trompé · 7/10Limite sur les données.Je ne lui montre jamais de vraies données de ventesRéponse
R8