Week 10 - SQL Transformations with dbt
dbt Setup for Azure PostgreSQL
Week 10 Assignment: Build a Daily Borough Stats Mart with dbt
Week 10 Lesson Plan (Teachers)
Career relevance: Week 10 in the NL data job market
Going Further: Optional Deep Dives
This page answers two questions students ask every week: why am I learning this, and how does it help me find a job?
It is scoped to Week 10 content (dbt: SQL transformations as a tested, documented, version-controlled project; the analytics-engineering workflow). Other weeks' career pages each cover their week's tool, not dbt. Generic NL junior-data career content (salary bands, day-to-day work, what employers do not expect from juniors) lives in one shared page across the curriculum and is not repeated here.
The numbers below are a rough reading of public NL postings as of May 2026. They are indicative, not measured. A separate project crawls Dutch data postings and will replace the qualitative claims here with measured percentages once the dataset is ready; placeholders are marked ~XX% for that swap.
dbt is the dominant transformation tool in NL postings that mention any modern data-stack tool by name. The frequency varies sharply by role: it is a near-must-have for analytics-engineering postings, common-but-not-required for data-engineering, and shows up as "nice to have" or not at all for data-science/-analyst postings.
| Role | Postings mentioning dbt | What the posting expects |
|---|---|---|
| Analytics Engineer (AE) | ~75% | Hands-on dbt: building staging/marts, writing tests, generating docs, working in a dbt build workflow on a Postgres / Snowflake / BigQuery warehouse. dbt is part of the role definition. |
| Data Engineer (DE) | ~45% | dbt as one of several T tools. Postings usually pair it with Airflow/orchestration plus an ingestion stack (Fivetran, Airbyte, custom Python). "Familiarity" or "hands-on" depending on team. |
| Data Scientist (DS) | ~10% | Listed as nice-to-have where the DS team owns its own marts. More common at smaller companies where roles overlap with AE work. |
| Data Analyst (DA) | ~15% | Increasing: analyst-engineer hybrids are common at scale-ups. Usually phrased as "comfortable with" or "willingness to work in" rather than deep ownership. |
The directional shape: AE is where dbt is non-negotiable; DE roles often expect it; pure DS/DA roles typically do not, but exposure helps. If you are aiming at AE postings specifically, dbt is the single highest-leverage tool to put on the CV.
The transformation-tool market in NL postings is heavily concentrated on dbt, with a long tail of legacy and warehouse-native tools.
| Tool | Posting frequency | Practical implication |
|---|---|---|
| dbt (Core or Cloud) | by far the most common | Lead with this on a CV. The recruiter keyword is just "dbt". |
| Coalesce | rare-but-rising | Visual, schema-driven; SaaS analytics-engineering platform. Niche but growing in enterprise NL. |
Snowflake-native (MERGE + Tasks + Streams) |
uncommon | Mostly seen at companies fully on Snowflake without a transformation framework: usually they then introduce dbt. |
| BigQuery dataform (Google's dbt-alike) | rare | Bundled into GCP. If a posting mentions GCP heavily, dataform may show up; dbt-postgres / dbt-bigquery skills transfer cleanly. |
| SSIS / Informatica / Talend / Pentaho | legacy enterprise / banks | Older shops still hire for these. Different paradigm (visual ETL, not SQL+git). Do not list as your modern-stack skill, but acknowledge it if a posting names one. |
| Stored procedures (Postgres / SQL Server) | uncommon-as-primary | Some teams have SP-heavy legacy code under active maintenance. Not a CV-headline skill. |
What this means for your CV: lead with "dbt", mention the warehouse you targeted (dbt-postgres is what you used; teams running BigQuery / Snowflake recognise the workflow as portable), and skip the legacy ETL tools unless the posting asks for one.
Postings phrase the expectation at three levels:
The chapter explicitly previews incremental and snapshot so you can name them in interviews ("I know what they are, I have not yet built a project where they earned their keep") even though Week 10 does not practice them at scale. That honest framing is the right junior register.
Strong line a student can copy-adapt:
Built a dbt-Core analytics project on Azure PostgreSQL: layered staging/intermediate/mart models for NYC TLC trip data, with
not_null/unique/relationships/accepted_valuestests, a unit test for thepayment_type_labelmapping logic, a snapshot tracking SCD Type 2 zone history, anddbt docs-generated lineage. Followed thedbt buildworkflow with model-tests interleaved on every run. Reproducible from a public reference repo with CI.
Recruiter keywords this carries: dbt, dbt Core, PostgreSQL, staging, marts, fct/dim modelling, dbt tests (not_null, unique, relationships), unit tests, snapshots, SCD Type 2, dbt docs, lineage, CI.
Weaker alternative for contrast (avoid):
Used dbt to transform some data.
The weaker version drops every recruiter keyword and could be claimed by anyone who has ever run dbt run once. The strong version names the specific tests, the specific patterns, and the specific deliverables.
Three sentences that cover the assignment cleanly when an interviewer asks "tell me about a project you have built":
stg_trips, stg_zones) clean and rename source columns, a single mart (fct_trips) joins them and folds zone attributes inline OBT-style, and dbt tests assert the data contracts on each layer."payment_type_label case statement: I wanted to be sure the mapping from TLC payment codes to human-readable labels could not silently drift, so I mocked rows for each code and asserted the labels."dbt build as the canonical command rather than dbt run then dbt test separately, so an upstream test failure stops the mart from being rebuilt on top of bad data: that's the most common dbt-junior mistake I wanted to avoid making in code review."Two honest follow-ups if asked "what would you do differently?":
fct_trips is full-refresh on every run because the dataset fits in memory; in production I would switch it to incremental once the row count or rebuild time crossed the threshold where a full rebuild blocked downstream consumers: Week 10 does not practice that change because the dataset is too small for it to matter."Week 10 is the foundation, not the finished article. After this week you are not yet:
view vs table and have heard of incremental; you have not tuned the warehouse-specific +pre-hook, partitioning, or clustering options that real performance tuning requires.These are the senior-shaped skills the chapter does not yet make you qualified for. Naming them honestly in an interview ("I know where my skills end") is more impressive than a junior overclaim.
Mark this page indicative, not statistical. Numbers will be replaced with measured percentages once the postings-crawler project ships.
<aside> 💭 For generic NL junior data-career content (salary bands, day-to-day work, what employers do not expect from any junior), one shared page across all weeks is the right home. That page does not exist yet; for now, treat this page as Week-10-specific only.
</aside>
The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*
Built with ❤️ by the HackYourFuture community · Thank you, contributors
Found a mistake or have a suggestion? Let us know in the feedback form.