Questions d’entretien pour Data Engineer

Le recruteur cherche d’abord des preuves de maîtrise : comment vous structurez un pipeline data (ingestion, transformation, serving) et comment vous sécurisez les exécutions. Une bonne réponse cite généralement des outils concrets comme Airflow pour l’orchestration, dbt pour la modélisation et Great Expectations pour la qualité, ainsi que des indicateurs mesurables (latence, taux d’échec, SLA). Vous gagnez aussi en crédibilité quand vous expliquez votre approche d’idempotence et de déduplication, car c’est la base d’une fiabilité industrielle. Enfin, vous devez montrer que vos décisions sont motivées par des contraintes opérationnelles, par exemple le coût de rerun, la gestion des incidents et la capacité à diagnostiquer en moins d’une heure.

Sur la partie architecture, l’objectif n’est pas de “tout faire” mais de choisir le bon modèle selon le besoin métier. Vous devez parler explicitement de latence, de tolérance à l’erreur et de complexité de traitement, en reliant ces points à des exemples typiques (reporting, ML features, alerting temps réel). Pour le batch, attendez-vous à mentionner Spark batch, des modèles dbt et une exécution orchestrée via Airflow avec retries maîtrisés. Pour le streaming, évoquez Kafka comme source d’événements et un moteur de traitement comme Spark Structured Streaming ou Flink, avec event-time, watermarks et gestion du backpressure. Le recruteur attend souvent une réponse hybride réaliste, où le batch assure la correction et le streaming l’actualité, afin de maintenir un SLA élevé à coût maîtrisé.

Quand on vous demande d’investiguer des données incorrectes, la valeur de votre réponse dépend de votre méthode de diagnostic structurée. Le recruteur veut voir comment vous reproduisez l’écart, comment vous remontez la chaîne causale (serving → transformation dbt → ingestion Airflow/Spark/Kafka) et comment vous identifiez la cause racine. Mentionner des mécanismes concrets comme les tests dbt (unique/not null/relationships) et des checklists Great Expectations rassure immédiatement. Ensuite, vous devez proposer une correction sécurisée : un backfill ciblé, une stratégie de rollback et un plan de non-régression avec nouveaux tests. Enfin, vous gagnez des points en liant votre réponse à des KPI : taux de rejet, latence par étape, et fréquence de changements de schéma qui impactent la production.

Pour la dette technique, le recruteur attend une approche “système”, pas seulement des intentions. Vous devez montrer comment vous mesurez le problème : incidents Airflow, temps de traitement Spark, couverture de tests dbt, et indicateurs de qualité des données. Une réponse convaincante inclut un mécanisme de priorisation fondé sur l’impact et le risque, avec une allocation explicite (par exemple 20% de capacité) pour stabiliser les pipelines. Vous pouvez aussi citer des pratiques de gouvernance : code review obligatoire, conventions de nommage, documentation et seuils d’alerte. L’idée est de prouver que vous réduisez le taux d’échec et améliorez le SLA sans bloquer les releases, en traitant la dette comme un investissement de fiabilité et de réduction de coûts d’exploitation.