---
title: dbt Interview Questions and Answers (2026)
description: Real dbt interview questions — models and ref, materializations, incremental models, tests, snapshots and macros — with worked code and a four-week prep plan.
url: https://usegreenroom.app/blog/dbt-interview-questions
last_updated: 2026-07-31
---
← Back to blog
Data Engineering
# dbt interview questions and answers
July 31, 2026 · 12 min read
The candidate had a nice answer about incremental models. Really nice. Then the interviewer asked: "Your incremental model has been running for three months. Yesterday someone fixed a bug in the CASE statement that assigns customer tier. What happens to the ninety days of rows already in that table?" And the answer, which the candidate found about eight seconds too late, is: absolutely nothing happens to them, which is the problem.
dbt interview questions concentrate on exactly this sort of thing — not what a feature does, but what it costs you later. dbt is deceptively easy to learn and genuinely easy to misuse, so interviews probe the operational edges. This guide covers models, materializations, incremental logic, tests, snapshots and macros, with the follow-up behind each.
## What dbt interviews actually test
dbt interview questions tend to break into five areas, and only the first is beginner-level:
- Core mechanics — models, ref(), the compiled DAG, project structure.
- Materializations — view, table, incremental, ephemeral, and the tradeoff behind each.
- Incremental models — the highest-value area, and where most candidates get exposed.
- Testing and documentation — generic tests, singular tests, sources and freshness, and what you would actually alert on.
- Snapshots and macros — slowly changing dimensions, Jinja, and knowing when a macro is a bad idea.
The five bands of dbt interview questions, with incremental models exposing the most candidates.
## Models, ref() and why the DAG matters
A dbt model is a SELECT statement in a .sql file; dbt wraps it in the DDL needed to materialise it. The opening question is usually: why use ref() instead of writing the table name?
Three reasons, and a complete answer gives all three. It builds the dependency graph, so dbt knows the correct build order without you maintaining one. It handles environment resolution, so the same code points at your dev schema locally and production in prod — which is the entire reason dbt developers can work safely in parallel. And it enables selective runs like dbt run --select my_model+ to rebuild a model and everything downstream.
Expect a question on project structure too. The conventional layering is staging (one model per source table, light renaming and casting, no business logic), intermediate (joins and reusable logic), and marts (business-facing fact and dimension tables). The reasoning is worth stating: staging models are cheap to reason about because they map one-to-one to sources, so when a source changes you know exactly what breaks. Use source() rather than ref() for raw tables, so freshness can be checked and lineage starts at the true origin.
## Materializations: view, table, incremental, ephemeral
A guaranteed question. The four dbt materializations and when each is right:
- view — no storage, always fresh, computation happens at query time. Right for lightweight staging models and anything queried rarely. Wrong when the logic is expensive and queried often, because every consumer pays the cost.
- table — rebuilt from scratch each run. Simple, predictable, and correct by construction. Right until the rebuild gets too slow or expensive.
- incremental — only new or changed rows are processed. Right for large event and fact tables. Costs you complexity and, as the intro shows, correctness risk when logic changes.
- ephemeral — not built at all; inlined as a CTE into downstream models. Right for small reusable logic you do not want cluttering the warehouse. Wrong for anything complex, because it cannot be inspected or tested directly and it duplicates compute in every consumer.
The strongest answer adds the default heuristic: start with view or table, and move to incremental only when the runtime or cost actually hurts. Candidates who reach for incremental immediately are optimising a problem they do not have and importing a class of bug they do not need.
## Incremental models — the question that decides the round
Here is a realistic incremental model, in the shape interviewers expect to see:
```
{{ config(
materialized='incremental',
unique_key='order_id',
incremental_strategy='merge',
partition_by={'field': 'order_date', 'data_type': 'date'}
) }}
SELECT
o.order_id,
o.customer_id,
o.order_date,
o.amount_paise,
o.updated_at
FROM {{ ref('stg_orders') }} o
{% if is_incremental() %}
-- Look back 3 days to catch late-arriving and corrected records
WHERE o.updated_at >= (
SELECT COALESCE(MAX(updated_at), '1900-01-01') FROM {{ this }}
) - INTERVAL '3 days'
{% endif %}
```
Talk through the deliberate choices, because each is a likely follow-up:
- is_incremental() is false on a full refresh and on the first run, so the same file builds the table from scratch or updates it.
- The lookback window exists because filtering on exactly MAX(updated_at) silently drops late-arriving rows. A three-day overlap plus unique_key deduplication is the standard pattern.
- unique_key with the merge strategy turns re-processed rows into updates rather than duplicates. Without it, an overlapping window inserts the same order twice.
- {{ this }} refers to the existing version of the model being built.
- Strategies differ by warehouse — merge on Snowflake, BigQuery and Databricks; delete+insert on Redshift and Postgres; insert_overwrite for partition-level replacement on BigQuery and Spark. Naming the right one for the warehouse in the job description is a strong signal.
And then the intro's question: what happens when the transformation logic changes? Nothing — old rows keep the old logic, and the table becomes silently inconsistent. The fix is dbt run --full-refresh, and the mature answer adds that this is the real cost of incremental models: you must remember to full-refresh after logic changes, so many teams schedule a periodic full refresh (weekly, or monthly for huge tables) as insurance.
## Tests, sources and freshness
dbt ships four generic tests — unique, not_null, accepted_values and relationships (referential integrity) — declared in YAML. Singular tests are arbitrary SQL files that pass when they return zero rows, which is the right tool for business rules like "no order may have a negative amount" or "daily revenue must not drop more than 50% day over day."
Two follow-ups recur. First, what would you actually alert on? The good answer distinguishes severity: error (block the build — a duplicate primary key) from severity: warn (log it — a slightly stale source), because a test suite that pages people for warnings gets muted, and a muted suite is worse than none. Second, source freshness: dbt source freshness checks a loaded_at_field against warn and error thresholds, catching the failure mode where your models run perfectly on yesterday's data. That is the same "task succeeded, data is stale" problem the Airflow interview questions guide covers from the orchestration side.
Also know dbt docs generate and the lineage graph, and packages like dbt-utils and dbt-expectations for tests you would otherwise hand-roll.
## Snapshots, macros and Jinja
Snapshots implement slowly changing dimensions type 2 — they track how a row changed over time by maintaining dbt_valid_from and dbt_valid_to columns. Two strategies: timestamp (uses an updated_at column, preferred and cheaper) and check (compares a list of columns, for sources with no reliable timestamp).
The question behind it: why not just build SCD2 as a model? Because snapshots must capture state as it was observed — once a source row is overwritten, the history is gone forever unless you snapshotted it. Snapshots therefore run on their own schedule against sources, before the models that consume them. The data modeling interview questions guide covers SCD types in depth.
Macros are Jinja functions for reusable SQL — cents_to_rupees(column), a standard date spine, warehouse-specific grant logic. The mature take, and interviewers reward it: macros are a maintenance cost. A macro used in twenty models is excellent; a macro used once is a layer of indirection that makes the SQL unreadable to the analyst who has to debug it at 9pm. Know that dbt compiles Jinja to plain SQL and that dbt compile plus the target/ directory is how you debug a macro that produces something unexpected.
## Stored procedures, Airflow, ChatGPT — where each fits
- The official dbt documentation — unusually good, and the materializations and incremental-strategy pages answer most interview questions directly.
- The dbt Fundamentals course — free, a few hours, and closely aligned with what entry-level rounds ask.
- dbt vs stored procedures — a real interview question. dbt gives you version control, testing, documentation, lineage and environment separation; stored procedures give you none of that by default. Say that without sneering at the legacy stack, because you may be migrating one.
- dbt vs Airflow — the other real question, and the answer is that they are not competitors. dbt transforms inside the warehouse; Airflow orchestrates when things run, including the dbt job. Most teams run both.
- A real project — highest yield here. Build a small project on DuckDB or a free Snowflake/BigQuery tier with staging, marts, tests and one incremental model. Then change the logic and watch the incremental table not update. That experience answers the hardest question in the loop.
- ChatGPT — good at generating models and explaining Jinja. It will not ask what happens to ninety days of already-materialised rows.
- Greenroom — the spoken layer. Ari, the AI interviewer, runs the round out loud and pushes on the operational consequence behind each answer. Fair tradeoff: Ari will not run your project.
> The core truth: dbt questions are about the second-order cost of a choice, not the syntax of it. Incremental saves compute and buys you a correctness problem; ephemeral tidies the warehouse and hides logic; macros DRY things up and add indirection. Name both sides and you sound like someone who has maintained a project.
## How to prepare for a dbt interview
- Week 1: build a small project locally on DuckDB — sources, staging, marts, ref() everywhere. Explain the DAG and environment resolution aloud.
- Week 2: materializations. Convert one model between all four and articulate the tradeoff each time in ninety seconds.
- Week 3: incremental models and snapshots. Build one, change its logic, observe the inconsistency, then full-refresh. Add tests at both severity levels and a source freshness check.
- Final week: rehearse the dbt-versus-Airflow and dbt-versus-stored-procedure comparisons, prepare two war stories in first person, and run two full spoken mocks with follow-ups.
Building the rest of the stack? The PySpark interview questions guide covers distributed processing, the Databricks interview questions guide covers the lakehouse, the Airflow interview questions guide covers orchestration, and the Snowflake interview questions guide covers the warehouse dbt most often runs against.
## Frequently asked questions
### What are the most common dbt interview questions?
The most common questions cover why you use ref() instead of hard-coded table names, the four materializations and when each is appropriate, how incremental models work and what is_incremental() does, what happens to existing rows when incremental logic changes, generic versus singular tests and what you would alert on, what snapshots are for, and how dbt compares to Airflow and to stored procedures.
### What is the difference between the dbt materializations?
A view stores no data and computes at query time, suiting light staging models. A table is rebuilt from scratch each run, which is simple and always correct. An incremental model processes only new or changed rows, saving compute on large fact tables at the cost of complexity and correctness risk. An ephemeral model is not built at all and is inlined as a CTE into downstream models. Start with view or table and move to incremental only when cost or runtime hurts.
### What happens when you change the logic in a dbt incremental model?
Nothing happens to the rows already in the table — they keep the old logic, so the table becomes silently inconsistent between historical and new rows. You must run dbt run --full-refresh to rebuild it with the corrected logic. Because it is easy to forget, many teams schedule a periodic full refresh, weekly or monthly depending on table size, as insurance against exactly this problem.
### What is is_incremental() in dbt?
is_incremental() is a Jinja macro that returns true only when the model is being run incrementally — meaning the target table already exists, the model is configured as incremental, and the run is not a full refresh. It lets you wrap a WHERE clause that filters to new or changed rows, so the same file can either build the table from scratch or update it, depending on the run.
### What are dbt snapshots used for?
Snapshots implement slowly changing dimension type 2 by recording how a source row changed over time, maintaining dbt_valid_from and dbt_valid_to columns. They exist because once a source row is overwritten its history is gone permanently, so the change must be captured as it is observed. They run against sources on their own schedule, using either the timestamp strategy with an updated_at column or the check strategy comparing named columns.
### Is dbt a replacement for Airflow?
No — they solve different problems and most teams run both. dbt transforms data inside the warehouse and manages the dependency graph between models, tests and documentation. Airflow orchestrates when jobs run across the whole platform, handles retries and backfills, and typically triggers the dbt job itself alongside ingestion and downstream tasks. Framing them as competitors in an interview is a common mistake.
dbt rounds turn on the second-order cost, and that is a spoken answer. Greenroom runs mock analytics engineering interviews out loud with Ari — tradeoff follow-ups included — and scores structure, clarity and depth. Free to start. Curious how it works? See how AI mock interviews work.