Questions d'Entretien pour Ingénieur de Données : SQL, Pipelines et Fiabilité sous Pression

La boucle d'entretien pour ce rôle se construit autour d'une préoccupation centrale : pouvez-vous déplacer et transformer les données correctement à l'échelle sans que quelqu'un n'ait besoin de la surveiller. Cela se manifeste comme quatre domaines de compétences connectés : SQL et modélisation des données, conception de pipelines dans les modèles ETL et ELT, fiabilité en cas d'échec, et le jugement pour communiquer les compromis aux personnes qui ne codent pas.

La plupart des boucles mélangent un tour de SQL pratique, un tour de conception de systèmes axé sur un pipeline ou une plate-forme de données, et un tour comportemental qui explore comment vous gérez les données corrompues, les exigences manquantes et les désaccords avec les data scientists ou les analystes. Certaines entreprises exécutent également un exercice à emporter où vous construisez un petit pipeline à partir d'un ensemble de données brutes, ce qui teste les mêmes compétences sans public en direct.

Les recruteurs ne notent pas seulement si votre requête retourne les bonnes lignes. Ils écoutent comment vous narrez votre raisonnement : pourquoi vous avez choisi une fonction de fenêtre au lieu d'une auto-jointure, pourquoi vous avez choisi un chargement incrémental au lieu d'une actualisation complète, pourquoi vous alerteriez sur la dérive du nombre de lignes au lieu de seulement compter les valeurs nulles. Un candidat qui marmonne à travers une réponse correcte perd souvent contre celui qui explique une réponse légèrement plus brute clairement.

Avant votre entretien, établissez une courte liste de pipelines, de tables ou d'incidents de votre propre travail que vous pouvez décrire en deux ou trois phrases chacun. Vous les utiliserez constamment dans les tours SQL, conception et comportement.

SQL est toujours la porte la plus courante dans les entretiens d'ingénierie des données, même dans les entreprises qui fonctionnent principalement sur Spark ou dbt. Attendez-vous à des invites comme : écrivez une requête qui retourne la commande la plus récente de chaque client, trouvez des lacunes dans une séquence de dates par compte, calculez un total de sept jours glissants des revenus quotidiens, ou dédupliquez les lignes sans perdre la version la plus récente.

Les fonctions de fenêtre apparaissent constamment. ROW_NUMBER() avec une clause PARTITION BY est l'outil standard pour les problèmes de "derniers enregistrements par clé"; LAG() et LEAD() gèrent les questions de brèche-île et de détection de changement; SUM() OVER une fenêtre ordonnée gère les totaux glissants sans une auto-jointure. Les recruteurs veulent également que vous raisonniez à voix haute sur un plan de requête : quel ordre de jointure l'optimiseur pourrait choisir, où un index aiderait, et quand une requête est lente à cause d'un filtre de partition manquant plutôt que d'une mauvaise jointure.

Les questions de modélisation des données testent un muscle différent : conception de schéma sous des contraintes conflictuelles. Une invite commune consiste à concevoir un schéma en étoile pour un ensemble de données de commerce électronique ou d'abonnement, avec des tables de faits pour les commandes ou les événements et des tables de dimensions pour les clients, les produits et le temps. Soyez prêt à expliquer les dimensions qui changent lentement : quand une mise à jour de type 1 (remplacer) convient par rapport à quand vous avez besoin du type 2 (nouvelle ligne, dates d'effet) pour préserver l'historique pour une métrique comme "segment de client au moment de l'achat."

Vous devriez également être capable de justifier les compromis de normalisation. Les systèmes OLTP favorisent les tables normalisées pour protéger la cohérence des écritures; les entrepôts d'analyse dénormalisent souvent délibérément pour qu'un outil BI puisse interroger une large table au lieu de cinq jointures. Nommer ce compromis, plutôt que de traiter un style comme universellement correct, c'est ce qui sépare une réponse solide d'une réponse de manuel.

Les questions de conception de pipeline vous demandent de décrire comment les données brutes deviennent une table digne de confiance. Une invite typique : concevoir un pipeline qui ingère des événements de flux de clics et produit une table d'utilisateurs actifs quotidiens que l'équipe produit peut interroger chaque matin. Une réponse solide commence par la source, pas l'outil : d'où proviennent les données, à quelle fréquence arrivent-elles, quelle est la latence acceptable, et que se passe-t-il si un lot est tardif ou un flux s'arrête?

Attendez-vous à comparer explicitement ETL et ELT. Dans ETL, vous transformez les données avant de les charger dans l'entrepôt, ce qui convient aux volumes plus petits ou aux besoins stricts de conformité. Dans ELT, vous chargez d'abord les données brutes et les transformez dans l'entrepôt avec un outil comme dbt, ce qui est maintenant le modèle plus courant car la computeude l'entrepôt est bon marché et elle conserve l'historique brut pour le retraitement. Soyez capable d'expliquer pourquoi vous choisiriez l'un plutôt que l'autre pour une source de données donnée.

Les questions d'orchestration testent si vous pensez à l'échec, pas seulement au chemin heureux. Les recruteurs veulent entendre parler des DAG dans un outil comme Airflow ou Dagster, des tentatives au niveau des tâches, des remplissages pour un schéma qui a changé au milieu de l'historique, et des charges incrementales qui ne traitent que les lignes nouvelles ou modifiées au lieu de retraiter une table entière à chaque exécution. L'idempotence est un suivi préféré : si une tâche échoue à mi-parcours et est relancée, produit-elle des lignes dupliquées ou le même résultat correct?

Les questions spécifiques au streaming apparaissent davantage dans les entreprises ayant des exigences en temps réel. On peut vous demander de comparer un pipeline de streaming basé sur Kafka avec une approche de micro-lot, ou d'expliquer la sémantique de livraison exactement-une-fois par rapport à au-moins-une-fois et quelle stratégie de déduplication vous utiliseriez en aval quand un système ne garantit que au-moins-une-fois.

Les questions de fiabilité dans les questions d'entretien pour ingénieur de données commencent généralement par un scénario : un tableau de bord affiche zéro revenu ce matin, expliquez-moi comment vous le débogueriez. Une bonne réponse remonte en arrière à travers le pipeline dans l'ordre plutôt que de deviner au hasard. Vérifiez que le système source a réellement produit des données, vérifiez les journaux du travail d'ingestion et les décomptes de lignes, vérifiez la couche de transformation pour une exécution échouée ou silencieusement ignorée, et vérifiez si le tableau de bord lui-même pointe vers une table obsolète ou un cache.

Les vérifications de qualité des données sont un sujet fréquent en elles-mêmes. Les recruteurs veulent des détails : des vérifications du taux de nullité sur les champs obligatoires, détection d'anomalies du nombre de lignes par rapport à une ligne de base historique, vérifications de fraîcheur qui alertent quand une table n'a pas été mise à jour dans sa fenêtre attendue, et vérifications référentielles qui détectent les clés étrangères orphelines après un changement de schéma en amont. Des outils comme les tests dbt ou Great Expectations apparaissent souvent, mais nommer un outil importe moins que d'expliquer ce que vous vérifieriez réellement et pourquoi cette vérification détecte le mode d'échec qui vous préoccupe.

Vous devriez également attendre des questions sur les SLA et SLO pour la fraîcheur des données, et comment vous conceVriez les alertes pour que la bonne personne soit alertée pour un vrai problème sans noyer l'équipe dans le bruit de variance attendue. Parlez de la façon dont vous définiriez les seuils, achemineriez les alertes par gravité, et éviteriez une alerte qui se déclenche chaque jour et est ignorée.

Un fil conducteur lié est la rétrospective : décrivez un incident où des données incorrectes ont atteint un rapport ou un modèle avant que quelqu'un ne l'attrape. Les recruteurs écoutent la propriété et le changement de processus, pas le blâme. Une réponse solide nomme la cause racine, la correction immédiate, et la protection spécifique que vous avez ajoutée après, comme une nouvelle vérification de validation ou un changement dans la façon dont les remplissages sont révisés.

Les questions comportementales pour les ingénieurs de données se concentrent moins sur les exploits individuels et plus sur la façon dont vous gérez les demandes concurrentes des personnes qui dépendent de vos pipelines. Les invites communes incluent : parlez-moi d'une fois où une partie prenante avait besoin de données plus rapidement que votre pipeline ne pouvait les fournir; parlez-moi d'un désaccord avec un data scientist ou un analyste sur un schéma ou une définition de métrique; parlez-moi d'une fois où vous avez trouvé une erreur dans les données de production après qu'elle ait déjà été utilisée dans un rapport.

Utilisez STAR, mais gardez la section action spécifique au travail de données. Pour l'histoire "des données déjà utilisées dans un mauvais rapport", expliquez comment vous avez découvert l'erreur, à qui vous l'avez dit et à quelle vitesse, comment vous avez corrigé les chiffres en aval, et quelle validation vous avez ajoutée pour que la même classe d'erreur ne puisse pas se glisser à nouveau. Les recruteurs veulent voir que vous traitez les incidents de données de la même façon qu'un ingénieur logiciel traite une panne de production, pas comme un désagrément mineur.

Pour les désaccords sur le schéma ou la métrique, montrez que vous pouvez maintenir une position technique tout en arrivant à une décision que l'équipe peut accepter. Expliquez le compromis que vous défendiez, comme la performance des requêtes par rapport au coût de stockage, ou un schéma plus strict par rapport à un intégration plus rapide d'une nouvelle source de données, et comment vous l'avez résolu sans simplement annuler l'autre personne.

Les questions de priorisation sont également courantes : comment décidez-vous entre corriger un pipeline instable, construire une nouvelle source de données qu'une partie prenante attend, et rembourser la dette technique dans un ancien modèle. Une réponse crédible pèse l'impact commercial, le rayon d'impact si le pipeline instable échoue à nouveau, et combien de temps l'équipe peut tolérer la dette avant qu'elle ralentisse tous les changements futurs.

Ces questions sont plus faciles à répondre sur papier qu'à haute voix. Expliquer une fonction de fenêtre, une conception de pipeline, ou une rétrospective d'incident en phrases parlées claires est une compétence différente de l'écriture du SQL correct ou du dessin du bon DAG, et les recruteurs notent l'explication autant que la réponse.

Pratiquez la narration de solutions SQL avant de toucher un clavier : énoncez l'approche, nommez la fonction de fenêtre ou la stratégie de jointure que vous utiliserez, puis écrivez la requête. Pour les invites de conception de pipeline, pratiquez à parler à travers la source, les exigences de latence, la logique de transformation, et la gestion des défaillances dans cet ordre à chaque fois, pour que la structure devienne automatique sous pression. Pour les histoires comportementales, répétez jusqu'à ce que le détail technique reste spécifique sans devenir un monologue.

Enregistrez-vous répondant à quelques-unes de ces questions et écoutez à nouveau pour les mots de remplissage, la configuration qui se ramifie avant d'arriver au point, ou les étapes omises dans une visite du pipeline. SayNow AI peut vous aider à pratiquer les questions d'entretien pour ingénieur de données à haute voix, avec des commentaires sur la clarté et le tempo pour que votre raisonnement technique se communique avec autant de confiance qu'il se lit sur la page.