Fifteen common dbt interview questions
- What is dbt, and where does it sit in the data stack?
- What does ref() do, and why not hard-code table names?
- What are sources, and what are source freshness checks?
- Explain the materialisations: view, table, incremental, ephemeral.
- How do incremental models work? What can go wrong?
- What tests does dbt provide, and how do you write custom ones?
- What are snapshots?
- What are macros, and when would you write one?
- How do you structure a dbt project?
- What are seeds?
- How do you document models?
- How do you run dbt in CI efficiently?
- How do you handle environments such as dev and prod?
- How do you debug a failing model?
- What is the semantic layer, and why use it?
Core concepts
- dbt handles the transform step of ELT: you write SELECT statements, and dbt builds tables and views in the warehouse in dependency order.
- ref() resolves to the correct schema per environment and builds the dependency graph; hard-coded names break lineage and environment switching.
- Sources declare raw tables, enabling lineage from raw data and freshness checks that warn when data stops arriving.
- Seeds load small static CSVs, such as country codes, into the warehouse.
Materialisations
| Materialisation | Use when |
|---|---|
| View | Lightweight logic queried rarely; always fresh, recomputed on read |
| Table | Frequently queried or expensive models; rebuilt each run |
| Incremental | Large tables where only new or changed rows need processing |
| Ephemeral | Reusable logic inlined as a CTE; not built in the warehouse |
Incremental models and snapshots
An incremental model processes only new rows on subsequent runs, filtered with is_incremental() — for example, events after the latest timestamp already loaded. Use a unique key to merge updates. Pitfalls: late-arriving data missed by a strict timestamp filter (use a lookback window), schema changes, and drift that needs an occasional full refresh. Snapshots implement type 2 slowly changing dimensions: dbt records changes to mutable source rows over time with validity columns, using a timestamp or check strategy.
Testing and documentation
- Generic tests: unique, not_null, accepted_values and relationships declared in YAML.
- Singular tests: SQL queries that return failing rows for custom business rules.
- Packages add more tests, such as ranges or row-count comparisons.
- Severity: warn for soft issues, error for critical ones.
- Documentation: descriptions in YAML and generated docs with a lineage graph, so analysts can trust and find models.
Structure, macros and CI
A common structure has staging models (one per source table, renamed and typed), intermediate models (reusable joins and logic) and marts (business-facing facts and dimensions). Macros are Jinja functions for repeated SQL patterns, such as currency conversion or generating date spines; use them for genuine repetition, not to hide simple SQL. In CI, build and test only modified models and their downstream dependants against a production manifest, which keeps runs fast. See analytics engineer interview questions.
Debugging a failing model
Read the compiled SQL in the target directory — it shows exactly what ran after Jinja rendering. Run the model alone with its upstream dependencies, query intermediate CTEs directly in the warehouse, and check whether a source changed schema or a test caught bad upstream data. For test failures, query the failing rows that the test returns. Interviewers like candidates who reach for compiled SQL first, because most dbt bugs are SQL bugs hidden behind templating.
Practising
The fastest way to find gaps is to be asked. Run a spoken mock round on dbt topics — a free AI interview assistant such as CoPilot Interview builds one from your résumé and the job description and scores every answer — then study whatever you stumbled on. Build a small project with a staging, an intermediate and a mart model, tests on each, and one incremental model with a lookback window.
Disclosure: CoPilot Interview is our product, so weigh what we say about it accordingly. Everything else on this page applies whichever tool you use, or none.
Frequently asked questions
What is dbt used for?
Transforming data inside the warehouse using SQL SELECT statements organised into modular, tested and documented models built in dependency order.
What does ref() do in dbt?
It references another model, resolving to the right schema for the current environment and recording the dependency so dbt builds models in the correct order and shows lineage.
How do incremental models work?
On later runs they process only new or changed rows, filtered with is_incremental(), and merge them using a unique key, with a lookback window to catch late data.
What are dbt snapshots?
A way to capture changes to mutable source records over time, implementing type 2 slowly changing dimensions with validity date columns.
Practise on real interview questions
Run 145 real interview questions across 10 tracks, answer out loud and see a structured answer to compare with yours. Free, no signup.
Try a practice question