How to Build a Data Engineer Portfolio That Actually Gets UK Interviews

Most beginner Data Engineer portfolios in the UK look the same: a Jupyter notebook that cleans a CSV, a README that says “data pipeline project”, and nothing that actually runs on a schedule. UK recruiters and hiring managers open dozens of these, and a notebook alone almost never leads to an interview, because it does not prove you can build the thing the job actually pays for: a pipeline that keeps working when nobody is watching it.

A Data Engineer portfolio has one job: convince a hiring manager, in a few minutes of looking at a repo, that you can build and run production-shaped infrastructure without supervision. This guide covers the projects that do that, how to structure the repository, and the README rules that convert into interviews. If you have not mapped the toolchain yet, our Modern Data Stack guide covers what each tool is for.

Why Most Beginner Data Engineer Portfolios Get Ignored

Before the project list, it helps to know what makes a reviewer stop looking. The recurring problems:

• a notebook that cleans data once, with no schedule, no orchestration, and no sign it would survive a second run
• a “pipeline” that is really just a Pandas script with no tests and no failure handling
• no orchestrator anywhere, despite it appearing in the majority of UK Data Engineer job adverts
• hardcoded credentials or config committed to the repo, which is an instant credibility problem
• a README that describes the code instead of the data problem it solves

If a reviewer has to guess what the project is for, they move on to the next repository.

The 4 Projects UK Recruiters Expect to See

You do not need ten repositories. You need one coherent project, ideally split across clearly documented stages, that proves you can ingest, transform, orchestrate, and ship data infrastructure end to end.

1. An Ingestion and Cleaning Layer From a Genuinely Messy Source

Pick a public dataset that is not already tidy: an API with pagination and rate limits, a set of inconsistent CSVs, or scraped data with missing fields. Write the ingestion as a proper script or module, not a notebook cell, with logging and basic error handling. This is the project that proves you can handle data as it actually arrives, not as it appears in a tutorial.

2. A dbt Project With Tests and Documentation

Load your raw data into a free-tier warehouse (BigQuery sandbox or a local Postgres instance both work) and build a dbt project that transforms it into clean, modelled tables. Add dbt tests for uniqueness, nullability, and referential integrity, and generate the documentation site. This is the project recruiters open second, and the one that shows you think about data quality rather than just moving data around.

3. An Orchestrated, Scheduled Pipeline

Wrap the ingestion and dbt steps in an Airflow DAG (or a Dagster job, if you want to signal familiarity with the newer tool). Add retries, basic alerting on failure, and a sensible schedule. This is the single biggest differentiator between a beginner portfolio and one that reads as production-shaped. Our dbt vs Airflow vs Dagster comparison covers which to build first if you are short on time.

4. A Containerised, Reproducible Setup

Package the project with Docker so a reviewer can run it in minutes rather than fighting your local environment. Extra credit for a short Terraform script that provisions the warehouse or storage bucket the pipeline depends on, even if it only runs against a free-tier account. This is what separates “I built something once” from “I can hand this to a team.”

How to Structure the GitHub Repo

Keep the structure predictable so a reviewer can navigate it without asking you questions:

• README.md at the root, the only file most reviewers actually read in full
• /dags or /orchestration, the Airflow or Dagster definitions
• /models, the dbt project
• /ingestion, the scripts or modules that pull raw data
• /infra, any Docker or Terraform files
• /docs or a diagram embedded in the README, showing the pipeline shape at a glance

Never commit credentials, large data dumps, or a half-finished branch as the default one. Do commit a .env.example file and a clear list of what needs to be configured to run it.

The README Rules That Convert Into Interviews

A strong Data Engineer README answers these questions, in this order:

1. What data problem does this pipeline solve, and where does the data come from?
2. What does the architecture look like? (a simple diagram beats a paragraph here)
3. What tools does it use, and why those specifically?
4. How is data quality checked? (link to your dbt tests)
5. What would you add with more time: monitoring, a second source, CDC, streaming?
6. How does someone else run it? (this should genuinely work if they try it)

Write it for a technical reviewer skimming quickly, not for someone who will read every line of code. The diagram and the “how to run it” section do most of the work.

Where to Host the Portfolio

• GitHub for the code, DAGs, and dbt project, with a clean commit history rather than a single dump
• A short architecture diagram (Excalidraw or similar, embedded as an image) so the design is visible without reading code
• dbt docs, generated and hosted for free via GitHub Pages, so the data model is browsable
• A one-page summary linked from your CV and LinkedIn, pointing at the repo and the diagram

One clear link at the top of your CV, pointing at the strongest project, is what most hiring managers actually click.

Common Mistakes to Avoid

• shipping a notebook and calling it a pipeline
• using a toy Kaggle CSV with no real messiness to clean up
• skipping tests entirely, which signals you have not worked with production data quality expectations
• no orchestrator, despite it appearing in the large majority of UK Data Engineer adverts
• a README that lists technologies used but never explains the actual data problem

A 6-Week Plan to Build the Portfolio From Scratch

• Weeks 1 to 2: ingestion and cleaning layer against a genuinely messy public dataset
• Weeks 3 to 4: dbt project with models, tests, and generated documentation
• Week 5: Airflow (or Dagster) DAG orchestrating the full pipeline on a schedule, with basic alerting
• Week 6: Docker packaging, a simple architecture diagram, and the README that ties it together

This assumes roughly 8 to 10 focused hours a week, the same pace described in our Data Engineer roadmap.

The Honest Summary

A strong Data Engineer portfolio is not a notebook, it is a small, working system: real ingestion, tested transformations, an orchestrator running it on a schedule, and a README that lets someone else run it too. One project built to that standard beats five notebooks every time, because it is the closest thing to the actual job a recruiter can evaluate before an interview.

Frequently asked questions

Read next

• Data Engineer Interview Questions UK (2026, with Honest Answers)
• Data Engineer Salary in the UK: Junior to Senior Pay in 2026
• What Does a Data Engineer Actually Do All Day? (An Honest Account)