Questions d'entretien Senior Ingénieur Data

Ce qui est attendu au niveau Senior

On attend de l'architecture de plateforme/entrepôt, de la fiabilité et la responsabilité de la gouvernance.

Exemples de questions d'entretien pour Ingénieur Data

• ProgrammationÉcrivez une requête SQL pour trouver le deuxième salaire le plus élevé par département.
  Ce qu'une bonne réponse couvre

  • Utilisation de DENSE_RANK pour gérer les ex-aequo
  • Sous-requête ou CTE pour filtrer le rang 2
  • Partitionnement par département
  • Ordre décroissant sur salaire
  • Piège: ROW_NUMBER vs DENSE_RANK pour ex-aequo

  Voir un exemple de réponse

  Pour trouver le deuxième salaire le plus élevé par département, il faut gérer les ex-aequo. On utilise DENSE_RANK() partitionné par département et ordonné par salaire décroissant. On filtre ensuite sur rank = 2. Une alternative avec ROW_NUMBER ne fonctionnerait pas en cas d'ex-aequo. La requête ci-dessous utilise une CTE propre. La complexité est O(n log n) due au tri, mais c'est acceptable pour des volumes raisonnables. Attention : si un département a moins de deux employés, la requête ne renverra rien pour ce département. On peut aussi utiliser un LAG ou une sous-requête corrélée, mais DENSE_RANK reste la plus lisible.

  WITH ranked_salaries AS (
    SELECT
      department_id,
      salary,
      DENSE_RANK() OVER (PARTITION BY department_id ORDER BY salary DESC) AS rank
    FROM employees
  )
  SELECT department_id, salary
  FROM ranked_salaries
  WHERE rank = 2;

• TechniqueExpliquez la différence entre ETL et ELT et quand utiliser chacun.
  Ce qu'une bonne réponse couvre

  • ETL : transformation avant chargement
  • ELT : chargement avant transformation, exploite puissance DB/Data Lake
  • ETL adapté aux sources complexes et volumes modérés
  • ELT adapté au big data et données brutes
  • Latence, coût de stockage, maintenabilité

  Voir un exemple de réponse

  ETL (Extract, Transform, Load) transforme les données avant de les charger dans la cible, ce qui réduit le volume stocké mais nécessite un serveur ETL puissant. ELT (Extract, Load, Transform) charge d'abord les données brutes dans un Data Lake ou un entrepôt, puis applique les transformations (souvent en SQL) dans le système cible. On choisit ETL quand la source est complexe (ERP avec jointures lourdes) ou quand la cible est un entrepôt classique avec peu de puissance de calcul. On choisit ELT pour le Big Data (par ex. Spark ou Snowflake) car on exploite la scalabilité du stockage et du calcul. Un piège courant est de forcer l'ELT dans un système où les transformations sont trop coûteuses en écriture de tables temporaires. L'ETL offre un meilleur contrôle de la qualité en amont, l'ELT permet plus de flexibilité d'exploration.

• TechniqueComment concevriez-vous un pipeline idempotent que l'on peut réexécuter en toute sécurité ?
  Ce qu'une bonne réponse couvre

  • Déterminisme : mêmes entrées = mêmes sorties
  • Utilisation d'ID de partition et de checkpoint
  • Opérations UPSERT (MERGE) au lieu d'INSERT
  • Horodatage de batch et déduplication
  • Mécanisme de compensation ou de rollback

  Voir un exemple de réponse

  Pour un pipeline idempotent, chaque réexécution doit produire exactement le même état final si les données sources sont identiques. On y parvient en : (1) rendant les opérations déterministes, par exemple en triant les données avant traitement ; (2) utilisant des identifiants de batch uniques et stockant le dernier checkpoint (offset Kafka, date de snapshot) ; (3) écrivant en mode UPSERT (MERGE) ou INSERT avec déduplication via une clé primaire ; (4) enregistrant des marqueurs de succès dans une table de métadonnées pour éviter de re-traiter un batch déjà finalisé. Par exemple, un pipeline Spark Streaming peut utiliser .checkpointLocation() pour sauvegarder l'état. Un piège fréquent est d'utiliser des fonctions non déterministes (comme rand() ou now()) dans la logique de transformation. En cas d'échec, le redémarrage doit reprendre exactement là où il s'est arrêté sans duplication ni perte.

• TechniqueComment gérez-vous les données arrivant en retard dans un pipeline de streaming ?
  Ce qu'une bonne réponse couvre

  • Fenêtres de temps : event-time vs processing-time
  • Watermarking pour gérer le flou temporel
  • Stockage des événements en attente (late data buffer)
  • Politiques : ignorer, join différée, correction par batch
  • Outils : Watermarks dans Flink/Spark, late data firing

  Voir un exemple de réponse

  Dans un pipeline streaming, les données en retard arrivent après la fenêtre de temps attendue. Pour les gérer, on utilise l'event-time (horodatage de l'événement) plutôt que le processing-time. On définit un watermark qui indique jusqu'à quel temps les données sont considérées complètes. Par exemple dans Apache Flink, le watermark est une heuristique : tant que les événements sont dans la tolérance (ex: 10 minutes de retard), on les intègre à la fenêtre en cours. Sinon, on peut les envoyer dans un flux de données tardives pour un traitement asynchrone (batch de correction). Une autre approche consiste à relancer le calcul des agrégats une fois que les données tardives arrivent (ex: via un pipeline de réconciliation). Le piège est de bloquer le output en attendant les données tardives – mieux vaut émettre des résultats provisoires puis les mettre à jour. En pratique, pour une appli temps réel, on fixe un seuil de retard au-delà duquel on ignore les événements ou on les stocke pour analyse offline.

• ProgrammationUtilisez des fonctions de fenêtrage pour calculer une moyenne glissante sur 7 jours.
  Ce qu'une bonne réponse couvre

  • ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
  • PARTITION BY pour agréger par groupe
  • Ordre temporel (timestamp)
  • Moyenne mobile simple
  • Gestion des premières lignes (moins de 7 jours)

  Voir un exemple de réponse

  Pour calculer une moyenne glissante sur 7 jours, on utilise la clause ROWS BETWEEN 6 PRECEDING AND CURRENT ROW dans une fonction de fenêtrage. Il faut s'assurer que les données sont ordonnées par date et éventuellement partitionnées par catégorie. La requête ci-dessous calcule la moyenne des ventes des 7 derniers jours (y compris le jour courant). Attention : si les données ne sont pas quotidiennes, il faut ajuster l'intervalle (par ex. RANGE BETWEEN INTERVAL 6 DAYS PRECEDING AND CURRENT ROW en SQL supportant les intervalles). Le piège est que ROWS compte les lignes physiques, pas les jours – si un jour manque, la moyenne peut être faussée. On peut utiliser RANGE avec INTERVAL pour une fenêtre temporelle exacte.

  SELECT
    date,
    sales,
    AVG(sales) OVER (
      ORDER BY date
      ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
    ) AS moving_avg_7_days
  FROM daily_sales;

• Conception de systèmesConcevez un entrepôt de données pour l'analytique d'une entreprise de e-commerce.
  Ce qu'une bonne réponse couvre

  • Modélisation en étoile / flocon
  • Tables de faits : ventes, commandes, clics
  • Dimensions : temps, produit, client, magasin
  • Granularité et clés de substitution
  • Scalabilité : partitionnement, colonnes compressées (Parquet)

  Voir un exemple de réponse

  Pour un entrepôt de données e-commerce, on utilise typiquement un schéma en étoile. La table de fait centrale est 'Ventes' avec des mesures comme montant, quantité, remise, et des clés étrangères vers les dimensions : Temps (jour, mois, année), Produit (catégorie, prix, fournisseur), Client (segmentation, localisation), Magasin (entrepôt, région). On peut ajouter une dimension 'Achat' pour les attributs de la transaction (mode de paiement, promo). La granularité la plus fine est la ligne de commande. Pour les clics et navigation, on crée une table de fait 'Événements' avec mesure de comptage. On dimensionne via partitionnement par date (ex: par mois) et l'utilisation de formats colonnes comme Parquet. On gère les SCD de type 2 pour les dimensions changeantes (ex: adresse client). Un piège est de négliger les dimensions dégénérées (ex: numéro de commande). L'architecture peut être un Data Lake house (Databricks, Snowflake) pour combiner flexibilité et performance.

• ComportementalParlez-moi d'un problème de qualité de données que vous avez détecté et corrigé.
  Ce qu'une bonne réponse couvre

  • Problème concret : doublons d'ID client
  • Détection via analyse de distribution et tests d'unicité
  • Méthode : jointure de tables et agrégation
  • Correction : déduplication par date la plus récente
  • Mesure d'impact : métriques erronées de chiffre d'affaires

  Voir un exemple de réponse

  Dans un précédent projet e-commerce, j'ai détecté un problème de qualité de données où des ID clients étaient dupliqués en raison d'un bug dans le système CRM. Les clients effectuaient des achats, mais un nouvel ID leur était attribué après chaque connexion. J'ai écrit une requête SQL pour regrouper par email et compter les ID distincts, ce qui a révélé plus de 5% de clients avec des doublons. L'impact était une sous-estimation des clients fidèles et une surévaluation du nombre total de clients. J'ai corrigé en implémentant un pipeline de déduplication qui gardait la dernière version de chaque client (basée sur la date de modification), et j'ai mis à jour les tables de faits en référençant le bon ID. Ensuite, j'ai ajouté une contrainte d'unicité sur l'email dans la source et des alertes de monitoring sur les variations hebdomadaires du nombre de nouveaux ID. Le projet a duré deux semaines et a restauré la confiance dans les rapports marketing.

• ComportementalComment priorisez-vous la fiabilité des pipelines face aux nouvelles demandes ?
  Ce qu'une bonne réponse couvre

  • Cadre SLA / SLO pour définir les priorités
  • Impact métier : perte de données vs time-to-insight
  • Compromis : investissement dans la fiabilité vs fonctionnalités
  • Processus d'évaluation : analyse d'impact et coût
  • Itération : améliorer la fiabilité en continu via des rétrospectives

  Voir un exemple de réponse

  Pour prioriser la fiabilité des pipelines face aux nouvelles demandes, j'utilise un cadre basé sur l'impact métier. D'abord, je définis des SLA clairs pour chaque pipeline (latence, exactitude, disponibilité). Une nouvelle demande est évaluée selon son urgence, mais je refuse de sacrifier les SLA existants. Je quantifie le risque : une perte de données client est prioritaire sur un rapport mensuel. Je mets en place un système de tickets pondérés : plus une défaillance coûte cher, plus sa correction est prioritaire. Les nouvelles demandes passent dans un backlog que l'on priorise avec le product owner. Je consacre systématiquement 20% du temps de l'équipe à la maintenance et à la fiabilité. Par exemple, récemment nous avons rejeté une demande de dashboard rapide car le pipeline sous-jacent avait besoin d'alertes de qualité. Nous avons convenu de déployer d'abord le monitoring, ce qui a évité une future perte de confiance. Le piège est de toujours dire oui : il faut avoir le courage de dire non et de proposer des alternatives.

Ce que les recruteurs évaluent

Comment se préparer

• Affûtez votre SQL — les fonctions de fenêtrage et l'optimisation reviennent dans presque chaque processus.
• Pour la conception de pipelines, commencez par l'idempotence, les reprises et les backfills.
• Évoquez de façon proactive la qualité des données et la traçabilité ; cela signale une maturité de production.

Questions fréquentes