Talk through a data project in an interview: a structure that works

"Tell me about a project you are proud of" is one of the most common questions in a data interview, and one of the most often answered badly. The usual mistake is to describe the tools in the order you used them. The interviewer is listening for something else: whether you can explain a piece of work clearly, what decisions you made and why, and whether you know what your results do and do not show.

A six-part outline

Prepare one or two projects with this structure. It is close to the well-known situation, task, action, result pattern, adapted for analytical work:

1. Context. Who needed the answer and why, in one or two sentences. The support team wanted to know why ticket volume rose every Monday.
2. The question. Stated so that it has an answer. Which ticket categories drive the Monday increase, and is it new demand or a backlog from the weekend?
3. The data and its problems. Where it came from, roughly how much, and the one or two problems you had to deal with. Two years of tickets from the help desk export; categories were renamed halfway through, so I mapped the old names to the new ones.
4. Your approach and one decision. The main steps, then a choice you made and the alternative you rejected. I compared Mondays with the average weekday rather than with Sundays, because the weekend has no staff and would exaggerate the rise.
5. The result. What you found, with a number, and how you know it is right. Two categories explained most of the increase, and almost all of those tickets had been created on Saturday or Sunday. I checked the totals against the help desk's own monthly report.
6. What happened next and what you would change. The decision it informed and an honest limitation. The team added a weekend triage shift. I would have liked to measure whether resolution times improved, but the project ended first.

Spoken aloud, that takes about two minutes, and every part invites a good follow-up question.

Put the decisions in the middle

The part interviewers remember is the decision. Anyone can say they cleaned the data and built a chart; few explain why they chose one comparison over another, or why they dropped a model that looked good. Prepare one decision per project and the trade-off behind it.

Be precise about results

Say what you measured and how sure you are. If the result is a correlation, call it that. If the sample was small, say so before you are asked. Being exact about the limits of your own work is one of the clearest signals of experience.

Prepare for the follow-ups

The first telling is an invitation. Expect questions such as:

• How did you check the numbers were right?
• What would you do differently with more time or more data?
• Who used the result, and how did you present it to them?
• What was the hardest part, and why?
• If the data had been ten times larger, what would break?

Have a short, honest answer for each. If one exposes a weakness in the project, that is fine: say what you would do now.

Practise out loud

Tell the story to a friend or record yourself. Most people find their first version is too long in the set-up and too short on the result. Cut the context to two sentences, and make sure the number and the decision are both said clearly. Bring a simple sketch of the steps if a whiteboard or shared screen is offered; a picture of the flow often answers three questions at once.