Accueil›Blog›Test technique dbt

Guide recrutement data

Test technique dbt : ce qu'on évalue vraiment en entretien

dbt est devenu le standard de la couche de transformation dans la stack data moderne. Mais « faire du dbt » va de lancer dbt run sur des modèles copiés-collés à concevoir un projet modulaire, testé, documenté et gouverné. L'écart de niveau est immense — voici comment le mesurer.

Data Builder·Juillet 2025·9 min de lecture·Analytics Engineer

Sommaire

Modélisation et matérialisations
ref() et sources
Tests et qualité
Incrémental et snapshots
Structure et conventions
Grille par niveau

dbt (data build tool) a industrialisé la transformation de la donnée : versionnée, testée, documentée, exécutée dans un DAG. Sur le papier, tout le monde « connaît dbt ». En entretien, l'écart se creuse vite entre celui qui empile des modèles et celui qui conçoit une couche analytique maintenable. Voici les cinq dimensions que nous évaluons, et les signaux qui trient les profils.

1Modélisation et matérialisations

Question discriminante

Comment choisissez-vous entre une vue, une table et un modèle incrémental — et pourquoi ?

C'est la première ligne de partage. Un profil solide justifie chaque choix par le coût de reconstruction, la fréquence de lecture et la volumétrie, pas par habitude.

view — recalculée à chaque requête, zéro stockage : idéale pour la couche de staging.
table — matérialisée, rapide à lire mais coûteuse à reconstruire : pour les marts souvent consommés.
incremental — ne traite que les nouvelles lignes : indispensable dès que la reconstruction complète devient prohibitive.
ephemeral — jamais matérialisée, inlinée en CTE dans les modèles qui l'utilisent.

Bon réflexe : vue par défaut, table pour les marts très lus, incrémental seulement quand le coût le justifie. Matérialiser tout en table « pour aller vite » est un signal de méconnaissance des coûts.

2ref() et sources

Question discriminante

Pourquoi ne faut-il jamais écrire un nom de table en dur dans un modèle ?

ref() — référence un autre modèle et construit automatiquement le graphe de dépendances (DAG).
source() — déclare et documente les tables brutes en entrée du projet.
Lineage — dbt sait dans quel ordre construire, et ce qui casse en aval quand un modèle change.
source freshness — détecte une source qui n'est plus alimentée avant que le rapport ne soit faux.

Signal d'alerte : un candidat qui code un nom de table en dur (from analytics.orders) casse le lineage et l'ordonnancement. C'est le premier réflexe qui distingue un utilisateur de dbt d'un simple exécutant de SQL.

3Tests et qualité

Question discriminante

Comment garantissez-vous la fiabilité de ce que consomment les analystes en aval ?

Tests génériques : unique, not_null, accepted_values, relationships — déclaratifs, dans le YAML.
Tests singuliers : une requête SQL qui doit renvoyer zéro ligne pour passer.
Paquets : dbt-utils, dbt-expectations pour des assertions avancées (unicité composite, distribution, fraîcheur).
Contrats et versions de modèles (dbt 1.5+) — figer le schéma d'un modèle consommé par d'autres équipes.

Signal d'alerte : un projet sans tests est un projet dont personne ne connaît la fiabilité. En production, c'est un drapeau rouge — surtout si le candidat n'a pas de réponse à « comment sauriez-vous qu'une clé est dupliquée ? ».

4Incrémental et snapshots

Question discriminante

Comment gérez-vous une table de faits volumineuse, et l'historisation d'une dimension qui change ?

{{ config(materialized='incremental', unique_key='order_id') }}

select * from {{ ref('stg_orders') }}
{% if is_incremental() %}
  where updated_at > (select max(updated_at) from {{ this }})
{% endif %}

is_incremental() + unique_key — ne traiter que le delta, en re-fusionnant proprement les lignes modifiées.
Stratégies : append, merge, delete+insert, insert_overwrite — le bon choix dépend du moteur et de la donnée.
Le piège des late-arriving data — prévoir une fenêtre de rattrapage plutôt qu'un simple max().
snapshots — capturer l'historique d'une dimension (SCD type 2) sans réécrire la logique à la main.

5Structure, conventions et documentation

Question discriminante

Comment organisez-vous un projet dbt destiné à durer et à être repris par une équipe ?

Couches : staging (1:1 avec les sources, renommage et typage), intermediate (logique réutilisable), marts (modèles métier).
Conventions de nommage : stg_, int_, fct_, dim_ — la cohérence prime sur le goût personnel.
Macros et packages pour factoriser la logique répétée.
Documentation et exposures — un projet qui se documente lui-même et déclare ses usages en aval.
CI/CD : slim CI avec state:modified pour ne (re)construire et tester que ce qui change.

Bon réflexe : un senior parle de conventions d'équipe et de CI avant de parler de syntaxe. La maintenabilité, pas la virtuosité, fait la différence à l'échelle.

6Grille par niveau

Niveau	Maîtrise attendue	Signal GO	NO-GO
Junior	Matérialisations de base, `ref`/`source`, tests génériques	Écrit un modèle propre, ajoute `unique`/`not_null`	Code un nom de table en dur
Confirmé	Incrémental, macros, packages, structure en couches	A construit une couche marts testée et documentée	Ne sait pas quand utiliser `incremental`
Senior	Snapshots (SCD2), contrats, CI slim, performance et coûts	A mis en place l'historisation et la CI `state:modified`	Ne teste pas ses modèles
Lead	Gouvernance, mesh / multi-projets, standards d'équipe	A défini les conventions et le lineage cross-équipes	Ne peut pas expliquer `view` vs `table` vs `incremental`

Home›Blog›dbt technical interview

Data hiring guide

dbt technical interview: what we really assess

dbt has become the standard transformation layer of the modern data stack. But "doing dbt" ranges from running dbt run on copy-pasted models to designing a modular, tested, documented and governed project. The gap in level is huge — here's how to measure it.

Data Builder·July 2025·9 min read·Analytics Engineer

Contents

Modelling and materializations
ref() and sources
Tests and quality
Incremental and snapshots
Structure and conventions
Level grid

dbt (data build tool) industrialized data transformation: versioned, tested, documented, run in a DAG. On paper, everyone "knows dbt". In an interview, the gap widens fast between someone who stacks models and someone who designs a maintainable analytics layer. Here are the five dimensions we assess, and the signals that sort candidates.

1Modelling and materializations

Key question

How do you choose between a view, a table and an incremental model — and why?

This is the first dividing line. A strong profile justifies each choice by rebuild cost, read frequency and volume, not by habit.

view — recomputed on every query, zero storage: ideal for the staging layer.
table — materialized, fast to read but expensive to rebuild: for often-consumed marts.
incremental — processes only new rows: essential once a full rebuild becomes prohibitive.
ephemeral — never materialized, inlined as a CTE in the models that use it.

Good reflex: view by default, table for heavily-read marts, incremental only when cost justifies it. Materializing everything as a table "to go fast" signals a lack of cost awareness.

2ref() and sources

Key question

Why should you never hard-code a table name in a model?

ref() — references another model and automatically builds the dependency graph (DAG).
source() — declares and documents the raw input tables of the project.
Lineage — dbt knows the build order, and what breaks downstream when a model changes.
source freshness — detects a source that stopped loading before the report goes wrong.

Warning signal: a candidate who hard-codes a table name (from analytics.orders) breaks lineage and scheduling. It's the first reflex that separates a dbt user from a mere SQL executor.

3Tests and quality

Key question

How do you guarantee the reliability of what analysts consume downstream?

Generic tests: unique, not_null, accepted_values, relationships — declarative, in YAML.
Singular tests: a SQL query that must return zero rows to pass.
Packages: dbt-utils, dbt-expectations for advanced assertions (composite uniqueness, distribution, freshness).
Model contracts and versions (dbt 1.5+) — freeze the schema of a model consumed by other teams.

Warning signal: a project without tests is a project whose reliability nobody knows. In production it's a red flag — especially if the candidate has no answer to "how would you know a key is duplicated?".

4Incremental and snapshots

Key question

How do you handle a large fact table, and the historization of a changing dimension?

{{ config(materialized='incremental', unique_key='order_id') }}

select * from {{ ref('stg_orders') }}
{% if is_incremental() %}
  where updated_at > (select max(updated_at) from {{ this }})
{% endif %}

is_incremental() + unique_key — process only the delta, cleanly merging changed rows.
Strategies: append, merge, delete+insert, insert_overwrite — the right one depends on the engine and the data.
The late-arriving data trap — plan a catch-up window rather than a naive max().
snapshots — capture a dimension's history (SCD type 2) without hand-rolling the logic.

5Structure, conventions and documentation

Key question

How do you organize a dbt project meant to last and be picked up by a team?

Layers: staging (1:1 with sources, renaming and typing), intermediate (reusable logic), marts (business models).
Naming conventions: stg_, int_, fct_, dim_ — consistency beats personal taste.
Macros and packages to factor out repeated logic.
Documentation and exposures — a project that documents itself and declares its downstream uses.
CI/CD: slim CI with state:modified to (re)build and test only what changes.

Good reflex: a senior talks about team conventions and CI before syntax. Maintainability, not virtuosity, makes the difference at scale.

6Level grid

Level	Expected proficiency	GO signal	NO-GO
Junior	Basic materializations, `ref`/`source`, generic tests	Writes a clean model, adds `unique`/`not_null`	Hard-codes a table name
Mid-level	Incremental, macros, packages, layered structure	Has built a tested, documented marts layer	Doesn't know when to use `incremental`
Senior	Snapshots (SCD2), contracts, slim CI, performance and cost	Has set up historization and `state:modified` CI	Doesn't test their models
Lead	Governance, mesh / multi-project, team standards	Has defined conventions and cross-team lineage	Can't explain `view` vs `table` vs `incremental`

Test technique dbt : ce qu'on évalue vraiment en entretien

1Modélisation et matérialisations

2ref() et sources

3Tests et qualité

4Incrémental et snapshots

5Structure, conventions et documentation

6Grille par niveau

dbt technical interview: what we really assess

1Modelling and materializations

2ref() and sources

3Tests and quality

4Incremental and snapshots

5Structure, conventions and documentation

6Level grid

Vous recrutez un profil data ?