dbt est devenu le standard de la transformation data. Entre lancer dbt run et concevoir une architecture robuste, il y a un monde.
dbt a transforme le metier d'Analytics Engineer. Sa structure impose de bonnes pratiques — mais seulement si le candidat les a vraiment internalisees.
Comment organisez-vous les couches de votre projet dbt ? Difference entre staging, intermediate et marts ?
Signal d'alerte : un profil qui met tout en view ou n'a jamais configure un modele incremental n'a pas travaille sur des volumes reels.
Quels tests mettez-vous systematiquement sur vos modeles ? Quand creez-vous un test custom ?
Qu'est-ce que vous documentez systematiquement et pourquoi ?
Exemple de macro Jinja que vous avez ecrite. Quel probleme resolvait-elle ?
Comment organisez-vous un projet dbt pour une equipe de 4 Analytics Engineers ?
| Niveau | Maitrise attendue | Signal GO | NO-GO |
|---|---|---|---|
| Junior | dbt run/test/docs, 3 couches, tests generiques | Comprend staging/marts, tests not_null et unique | Pas de tests, tout en view |
| Confirme | Incrementaux, Jinja de base, dbt_utils | A configure un modele incremental en prod | N'a jamais ecrit de macro |
| Senior | Macros avancees, snapshots, CI/CD slim | CI GitHub Actions sur les modeles modifies | Pas d'experience CI/CD |
| Lead | Standards equipe, exposures, gouvernance | A defini les conventions de nommage equipe | Ne peut expliquer mono-repo vs multi-repo |
Premier entretien gratuit. Rapport GO/NO-GO sous 48h.