Data interviews

How to talk through a data project in an interview

Almost every data analyst and data engineer interview asks you to walk through something you’ve built. Here’s how to tell it so the interviewer hears your decisions, not just your tools.

By the Deeplink Interview teamLast reviewed 7 minute read

At a glance

Written for
Graduates and career changers applying for data analyst and data engineer roles
Reading time
7 minutes
Questions to practise
10 in our practice bank

The short answer

Tell it in five parts: the question the project answered, the data and what was wrong with it, the decisions you made and why, how you checked the result, and what happened because of it, plus what you’d do differently. Lead with the question, not the dataset or the tools. Have a one-minute and a three-minute version ready, because interviews ask for both.

Why do data interviews ask about your projects?

A project is the closest thing an interviewer has to watching you work. Anyone can list SQL and Python on a CV. Talking through a project shows whether you can turn a vague question into an analysis, cope with messy data, make sensible choices and explain them to someone else. For graduates and career changers, who may not have a data job to point to yet, it’s often the single most important answer in the interview.

It comes in different forms:

  • “Walk me through a data project you’re proud of.”
  • “In about a minute, describe one piece of data work you’ve done.”
  • “Tell me about your take-home task.” (at a second stage)
  • “What’s on your GitHub? Pick one and talk me through it.”
  • For data engineers: “Walk me through a pipeline you’ve built.”

The same structure works for all of them.

The five-part structure

PartWhat to sayRough share of a three-minute answer
The questionWhat you were trying to find out, and who wanted to know20 seconds
The dataWhere it came from, how big, and what was wrong with it30 seconds
Your decisionsTwo or three choices you made, and why70 seconds
The checkHow you knew the answer was right30 seconds
What happenedThe finding, what someone did with it, and what you’d change30 seconds

The middle part carries the answer. Tools belong inside the decisions (“I used a left join so stops with no complaints still showed up”), not in a list at the start.

Start with the question, not the dataset

“I used a Kaggle dataset of 50,000 rows” is a weak opening because it says nothing about why. “I wanted to know whether late buses were getting worse in the evenings, because my route home seemed to be” gives the interviewer a reason to care and a thread to follow. If the project was coursework, say what the question was, not just the module name.

Be honest about the data

Every real dataset has problems, and interviewers know it. Missing values, duplicates, a change in how something was recorded halfway through, codes nobody explained. Naming one or two problems and how you handled them is some of the strongest evidence you can give. Claiming the data was clean suggests either that you didn’t look or that the project was a tutorial.

Show decisions, with reasons

This is where you stand out. Good decisions to talk about:

  • Cleaning rules: what you dropped, what you kept and flagged, and why.
  • Definitions: what counted as “late”, “active” or “a customer”, and why that definition.
  • Joins: which tables, which key, and how you checked you didn’t lose or double rows.
  • Metrics: why a median rather than a mean, a rate rather than a count, a percentage point rather than a percentage.
  • For pipelines: why batch or incremental, how reruns stay safe, what happens when a file is late.

Say how you checked it

Interviewers listen hard for this, because it’s what separates analysis they can trust from analysis they’d have to redo. Totals that match another source, a sample checked by hand, row counts before and after each join, a result that made sense against something you already knew. One concrete check, with a number, is enough.

Land the result, and what you’d change

What did you find? Did anyone act on it? If it was a personal project, what would you do if it were your job? Then add one honest improvement: a better data source, a test you’d add, a question you’d ask first. It shows judgement and heads off the most common follow-up.

A worked example

Worked example“Walk me through a data project you’re proud of.”A history graduate applying for a junior data analyst role at a council, from a self-directed project
Question
I wanted to know whether missed bin collections in my city were concentrated in particular streets, because my street seemed to be missed every few weeks.
Data
Two years of missed collection reports from the council’s open data portal, about 18,000 rows, plus the street list with ward names. Around 6% of reports had no street name, and some streets were spelled three different ways.
Decisions
I standardised street names with a small lookup table rather than fuzzy matching, because I could check every change by eye. I kept the 6% with no street in the totals but out of the street ranking, and said so. I counted missed collections per 1,000 households rather than raw counts, because big streets would always top a count.
Check
My monthly totals matched the council’s published figures to within 1%. I checked the top ten streets by hand against the raw reports.
What happened
Nine of the top twenty streets were on one collection round, all narrow terraced streets where parked cars block the lorry. I sent a two-page summary to my councillor, who passed it to the waste team. If I did it again, I’d ask the council for the round data first instead of working it out from the streets.

Why it works: the question is personal and plain, the data problems are specific, each decision has a reason, the check has a number, and the ending has both an outcome and a lesson.

How to fit it into one minute

Some interviews, especially first rounds and one-way video interviews, give you about a minute. Keep the same five parts but give each one sentence:

“I wanted to know whether missed bin collections cluster in particular streets. I used two years of the council’s open data, about 18,000 reports, cleaned the street names and measured misses per 1,000 households so big streets didn’t dominate. My totals matched the council’s figures within 1%. Nine of the worst twenty streets were on one round, all narrow terraces, and the waste team is now looking at it.”

That’s about 70 words, which is roughly 30 seconds at a calm pace. It leaves time for a breath and a sentence on what you’d do next.

What follow-up questions should you expect?

After your first answer, a live interviewer will usually pick one part and dig. Prepare for these:

  • “Why did you choose that approach over [another one]?”
  • “How did you handle the missing values?”
  • “How do you know the join didn’t duplicate rows?”
  • “What would you do with ten times the data?”
  • “If you started again tomorrow, what would you do differently?”
  • “What would you do next with this?”
  • “Who was the audience, and how did you present it to them?”
  • For engineers: “What happens if the job runs twice?” or “What if the file arrives late?”

The guide to follow-up questions covers how to answer when you’re pushed further than you prepared for.

Common mistakes

  • A tour of the tools. “I used Python, pandas, Matplotlib and Tableau” tells the interviewer nothing about your thinking.
  • Too much set-up. Two minutes on the background leaves no time for the decisions.
  • Pretending the data was clean. It wasn’t. Say what was wrong and what you did.
  • No check. “And the result was 23%” with no sense of whether it’s right invites the hardest follow-up.
  • Group work with no “I”. If it was a team project, say clearly which part was yours.
  • A tutorial project told as original. If you followed a course project, say so, and talk about what you changed or added. Interviewers recognise the famous datasets.
  • Screen share chaos. If you share your screen, have the right file open and zoom in before you start.

What makes a good project to talk about?

If you’re still choosing, pick the one where you made the most decisions yourself, not the one with the most impressive tools. Good signs: a question you genuinely wanted answered, data you had to clean, a result someone could act on, and at least one thing that went wrong. UK open data (councils, transport, health, the ONS) makes for projects interviewers can relate to. For help building a portfolio, Deeplink Coaching has a guide to data analyst portfolio project ideas.

Practice checklist

Work through these before the real interview. Each one is something you can do, not just read about.

  • Pick one project you can talk about for ten minutes without notes. One deep project beats three shallow ones.
  • Write the project’s question in one plain sentence that a non-analyst would understand.
  • List three decisions you made (a cleaning rule, a join, a metric definition) and the reason for each.
  • Write down how you checked the result, with at least one number you compared against.
  • Prepare a one-minute version and a three-minute version, and time both out loud.
  • Answer “what would you do differently?” and “what would you do next?” before anyone asks.
  • Check you can open the project and find any file in it quickly, in case you’re asked to share your screen.

Questions to practise

These include every question in our “Projects and take-home debriefs” practice set. Each has its own page with what it’s really asking and an example outline. Then practise it out loud, with thinking time and a timed answer.

Go further

Written by the Deeplink Interview team and last reviewed 29 September 2026. The examples are invented to show the shape of a good answer: yours should come from your own experience, in your own words. This is general practice advice, not linked to any employer, and not a prediction of any hiring decision. How we write these guides.

Keep reading

All interview guides

Now say it out loud

Reading helps, but answers improve when you say them. Practise on camera with thinking time and a timed answer, or talk it through with an AI interviewer that asks follow-up questions, then read written feedback on each answer. Free to start, with no card needed.

Start practising freeBrowse interview questions