Describe the role of dbt in a modern analytics stack

What's really being asked

This question probes your understanding of the modern data stack's architecture, specifically the shift from ETL to ELT. The interviewer wants to see if you can articulate the value of separating the transformation step and applying software engineering discipline (version control, testing, CI/CD, documentation) to analytics code. It's a test of your knowledge of current best practices in data engineering and analytics.

The full answer

A strong answer will cover four key points. First, define dbt's role as the 'T' (transformation) in an ELT (Extract, Load, Transform) paradigm, clarifying that it operates after raw data is already loaded into a data warehouse. Second, explain its core philosophy: empowering analysts and engineers to write modular, reusable data models using SQL, enhanced with Jinja for templating. Third, contrast this with traditional ETL scripts, which often mix extraction, transformation, and loading logic in a single, monolithic script, making them brittle and hard to maintain. Fourth, differentiate it from orchestrators like Airflow; Airflow is for scheduling and managing dependencies between tasks (it can run a dbt job), whereas dbt is for defining the transformation logic and dependency graph within the data models themselves.

The mistakes people make

A major red flag is describing dbt as a complete ETL tool that handles extraction and loading. This shows a fundamental misunderstanding of the ELT pattern. Another common mistake is equating dbt with a workflow orchestrator like Airflow or Prefect. Saying 'dbt replaces Airflow' is incorrect; they are complementary tools, where Airflow often orchestrates dbt runs as part of a larger pipeline. Finally, a weak answer just says 'it lets you write SQL' without explaining the surrounding framework of testing, documentation, and version control that provides the real value.

What usually comes next

Be prepared for follow-ups like: 'How would you integrate dbt into a CI/CD pipeline?', 'When would you not use dbt, and choose a Python-based transformation tool like Pandas or Spark instead?', or 'Describe how you would structure a dbt project for a new business unit.'

A concrete example

Instead of a complex Python script that pulls from an API, transforms data in memory with Pandas, and then writes to a database, the modern approach is different. An ingestion tool like Fivetran (E+L) loads raw API data directly into a Snowflake warehouse. Then, dbt (T) runs a series of SQL models inside Snowflake to clean, join, and aggregate this raw data into a final fct_user_sessions table. This dbt project is stored in Git, has automated tests to check for null user_ids, and is run on a schedule by an Airflow DAG.