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.

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.

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).

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.