I'm an analytics engineer who builds the layer between messy source data and confident decisions: layered dbt models, star schemas, semantic layers and tests that make sure revenue means the same thing in every report.
Staging views one per source, intermediate models for the awkward aggregations, marts as tables. Everything flows through ref(), so the lineage graph is real documentation: you can see exactly where any number comes from and what breaks if a source changes.
Kimball-style facts and dimensions joined on surrogate keys, with relationships tests enforcing referential integrity. The grain of every table is stated before it's built, because most bad numbers are really grain mistakes in disguise.
Revenue, AOV and repeat rate get one definition in the semantic layer, then every dashboard consumes it. No maths hidden inside report visuals, no three versions of "revenue" arguing in a meeting. I build these as Power BI semantic models over dbt marts.
Keys carry unique and not_null, categoricals carry accepted_values, composite grains get their own tests, and singular tests reconcile the warehouse back to the source system. Legitimate mismatches run at warn severity so they're surfaced, not silenced.
An end-to-end dbt project on the public Olist dataset: 100k real Brazilian ecommerce orders across 9 source tables, modelled into a tested Kimball star schema and used to answer real business questions, each framed as finding, evidence, impact and recommendation.
Customer lifetime value on 1M+ transactions from a UK retailer, built as a dbt project with the machine learning running inside it as Python models. The core finding: this isn't one customer base, it's two, and a single model gets both wrong.