dbt Interview Questions (2026)
Practice 45 dbt interview questions on models, refs, sources, tests, documentation, snapshots, incremental models, seeds, macros, exposures, and deployment.
45 questions with answersWhat Is dbt?
Key Takeaways
- ✓dbt is an analytics engineering tool for transforming data in a warehouse using SQL, version control, tests, and documentation.
- ✓Interviews test models, refs, sources, tests, docs, snapshots, seeds, macros, materializations, incremental models, and deployments.
- ✓Strong answers explain how dbt turns SQL files into a dependency graph with tested, documented tables or views.
- ✓dbt does not extract or load data by itself. It transforms data already available in the warehouse or platform.
dbt is a data transformation and analytics engineering tool. Teams write SQL models, connect them with ref and source, test assumptions, document datasets, and deploy transformations through version-controlled workflows. In interviews, dbt questions test whether you can design a clean model DAG, choose materializations, write data tests, handle incremental logic, manage environments, and keep analytics tables trustworthy.
Watch: What is dbt?
Video: What is dbt? (dbt Labs, YouTube)
Test yourself and earn a certificate
6 quick questions. Score 70%+ to download your dbt certificate.
All Questions on This Page
45 questions- 1. What is a dbt model?
- 2. What does ref do?
- 3. What is a dbt source?
- 4. What is materialization?
- 5. When use view materialization?
- 6. When use table materialization?
- 7. What is an incremental model?
- 8. What is an ephemeral model?
- 9. What is a dbt data test?
- 10. What is a generic test?
- 11. What is a singular test?
- 12. What is a dbt snapshot?
- 13. What is a dbt seed?
- 14. What is a dbt macro?
- 15. What is a dbt exposure?
- 16. How do you design staging models?
- 17. How do you build a fact table in dbt?
- 18. How do you write safe incremental logic?
- 19. How do you monitor source freshness?
- 20. Which tests do you add first?
- 21. When would you use snapshots?
- 22. When should you use seeds?
- 23. How do you use macros well?
- 24. What should dbt docs include?
- 25. What should dbt CI run?
- 26. How do you promote dbt changes?
- 27. How do selectors help?
- 28. How do you backfill a dbt model?
- 29. How do you debug a failed dbt model?
- 30. How does a semantic layer help?
- 31. A model fails because a dependency was renamed. What should have helped?
- 32. A unique test fails. What do you do?
- 33. An incremental model misses late-arriving rows. What changes?
- 34. A dashboard is empty because source data is late. What should catch it?
- 35. A snapshot table grows too fast. What do you inspect?
- 36. A macro makes SQL hard to debug. What is the trade-off?
- 37. Two dashboards show different revenue. What is missing?
- 38. Queries are slow through many views. What changes?
- 39. A dbt test fails often but no one acts. What is wrong?
- 40. A full refresh changes old metrics. What should happen?
- 41. Dev models write into production schema. What control is missing?
- 42. A source column type changes. What catches it?
- 43. A model is deleted and a dashboard breaks. What was missing?
- 44. A team wants to seed a huge file. What do you say?
- 45. What do you ask before approving a dbt project?
dbt Fundamentals
Foundational15 questionsStart here. These are the definitions and first-principle checks that open most rounds.
Q1. What is a dbt model?
A dbt model is a SQL select statement that dbt materializes as a view, table, incremental table, or ephemeral model.
Models are nodes in the dbt DAG.
Model changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: What is dbt? (dbt Labs, YouTube)
Q2. What does ref do?
ref references another dbt model and creates a dependency in the DAG.
Use ref instead of hardcoding relation names.
ref changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
dbt DAG path
Tests can run at every layer.
Q3. What is a dbt source?
A source declares raw upstream tables that dbt models depend on.
Sources can include freshness checks.
source changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q4. What is materialization?
Materialization controls how dbt builds a model, such as view, table, incremental, or ephemeral.
Choose based on cost, speed, and use case.
Materialization changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
| Answer part | What to say | Evidence to mention |
|---|---|---|
| Definition | Materialization in one direct sentence. | Official docs or course material |
| Use case | The work where it changes a decision. | Dataset, model, query, dashboard, or pipeline |
| Risk | What breaks when it is misunderstood. | Metric, log, test result, or review note |
Q5. When use view materialization?
Use a view when logic is light and freshness matters more than query speed.
Views can become slow if stacked too deeply.
View changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: dbt fundamentals (dbt Labs, YouTube)
Q6. When use table materialization?
Use a table when query performance matters and rebuilding cost is acceptable.
Tables need rebuild scheduling.
Table changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q7. What is an incremental model?
An incremental model processes only new or changed data after the first build.
It needs careful unique keys and late-data logic.
Incremental model changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q8. What is an ephemeral model?
An ephemeral model is inlined into downstream SQL instead of being created as a relation.
It fits small reusable transformations.
Ephemeral model changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q9. What is a dbt data test?
A dbt data test checks assumptions about model data, such as not null, unique, relationships, or accepted values.
Tests should protect business logic.
Data test changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q10. What is a generic test?
A generic test is a reusable test pattern configured in YAML.
not_null and unique are common examples.
Generic test changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q11. What is a singular test?
A singular test is a custom SQL query that returns failing rows.
It fits business-specific rules.
Singular test changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q12. What is a dbt snapshot?
A snapshot tracks changes to mutable source records over time.
It is useful for slowly changing dimensions.
Snapshot changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q13. What is a dbt seed?
A seed is a small CSV file versioned in the dbt project and loaded into the warehouse.
Seeds fit small static reference data.
Seed changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: dbt models and tests (dbt tutorial, YouTube)
Q14. What is a dbt macro?
A macro is reusable Jinja logic used to generate SQL or project behavior.
Macros should reduce repetition without hiding too much.
Macro changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q15. What is a dbt exposure?
An exposure documents a downstream use such as a dashboard, notebook, ML model, or app.
It helps impact analysis.
Exposure changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
dbt Practical Interview Questions
Intermediate15 questionsThese questions test whether you can apply the topic to real data, real code, and messy constraints.
Q16. How do you design staging models?
Create one staging model per source table, rename fields, cast types, clean light source issues, and keep business logic minimal.
Staging creates a stable interface to raw data.
staging model changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
# Interview check: split data, run baseline, inspect metric
from sklearn.metrics import accuracy_score
print(accuracy_score(y_true, y_pred))Q17. How do you build a fact table in dbt?
Join clean staging models, define grain, calculate measures, add keys, test uniqueness, and document metric definitions.
Grain must be explicit.
fact table changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q18. How do you write safe incremental logic?
Choose unique key, filter new or changed rows, handle late arrivals, and test full refresh against incremental output.
Late data is the usual edge case.
incremental logic changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q19. How do you monitor source freshness?
Declare sources, set freshness thresholds, run freshness checks, and alert owners when upstream data is stale.
Freshness failures should block critical models.
source freshness changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q20. Which tests do you add first?
Add not_null and unique for primary keys, relationships for foreign keys, accepted values for enums, and custom tests for business rules.
Tests should protect data contracts.
dbt tests changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q21. When would you use snapshots?
Use snapshots when a source table updates records in place and you need history of changes.
Do not snapshot huge tables without reason.
snapshots changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q22. When should you use seeds?
Use seeds for small static reference data such as mapping tables or codes.
Use warehouse tables for large or frequently changing data.
seeds changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q23. How do you use macros well?
Use macros for repeated SQL patterns, cross-database helpers, and tests, while keeping generated SQL understandable.
Macros can become hard to debug.
macro use changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q24. What should dbt docs include?
Document model purpose, owner, columns, tests, source lineage, metric definitions, and downstream exposures.
Docs help users trust tables.
docs changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q25. What should dbt CI run?
Run changed models, dependencies, tests, linting where available, and compile checks before merge.
CI catches broken SQL and tests early.
CI job changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: dbt incremental models (dbt tutorial, YouTube)
Q26. How do you promote dbt changes?
Develop in dev schema, test in CI, deploy to production job, and monitor tests and freshness.
Environment separation protects production tables.
environment promotion changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q27. How do selectors help?
Selectors run subsets of the DAG by tag, path, state, model, or dependency graph.
They are useful for CI and backfills.
model selection changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q28. How do you backfill a dbt model?
Plan affected dates, run full refresh or scoped rebuild, validate counts and metrics, then communicate changes.
Backfills can change historical dashboards.
backfill changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q29. How do you debug a failed dbt model?
Read compiled SQL, check upstream refs, inspect warehouse error, run dependencies, and test failing rows.
Compiled SQL is the fastest clue.
debug failure changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q30. How does a semantic layer help?
It centralizes metric definitions so dashboards and users calculate metrics consistently.
Metric ownership still matters.
semantic layer changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
dbt Advanced Scenarios
Advanced15 questionsAdvanced rounds test trade-offs, failure modes, and whether the decision can hold up under production pressure.
Q31. A model fails because a dependency was renamed. What should have helped?
Using ref and CI should catch dependency changes before production.
Hardcoded table names are fragile.
broken ref changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q32. A unique test fails. What do you do?
Inspect model grain, joins, source duplicates, and incremental merge logic.
Do not ignore primary key failures.
duplicate primary key changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q33. An incremental model misses late-arriving rows. What changes?
Use a lookback window, merge strategy, or full refresh for affected periods.
Incremental filters need late-data rules.
late data changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q34. A dashboard is empty because source data is late. What should catch it?
Source freshness checks and alerts should catch it.
Freshness is part of the contract.
stale source changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q35. A snapshot table grows too fast. What do you inspect?
Check snapshot strategy, updated_at field, change frequency, and whether history is truly needed.
Snapshots store history and cost money.
snapshot explosion changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q36. A macro makes SQL hard to debug. What is the trade-off?
Reusability may be hurting readability.
Generated SQL should stay inspectable.
macro hides SQL changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q37. Two dashboards show different revenue. What is missing?
A shared metric definition, owner, and tested model are missing.
dbt can centralize logic.
wrong metric changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q38. Queries are slow through many views. What changes?
Materialize heavy models as tables or incremental models and profile warehouse queries.
Views are not free.
view stack slow changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q39. A dbt test fails often but no one acts. What is wrong?
The test may be poorly scoped, not owned, or not tied to a response.
Tests need actionability.
test noise changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q40. A full refresh changes old metrics. What should happen?
Validate against expected changes, document logic updates, and communicate downstream impact.
Historical changes need context.
bad full refresh changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q41. Dev models write into production schema. What control is missing?
Target profiles, permissions, and environment separation are missing.
Protect production schemas.
environment mistake changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q42. A source column type changes. What catches it?
Model compile, tests, source contracts, and CI should catch downstream breakage.
Raw changes need alerts.
source schema change changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q43. A model is deleted and a dashboard breaks. What was missing?
Exposures or lineage review should show downstream dependency.
Impact analysis needs metadata.
missing exposure changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q44. A team wants to seed a huge file. What do you say?
Use a warehouse load or source table instead.
Seeds are for small static data.
large seed changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q45. What do you ask before approving a dbt project?
Ask about model layers, grain, refs, sources, tests, docs, materializations, CI, freshness, exposures, and ownership.
These decide whether analytics tables are trusted.
senior review changes dbt decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
dbt Model vs Source vs Snapshot
dbt interviews often test whether you understand where raw data ends, transformed models begin, and history tracking belongs.
| dbt object | Purpose | Example | Risk |
|---|---|---|---|
| Source | Declare raw upstream data | raw.orders | Skipping freshness checks |
| Model | Transform data with SQL | stg_orders, fct_revenue | Building unclear dependencies |
| Snapshot | Track slowly changing records | customer status history | Using snapshots for every table |
| Seed | Version small static data | country codes | Using seeds for large data |
dbt answer signals
Good answers make the DAG trustworthy and maintainable.
- Model design: staging, marts, DAG
- Testing: unique, not null, relationships
- Materialization: view, table, incremental
- Docs: owners, metrics, lineage
How to Prepare for a dbt Interview
Prepare by drawing a dbt DAG from raw sources to staging models, intermediate models, marts, tests, and exposures.
- Review models, ref, source, tests, docs, seeds, snapshots, macros, materializations, selectors, and exposures.
- Know staging, intermediate, marts, facts, dimensions, incremental models, and source freshness.
- dbt run, dbt test, dbt build, and environment promotion is the explanation path.
- One story about a failed data test, broken incremental model, or unclear metric definition is useful.
dbt interview prep flow
Most rounds reward clear reasoning more than memorized phrasing.
How Strong dbt Answers Sound
A strong dbt answer explains the DAG and the contract. Say where raw data is declared, how staging models clean it, which facts and dimensions are produced, what tests protect the model, and who owns downstream use. production-ready answers mention incremental edge cases, source freshness, snapshots, selectors, CI jobs, documentation, metric definitions, and rollback when a model breaks.
Use refs, not hardcoded dependencies
ref builds lineage and lets dbt order models correctly.
Test business assumptions
Unique, not null, accepted values, relationships, and custom tests catch broken logic.
Keep staging simple
Staging should clean and standardize source data, not hide heavy business logic.
Watch incremental edge cases
Late-arriving data, deletes, and schema changes can break incremental models.
Test Yourself: dbt Quiz
Ready to test your dbt knowledge?
6 questions, about 4 minutes. Score 70% or higher to earn a shareable certificate.
Frequently Asked Questions
What do dbt interviews usually ask?
Is dbt an ETL tool?
What dbt project should I discuss?
What separates experienced dbt candidates?
Practice dbt answers before analytics engineering rounds
Use this dbt bank for SQL transformation and testing answers, then practice SQL and data tasks with Hyring's AI Coding Interviewer.
See Hyring AI Coding InterviewerSources
Written by Adithyan RK