Portfolio case study

Why it matters

For data analyst roles, a portfolio often matters as much as a degree or certificate, especially when you are changing careers. Hiring managers want evidence that you can do the whole job: take a fuzzy question, get and clean data, analyse it correctly, and communicate a recommendation. One complete, well-written case study shows that far better than ten notebooks of tutorial exercises. It also gives you something concrete to talk about in interviews.

Real-world context: many data analyst roles ask for a bachelor's degree (statistics, economics, computer science, business or similar), but employers increasingly accept a strong portfolio and relevant experience. Optional certificates such as the Google Data Analytics Certificate or Microsoft's Power BI Data Analyst (PL-300) can help you get past screening; requirements and exam details change, so check the official sites (grow.google, learn.microsoft.com). Checked on 2026-10-23.

What makes a strong case study

• A real question with a decision attached. "Which neighbourhoods should a bike-share operator add stations to?" beats "Exploring the bike-share dataset".
• Real, messy data. Public sources: government open data portals (data.gov, data.gov.uk, Eurostat), city open data, Kaggle datasets with clear licences, Google BigQuery public datasets, Our World in Data. Avoid the most overused datasets (Titanic, Iris) unless you add something new.
• The full workflow: question, data, cleaning, analysis, visualisation, recommendation, limitations.
• Your judgement on display: why you chose a metric, how you handled missing data, what you ruled out.
• Skills the job asks for: SQL, Python or spreadsheets, a BI dashboard, and clear writing. Check five job postings you would apply for and match them.

A structure for the write-up

Use this outline for the README or blog post:

1. Summary (3 to 5 sentences): question, approach, main finding, recommendation.
2. Context and question: who would use this and what decision it supports.
3. Data: sources with links and licences, time range, size, key fields, and known issues.
4. Method: cleaning steps, metric definitions, analysis techniques (cohorts, a forecast, a test analysis), and why.
5. Findings: three or four, each with one decluttered chart and a takeaway title.
6. Recommendation: what to do, expected impact, confidence.
7. Limitations and next steps: what you could not do and what you would do with more data or time.
8. Repository guide: how to rerun it (requirements file, SQL scripts, notebook order).

Where to publish

• GitHub repository: code, SQL, a clean README with the write-up and charts. Make sure notebooks run top to bottom.
• A short article on a personal site or blog platform, written for a non-technical reader.
• An interactive dashboard in Looker Studio or Tableau Public (public data only) linked from the README.
• A one-page PDF or slide summary to attach to applications.

Never publish data from an employer or school, or any personal information. Respect dataset licences and cite sources.

Worked example outline

Question: Where should a city bike-share add 10 new stations to increase rides? Data: 12 months of public trip records (about 3 million rows) plus station locations and census population by area. Method: SQL in DuckDB to aggregate trips by station and hour; a star schema with fact_trips, dim_station, dim_date; Python for demand per resident by neighbourhood; a simple seasonal forecast of next summer's demand. Findings: stations within 500 m of rail stops have 2.4× the rides; three dense neighbourhoods have no station within 800 m; summer demand is forecast to grow 8% to 12%. Recommendation: prioritise the three unserved neighbourhoods near rail; expected +4% to +7% total rides. Limitations: no data on failed rental attempts (empty docks), so demand at full stations is undercounted.

Interview-ready

Be ready to explain in two minutes: the question, one hard data problem you solved, the key finding and what you would do differently. Interviewers often ask "why did you choose that metric?" and "what would you do with more time?"

Common mistakes

• Code without a narrative, or a narrative without the code.
• No question, just "exploration".
• Default, cluttered charts.
• Overclaiming causation from observational data.
• Notebooks that do not run, broken links or missing data instructions.
• Ten small projects instead of one or two complete ones.

Quick recap

• One end-to-end case study with a real question beats many tutorials.
• Use real public data with clear licences, and show your judgement.
• Write it up with summary, data, method, findings, recommendation and limitations.
• Publish code and write-up, keep private data private, and rehearse a two-minute explanation.

Try it

The Do tab breaks the case study into steps you can complete over a few weeks.