Loading…
What separates a strong analytics-engineering portfolio from a collection of notebooks — what to include, what to leave out, how to present it on GitHub, and how to walk through it in an interview.
These six areas reflect recurring portfolio-review themes. Individual employers may weigh them differently.
Familiar datasets can still support a useful portfolio project when the work adds realistic grain, validation, and communication. Prefer scenarios involving orders, inventory, events, or metric definitions when you want to demonstrate analytics-engineering decisions.
A 200-cell notebook is not a portfolio piece. A portfolio piece is a Git repo with sources, staging models, intermediate models, marts, tests, docs, and a README. If a stakeholder can't read your README and understand what you built, the project isn't done.
Demonstrate engineering rigor by testing declared keys, important relationships, and business rules. Document the mart's grain, measures, dates, and fields consumers need to interpret correctly.
Five logical commits — sources, staging, marts, tests, docs — read better than a hundred wip commits. Use a feature branch, open a real PR against main, and merge with the PR body explaining what the project does.
A dbt project is invisible without an output. Add a tiny published Looker or Streamlit dashboard, or a documentation site (dbt docs generate + GitHub Pages). The hiring manager sees the chart first, then the SQL.
Don't claim production scale you didn't ship. The strongest portfolio framing is 'I built this project to learn X, and here's what I learned.' Hiring managers respond to the learning narrative more than to inflated stakes.
A clean repository structure is the easiest signal to send. Match this layout and a reviewer can skim your project in 90 seconds.
The first thing anyone reads. Lead with a 1-paragraph scenario, then the architecture diagram (source → staging → marts), then 'how to run this locally', then 'what's tested', then 'what I learned'.
Declare every raw table. Freshness checks where relevant. Source tests for not-null on PKs.
One file per source table. Standardize names, types, units. Document every column.
Business logic that isn't yet a final mart — joining staging tables, building rolling aggregates, etc.
The shipped tables. Use a star schema when the reporting grain and reuse requirements fit; document any different design and its trade-offs.
Singular tests for anything generic tests don't cover. Edge cases worth pointing out in the README.
Only if you have one; macros for the sake of macros are a red flag. A small reusable helper is a green flag.
Each one is a self-contained business scenario with realistic source tables and a clear final mart layer. Together they cover SQL, data modeling, and a full dbt+BigQuery build.
Metric-layer recovery and analytics debugging project (dbt + BigQuery)
E-commerce orders, inventory, and revenue modeling project
Event and performance analytics modeling project
Prepare a 90-second answer for each. Open your repo, share your screen, and click while you talk. Show, don't just describe.
Open the README. Read the scenario in your own words (90 seconds). Show the architecture diagram. Click into one mart model and explain what it answers. Click into one test and explain why it exists. End with what you'd change if you started over.
The honest answer wins. 'I wanted to practice star-schema design on something with realistic joins.' 'I wanted to ship a dbt project end-to-end from sources to docs.' Don't oversell — the hiring manager has seen the same five Kaggle datasets a hundred times.
Always have an answer ready. Examples: 'I'd add incremental models for the largest fact table.' 'I'd separate test data from production data with a dbt seed.' 'I'd add a freshness check on the orders source.' Showing self-critique is the strongest signal you can give.
Pick a real technical problem. Slowly-changing dimensions, late-arriving facts, a join that exploded the row count. Walk through how you diagnosed and fixed it. This is the question that separates good portfolios from great ones.
Pick a project, work through it end-to-end, and push it to GitHub. The capstone in the full course takes most students 20–40 hours and produces a portfolio piece you can talk through in any AE interview.
A screenshot or two of the output. A link to the dbt docs site if you've generated one.
Investigative SQL: follow the evidence across museum audit logs to unmask a thief.