dbt Interview Questions
dbt interviews for analytics engineering roles typically probe three layers: conceptual understanding of why dbt exists and how it differs from alternatives, hands-on modeling and materialization knowledge, and deeper mastery of testing, macros, and incremental strategies that only shows up after real production experience. Interviewers often care less about memorized syntax and more about whether a candidate can reason about tradeoffs — why choose a view over a table, why an incremental model needs a unique_key, why a test failure in CI should block a merge — because those judgment calls are what actually separates a reliable dbt project from a fragile one.
Cricket analogy: A talent scout watching a young batter cares less about a highlight reel of sixes and more about how they handle a probing line-and-length spell on a turning pitch, similarly to how an interviewer cares less about memorized dbt syntax and more about reasoning under real tradeoffs.
Conceptual Questions
Common conceptual questions include: 'What problem does dbt solve that raw SQL scripts don't?' (answer: version control, testing, documentation, and dependency management for SQL transformations), 'What is the difference between a source and a ref in dbt?' (source() points at a raw loaded table declared in a .yml file, while ref() points at another dbt model and builds the DAG dependency graph), and 'What happens when you run dbt run vs dbt build?' (dbt run only executes models, while dbt build runs models, tests, snapshots, and seeds together in dependency order, failing downstream models if an upstream test fails). A strong candidate can also explain why dbt compiles Jinja to raw SQL before execution, since that compilation step is what enables macros, variables, and cross-database portability.
Cricket analogy: Explaining the difference between source() and ref() is like explaining the difference between a raw pitch report and a scorecard reference to a previous innings — one describes external conditions, the other links to something already built within the match.
Modeling and Materialization Questions
Expect questions like 'What are the four built-in materializations and when would you use each?' (view for lightweight always-fresh logic, table for frequently-queried heavy transformations, incremental for large fact tables that shouldn't be fully rebuilt, and ephemeral for lightweight reusable logic that shouldn't persist as its own object in the warehouse), and 'How would you handle late-arriving data in an incremental model?' (typically by widening the incremental filter window with a lookback period, or using a merge/upsert strategy with a unique_key instead of a simple append). Candidates should also be ready to explain the difference between dbt seeds (small static CSV reference data checked into the repo) and dbt snapshots (point-in-time captures of a changing source table for SCD Type 2 history).
Cricket analogy: Choosing between a view, table, incremental, and ephemeral materialization is like choosing a batting approach — sometimes you need quick, disposable runs (view), sometimes a solid, lasting innings (table), sometimes building carefully over a long partnership (incremental), and sometimes just a single supporting shot that doesn't get remembered on its own (ephemeral).
Testing, Macros, and Advanced Questions
Senior-level interviews dig into custom generic tests written as Jinja macros in tests/generic/, the difference between dbt's built-in tests (schema tests, defined in YAML) and singular tests (custom SQL files in tests/ that fail if they return any rows), and questions like 'How would you debug a model that passed dbt test locally but failed in CI?' (usual suspects: environment-specific data differences, a hardcoded schema reference instead of using {{ target.schema }}, or a missing seed/snapshot not run before the test). Interviewers may also ask candidates to write a macro using a for loop and Jinja conditionals, or to explain how dbt's state:modified selector powers slim CI by only running and testing models that changed in a pull request rather than the entire project.
Cricket analogy: Debugging why a model passes locally but fails in CI is like debugging why a batter's technique works in the nets but breaks down in a real match — usually it's an environmental factor, crowd noise or pitch conditions, that only shows up under real match pressure, just as CI failures often trace to environment-specific data differences.
-- tests/generic/test_positive_value.sql
-- A custom generic test usable on any numeric column across models
{% test positive_value(model, column_name) %}
select *
from {{ model }}
where {{ column_name }} < 0
{% endtest %}
-- usage in schema.yml
-- columns:
-- - name: order_total
-- tests:
-- - positive_value
For interview prep, be ready to explain dbt build vs dbt run vs dbt test out loud in under 30 seconds — this is one of the most commonly asked warm-up questions and a shaky answer here signals shallow hands-on experience even if the rest of your answers are strong.
- Interviews test conceptual understanding, hands-on modeling/materialization knowledge, and advanced testing/macro fluency.
- Know the difference between source() (raw table) and ref() (another dbt model, builds the DAG).
- dbt build runs models, tests, seeds, and snapshots together; dbt run only executes models.
- Know all four materializations — view, table, incremental, ephemeral — and when to use each.
- Seeds are static CSV reference data; snapshots capture point-in-time history for SCD Type 2.
- Generic tests are reusable Jinja macros in tests/generic/; singular tests are one-off SQL files in tests/.
- state:modified powers slim CI by running/testing only models changed in a pull request.
Practice what you learned
1. What is the key difference between source() and ref() in dbt?
2. What does dbt build do that dbt run does not?
3. Which materialization is best for a large fact table that shouldn't be fully rebuilt every run?
4. What distinguishes a dbt snapshot from a dbt seed?
5. What does the state:modified selector enable?
Was this page helpful?
You May Also Like
dbt Best Practices
The project structure, layering, testing, and deployment conventions that keep a dbt project maintainable as it scales past a handful of models.
dbt Quick Reference
A lookup sheet of the CLI commands, YAML config keys, and Jinja functions used every day in a dbt project.
dbt vs Traditional ETL
How dbt's ELT, SQL-in-Git approach differs from traditional GUI-based ETL tools like Informatica or SSIS in compute cost, collaboration, and testing.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
ProgrammingPowerShell Study Notes
Programming · 30 topics