Ce que testent vraiment les entretiens data engineer

Qui est vraiment dans la salle

Pour un poste de data engineer, vous êtes rarement évalué par un recruteur généraliste après le premier appel. Les tours techniques sont généralement menés par un data engineer senior ou le responsable data engineering, parfois avec un analytics engineer ou un data scientist présent si les pipelines que vous construiriez alimentent leurs modèles. C'est important car les questions viennent de personnes qui ont été appelées à 3h du matin pour un DAG cassé, pas d'une grille écrite par les RH. Ils écoutent pour savoir si vous avez réellement exploité un pipeline en production, pas si vous savez définir l'ETL.

Les petites entreprises condensent souvent tout en deux tours : une session technique en direct et une conversation avec la personne responsable de la plateforme data. Les plus grandes le divisent en un test SQL/Python, un tour de conception système ou pipeline, et un tour valeurs ou gestion des parties prenantes avec quelqu'un de l'équipe que vous alimenteriez en données — souvent un analyste ou un product manager, et c'est le tour pour lequel les candidats se préparent le moins parce qu'il ressemble à du bavardage informel alors qu'il ne l'est pas.

Le test SQL et Python

C'est rarement du par-cœur. Vous recevrez un schéma — souvent quelque chose comme commandes, clients, événements — et devrez écrire une requête utilisant des fonctions de fenêtrage : totaux cumulés, classement par partition, une auto-jointure pour trouver des lacunes ou chevauchements dans des plages de dates. L'objectif n'est pas la syntaxe, c'est de savoir si vous choisissez le bon outil sans qu'on vous y conduise. Un candidat qui résout « trouver le premier et le deuxième achat de chaque client » avec une sous-requête corrélée alors qu'un LAG() le ferait proprement dit quelque chose à l'intervieweur sur la façon dont il écrira du SQL de production sous pression temporelle.

Côté Python, attendez-vous à de la manipulation de données avec pandas ou du Python pur — dédupliquer un jeu de données désordonné, parser du JSON mal formé, gérer des nulls qui signifient des choses différentes selon les colonnes. De plus en plus, on vous demandera de raisonner sur un job Spark : pourquoi une transformation est lente, où se produit un shuffle, si repartitionner avant une jointure aiderait. Si vous n'avez jamais exécuté Spark qu'à travers une plateforme managée comme Databricks et n'avez jamais eu à expliquer pourquoi un job a débordé sur disque, c'est là que ça se voit.

À quoi ressemble une réponse superficielle ici : réciter que les index « accélèrent les requêtes » sans pouvoir dire ce qui arrive aux performances d'écriture, ou expliquer correctement la syntaxe d'une fonction de fenêtrage mais être incapable de dire quand utiliser ROW_NUMBER() plutôt que RANK() et ce qui casse si vous vous trompez sur une table avec des clés dupliquées.

Le tour de conception de pipeline ou système

C'est le tour qui sépare les personnes qui ont configuré un outil de celles qui ont possédé un système. On vous demandera typiquement de concevoir quelque chose comme : ingérer des événements d'une application dans un entrepôt, maintenir une table de dimension synchronisée avec une source amont qui change, ou construire un pipeline qui doit recharger trois ans d'historique sans doubler la facture de calcul.

L'intervieweur écoute un petit ensemble de choses, et elles apparaissent dans presque toutes les versions de cette question :

• Idempotence. Votre pipeline peut-il être ré-exécuté sur les mêmes données sans produire de doublons ou de totaux comptés deux fois ? Si votre réponse ne mentionne pas comment vous géreriez un job qui échoue à mi-chemin et est réessayé, c'est une lacune qu'ils creuseront.
• Évolution de schéma. Que se passe-t-il quand un système source ajoute une colonne, ou change un type d'int à string ? Échouez-vous bruyamment, ou corrompez-vous silencieusement les tables en aval ? Mentionner un registre de schémas, ou comment des tests dbt ou Great Expectations détecteraient cela, signale que vous en avez déjà fait les frais.
• Batch versus streaming, et pourquoi. Pas « le streaming c'est mieux » — c'est la réponse superficielle. La vraie réponse explique le compromis : Kafka ou Kinesis vous apporte une faible latence et une complexité que vous possédez maintenant, versus un job batch planifié dans Airflow ou Dagster qui est plus simple à raisonner et déboguer mais signifie des données périmées pendant la durée du planning.
• Partitionnement et coût. Si vous concevez une table sans dire comment vous la partitionneriez — par date, généralement, dans un entrepôt comme BigQuery ou Snowflake — et sans reconnaître qu'un scan complet de table sur une table de faits multi-téraoctets coûte de l'argent réel, l'intervieweur remarque l'omission même s'il ne le dit pas.
• Dimensions à évolution lente. Si le scénario implique une dimension qui change dans le temps (l'adresse d'un client, la catégorie d'un produit), l'écrasez-vous, ou la versionnez-vous avec quelque chose comme SCD Type 2 ? Se tromper là-dessus ne vous fait pas échouer directement, mais ne pas connaître le terme quand l'intervieweur dit « comment géreriez-vous un client changeant de région » est révélateur.

Une réponse superficielle à une question de conception semble fluide sur les outils et silencieuse sur l'échec. « J'utiliserais Airflow pour l'orchestrer et le déposer dans Snowflake » est une phrase sans ingénierie dedans — elle nomme le fournisseur et saute la décision. Une bonne réponse dit pourquoi : pourquoi cet orchestrateur gère les rechargements comme vous en avez besoin, pourquoi les clés de clustering de cet entrepôt importent pour le pattern de requêtes que les analystes exécutent réellement.

Les questions qui ressemblent à du bavardage informel

« Racontez-moi une fois où un pipeline que vous avez construit a cassé en production » n'est pas un brise-glace. C'est généralement la question la plus diagnostique de tout le processus, car une réponse superficielle donne le symptôme (« le tableau de bord affichait de mauvais chiffres ») et une vraie réponse donne le mécanisme : quelle surveillance ou absence de celle-ci a fait que vous l'avez appris d'une partie prenante plutôt que d'une alerte, quelle s'est avérée être la cause racine — un fichier arrivé en retard, un bug de fuseau horaire, un changement de schéma amont dont personne ne vous a parlé — et ce que vous avez changé ensuite pour que ça ne puisse pas se reproduire de la même façon.

De même, « comment décidez-vous quoi tester dans un pipeline » est posé pour voir si vous écrivez des vérifications de qualité de données par habitude — comptages de lignes, seuils de nulls, intégrité référentielle entre un fait et ses dimensions — ou si le test est quelque chose que vous faites après un incident parce que quelqu'un vous l'a dit. Mentionner une pratique spécifique, comme affirmer qu'une clé étrangère dans une table de faits se résout toujours en une ligne dans la dimension, passe mieux que dire « j'écris des tests pour mes pipelines », ce qui pourrait décrire n'importe quel job avec le mot pipeline dedans.

« Comment expliqueriez-vous à une partie prenante pourquoi son rapport a un jour de retard » teste quelque chose de différent encore : si vous pouvez traduire une cause technique — une limite de taux d'API source, une dépendance en aval qui ne s'est pas terminée — en langage qu'un non-ingénieur peut exploiter, sans ni l'abrutir à néant ni le noyer dans une terminologie DAG qu'il n'a pas.

Ce qui trahit quelqu'un qui n'a pas fait le travail

Les intervieweurs dans ce domaine remarquent un pattern spécifique : la fluidité avec les noms d'outils et aucune opinion sur leurs limites. Quelqu'un qui a réellement exécuté dbt en production peut vous dire où son framework de test échoue et ce qu'il superpose par-dessus. Quelqu'un qui a réellement exploité Airflow peut vous dire ce qui casse quand un DAG a trop de tâches dynamiques, ou pourquoi il a déplacé une transformation lourde hors d'un PythonOperator et dans l'entrepôt lui-même. Si chaque réponse nomme un outil et s'arrête là, c'est la réponse superficielle, et les personnes qui recrutent des data engineers en ont entendu des centaines.

L'autre indicateur est de parler de volume de données sans parler de coût ou de pattern de requête. « Nous avions des milliards de lignes » n'est pas, en soi, un fait d'ingénierie. Qu'est-ce que cela signifiait pour la façon dont la table était partitionnée, clusterisée ou compactée, et qu'est-ce qui serait arrivé à la facture d'entrepôt si vous vous étiez trompé ? Un intervieweur qui a possédé un tableau de bord de coûts Snowflake ou BigQuery posera une question de suivi et découvrira vite si les milliards de lignes étaient quelque chose que vous avez géré ou quelque chose que vous avez mentionné.

Que faire ensuite

Avant votre prochain entretien, choisissez deux pipelines que vous avez réellement construits et soyez prêt à décrire, en termes précis : comment vous les ré-exécuteriez en toute sécurité après un échec partiel, ce qui se passerait si le schéma source changeait en dessous de vous, et un incident où il a cassé et ce que vous avez changé ensuite. Entraînez-vous à dire le compromis, pas seulement l'outil — batch versus streaming, dénormalisé versus normalisé, orchestrateur A versus orchestrateur B — parce que c'est la forme de phrase que l'intervieweur écoute.

Si le problème le plus difficile maintenant est d'arriver à cet entretien du tout — des annonces qui demandent une expérience spécifique d'entrepôt ou d'orchestration que vous avez sous une forme différente, et des candidatures qui restent silencieuses — jobmarket.pro lit l'annonce en entier, la fait correspondre à votre expérience réelle, et prépare la candidature à partir de cela plutôt que d'un modèle générique.