Describe dbt's role and how it differs from traditional ETL

WHAT THIS TESTS: This question probes whether you understand the modern analytics architecture and the separation of concerns between transformation logic, orchestration, and compute. Interviewers want to see that you know dbt is not just a query runner but a framework that brings software engineering discipline to analytics, and that you can clearly distinguish its declarative, in-warehouse approach from imperative Python scripts or general-purpose schedulers.

A GOOD ANSWER COVERS: First, position dbt as the transformation layer that executes SQL directly inside the cloud data platform, turning raw warehouse data into trusted data products. Second, explain that dbt uses SQL select statements and Jinja templating to create modular data models, while automatically generating lineage, tests, documentation, and contracts. Third, contrast this with traditional Python ETL where you write imperative code to extract, transform, and load data using external compute, which is harder to maintain and lacks built-in governance. Fourth, clarify that Airflow is an orchestrator that schedules and monitors task graphs but has no native understanding of data models, columns, or transformation semantics, whereas dbt manages the transformation graph and dependency resolution natively. Fifth, note that dbt complements rather than replaces Airflow, since Airflow can trigger dbt jobs while dbt handles the transformation logic.

COMMON WRONG ANSWERS: A major red flag is saying dbt replaces Airflow entirely, which reveals confusion about the boundary between orchestration and transformation. Another mistake is describing dbt as merely a SQL scheduler or runner, missing its framework features like testing, version control integration, and CI/CD. Candidates also err by claiming Python ETL is always superior for complex logic; a nuanced answer acknowledges dbt supports advanced use cases through macros and hooks while still keeping the workflow SQL-first.

LIKELY FOLLOW-UPS: Expect the interviewer to ask how you would handle transformations that are difficult to express in SQL. They may also ask how you enforce data contracts between teams, or how you optimize models to reduce warehouse compute costs. Another common thread is how dbt integrates with other data tools given its structured context of lineage, tests, and documentation.

ONE CONCRETE EXAMPLE: Imagine a company that has loaded raw transaction records into their cloud data platform. With dbt, an analyst writes a staging model that cleans and deduplicates records using a SQL select statement with Jinja templating. The dbt engine compiles this project, executes the transformation graph in the warehouse, and produces metadata showing that a downstream revenue_summary model depends on this staging table. Built-in tests assert uniqueness on transaction_id and referential integrity to a customers dimension. In a traditional Python ETL approach, an engineer writes imperative code to pull data out of the warehouse into external compute, transform it, and load it back, which fragments lineage and requires manual testing and documentation. Airflow could schedule either workflow, but without dbt it would only trigger a task blind to the schema and dependencies inside the script.

Source: docs.getdbt.com