Hire a dbt developer

• Structures the project: sources, staging, intermediate and mart layers with clear naming.
• Writes models in SQL (and Jinja macros where they help), with incremental models for large tables.
• Tests: unique and not-null keys, relationships, accepted values, freshness, and custom tests on business rules.
• Documents models and metrics so analysts and AI tools can find and trust them.
• Manages CI (slim CI on changed models), environments and deployment, in dbt Cloud or dbt Core with an orchestrator.
• Keeps warehouse cost down: materialisation choices, incremental strategies, model run times.

• Dashboards disagree on revenue, customers or churn.
• Business logic lives in BI tools and spreadsheets, copied many times.
• A dbt project exists but runs are slow, flaky or untested.
• You're moving off stored procedures or a legacy ETL tool onto dbt.
• You want AI assistants or a semantic layer to answer questions from your warehouse, and need clean, documented models for that.

A data engineer gets data into the warehouse reliably (ingestion, orchestration, platform). A dbt developer turns it into models the business uses. Small teams often need one person who does both; say which you need more of. See hire a data engineer and hire an analytics engineer.

• Grain and definitions first, SQL second.
• Tests where failure would mislead someone, not a test on every column.
• Small, readable models over one giant model.
• Knows when incremental is worth the complexity.

• "Walk me through how you'd structure a dbt project for orders, customers and subscriptions." Strong: staging per source, intermediate for joins and business logic, marts by consumer, consistent naming, one place for each definition.
• "A model that used to take two minutes now takes forty. What do you check?" Strong: materialisation, full refresh vs incremental, upstream fan-out, warehouse query profile, clustering or partitioning.
• "Explain an incremental model. What goes wrong with them?" Strong: is_incremental, unique_key and merge strategy, late-arriving data, schema changes, when to full-refresh.
• "How do you stop a model change breaking twenty dashboards?" Strong: CI on changed models and their children, model contracts and versions, exposures, communicating deprecations.
• "Snapshots: when and why?" Strong: tracking history of mutable source records (type 2), with a sensible check or timestamp strategy.
• "How would you set up the dbt semantic layer or metrics?" Strong: defines entities, measures and dimensions once; knows the trade-offs vs defining metrics in the BI tool.

• Every model is a table; nothing incremental on large data.
• No tests, or hundreds of tests nobody looks at.
• Macros for everything, making SQL unreadable.

dbt Core / dbt Cloud · Snowflake · BigQuery · Databricks · Redshift · Postgres · Fabric · Airflow / Dagster / Prefect · Fivetran / Airbyte · Git and CI · dbt packages (dbt_utils, dbt_expectations) · semantic layer · Power BI / Looker / Tableau downstream.

Option 1: post a role. Post your role free: permanent, contract or fractional; remote or on-site; the country and your overlap hours. See applicants ranked by fit. Vetted profiles show a vetting report from Carbon's real-world data experience test (scenario-based, not a coding test), a working-style profile and a short video intro. Interview with a guide tailored to the role and the candidate, then agree the rate, draft the contract and sign on the platform. Option 2: test someone you found. Already have a candidate? Test a candidate you found on Carbon before you make an offer. ID checks are available on Team and Scale.