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 9 content (analytical SQL: joins, CTEs, and aggregations; dimensional modeling with grain, facts, and dimensions; star schemas built as PostgreSQL views, with SQL data-quality validation). Other weeks' career pages each cover their week's tool, not this one. 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 June 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.
Analytical SQL is the one skill that shows up in almost every Dutch data posting, across every role. Tools come and go: SQL has been the constant since the 1970s, and a recruiter screening a junior CV looks for it first. But "knows SQL" is cheap. What separates a hireable junior from someone who only ran a SELECT * is the modeling judgment this week teaches: stating the grain of a table, telling a fact from a dimension, building a star schema, and spotting the fan-out bug where a bad join silently doubles a total.
That judgment is what NL analytics teams actually pay juniors to have. Anyone can write a GROUP BY. Far fewer juniors can look at a query that returns suspiciously high revenue and say "that's fan-out, the dimension isn't unique on the join key." This week is where you cross that line.
SQL is near-universal in Dutch data postings. Dimensional modeling (facts, dimensions, star schema, grain) is more specialized: it is the heart of analytics-engineering work, common in data engineering, and lighter for data science and analyst roles, who consume models more than they build them.
| Role | Analytical SQL in postings | Dimensional modeling in postings | What the posting expects |
|---|---|---|---|
| Analytics Engineer (AE) | ~95% | ~80% | Daily. Designing and owning fact/dimension models, defining grain, building a clean staging-to-marts layer. This week is the core of the role. |
| Data Engineer (DE) | ~90% | ~50% | Daily SQL for transformations. Modeling shows up when the DE owns the warehouse layer, less when they stop at ingestion and hand off to AE. |
| Data Analyst (DA) | ~85% | ~30% | Heavy SQL for reporting and ad-hoc questions. Usually queries an existing star schema rather than building one; "understands fact/dim" is a plus, not a requirement. |
| Data Scientist (DS) | ~65% | ~20% | SQL to pull and shape training data. Star-schema awareness helps when joining marts, but modeling is rarely their responsibility. |
The directional shape: analytical SQL is non-negotiable for every role; dimensional modeling is where AE and modeling-focused DE roles live. If you are aiming at Analytics Engineer postings, the grain-fact-dimension-star vocabulary from this week is exactly the language those job descriptions are written in.
SQL itself has no real competitor for querying a warehouse, but the way you write and structure analytical SQL has alternatives that show up in NL postings.
| Approach | Posting frequency | Practical implication |
|---|---|---|
| Raw SQL views / queries (this week) | very common | The baseline. Every data role expects you to read and write analytical SQL by hand. Lead with this. |
| dbt (SQL-as-a-project: tested, version-controlled) | common and rising | The modern way teams organize the same staging-to-marts SQL you built here. You meet it in Week 10. Postings increasingly pair "SQL" with "dbt". |
| BI semantic layers (Power BI, Tableau, Looker / LookML) | common | Some companies model in the BI tool instead of the warehouse. Different surface, same star-schema concepts (facts, dimensions, grain) underneath. |
| ORMs (SQLAlchemy, Django ORM) | operational/app teams | Generates SQL from Python objects. Fine for app CRUD, the wrong tool for analytics. Do not confuse "I used an ORM" with "I write analytical SQL". |
| Stored procedures (T-SQL, PL/pgSQL) | legacy enterprise / banks | Older NL shops run transformation logic in stored procedures. Acknowledge if a posting names it, but it is not your modern-stack headline. |
What this means for your CV: lead with analytical SQL and dimensional modeling (star schema, fact/dim, grain). The star-schema concepts transfer cleanly to dbt and to BI semantic layers, so naming them signals readiness for the modern stack, not just one tool.
Postings phrase the expectation at three levels:
SELECT".This week deliberately previews concepts you will not yet practice at scale: surrogate keys, slowly changing dimensions, materialized views, and dim_date. You can name them in an interview ("I know what a slowly changing dimension is and why surrogate keys exist; I have not yet built a project where they earned their keep") even though Week 9 builds plain views over 57K rows. That honest framing is the right junior register.
<aside> 💡 CV signal line (copy and adapt):
Built a star schema (fact and dimension views) over 57K NYC taxi trip records in PostgreSQL: audited the raw data for nulls, duplicates, out-of-range fares, and broken zone references; designed vw_fact_trips (grain: one taxi trip) and vw_dim_zones (grain: one location, location_id primary key); and validated the join with row-count and referential-integrity checks before reporting borough-level revenue.
Recruiter keywords this carries: SQL, PostgreSQL, analytical SQL, joins, CTEs, aggregations, dimensional modeling, star schema, fact table, dimension table, grain, primary key, foreign key, SQL views, data-quality validation, referential integrity.
</aside>
A weaker line to avoid, for contrast: "Wrote some SQL queries on a taxi dataset." It drops every recruiter keyword and could be claimed by anyone who has run one query. The strong version names the grain, the schema shape, and the specific validation checks.
Three sentences that cover the assignment cleanly when an interviewer asks "tell me about something you have built":
vendor_id plus the two timestamps, counted null location IDs, checked the fare range for negatives, and verified every pickup_location_id actually existed in the zones table, so I knew what I was working with before I built anything on top of it."location_id was unique in the dimension so joining trips to zones could not silently double the fare totals, and I confirmed it with a row-count check before and after the join."Two honest follow-ups if asked "what would you do differently?":
Week 9 is the foundation, not the finished article. After this week you are not yet:
Naming these limits honestly in an interview ("I know where my skills end") reads as more senior than a junior overclaim.
Mark this page indicative, not statistical. The ~XX% figures are placeholders; they 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-9-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.