Explain a Data-Analysis Project in an Inter­view

A data-analysis project walkthrough is an explanation of how you moved from a question to a finding. It is not a tour of every chart you made or a list of software names. Choose a real project you can discuss and make the reasoning traceable: what you were trying to learn, what you examined, what you did and what the result can support.

For choosing and presenting work samples, use our portfolio walkthrough guide. This guide goes deeper into the explanation of one analysis, including its limitations. Follow any interview brief before using the prompts below.

Start with the question, not the tool

Write the question your project actually addressed in one sentence. Then name its context: paid work, study, volunteering or a personal exercise. Say whether you defined the question, received it from someone else or worked with others to refine it.

Avoid making the task sound larger than it was. Comparing two sets of records is not the same as discovering why they differ. If you only produced a descriptive summary, call it that.

The National Careers Service interview advice recommends preparing examples from past experience and reading the job description. Using the role description to choose relevant evidence does not mean claiming experience you lack.

Describe what the data represented

Before naming your method, explain what one row, entry or observation meant. Note the source, period covered and the information available to you. Leave out names, internal figures and the dataset itself unless you are sure you may share them.

Use these preparation questions:

• What was included, and what was outside the scope?
• Was the data collected for this question or originally for another purpose?
• Which fields did you use, and what did their labels mean?
• Were any entries missing, repeated or unclear?
• What could you not establish from the available records?

Describe checks you actually made. Do not add a cleaning or validation step because it sounds expected. If another person prepared the data, credit them and explain what you checked yourself.

Explain one choice and its effect

Choose a decision you can explain without hiding behind a tool name. It might be how you grouped records, which period you compared, how you treated missing entries or why you chose a particular chart. Say what you did, your reason at the time and any limitation it introduced.

Keep the original decision separate from what you would do now. If you did not consider another method then, say so plainly. Fictional sample wording, usable only if it is true for you: “I did not compare alternatives at the time; that is something I would examine next.” Do not invent a sophisticated selection process after the event.

If asked about a technique you did not use or cannot explain, state that limit. This is interview preparation, not a substitute for learning or checking a technical method.

Separate finding, interpretation and action

Prepare three distinct statements:

• Finding: what your analysis showed within the records you examined.
• Interpretation: what you thought it might mean, including uncertainty.
• Action: what someone actually did afterwards, if you know.

A chart being delivered is not evidence that a team used it. A difference between groups does not by itself establish its cause. Avoid claiming a business improvement unless you have evidence connecting your work to that outcome. An unfinished analysis or an unknown outcome can still be described honestly.

Work through a fictional example

This entire illustration is fictional, not a real candidate, dataset or result. It shows how to separate a finding from a claim the data cannot answer.

“In a personal spreadsheet exercise, I used invented records for two library workshops. The question was how many bookings had a recorded attendance status. Each row represented one booking. I checked for repeated booking identifiers and blank status cells, then counted the recorded statuses separately for each session. I left blanks as unknown rather than calling them absences. The summary showed that some bookings had no status recorded. It could not tell me whether those people attended, or why the entries were blank. I made a chart of the recorded categories; nobody used it to make a real library decision.”

Do not borrow that experience as your own. In your real answer, identify any calculations, checks or decisions made by teammates or supplied by a course. Explain only the part you can substantiate.

Rehearse the questions behind your conclusion

Ask a practice partner to interrupt with invented practice questions such as “What does that count include?”, “What did you leave out?”, “How did you check it?” and “What would change your interpretation?” Answer from your real notes, not from a memorised success story. If you no longer remember a detail, say so.

Use only material you are permitted to share. If you are unsure, do not share the records. Describe the approach in general terms, leaving out confidential detail, or choose another example. Removing names does not establish permission. Do not put confidential or private datasets or notes into any practice or AI tool. If you practice with another person, agree with them before recording and before sharing any recording. In a real interview or assessment, do not use any tool to generate answers unless the organiser has explicitly allowed it.

Before finishing, check that your answer links the question to the data, your choices and the limits of the finding. This guide is published by Muqabala. You can visit our interview practice page for your next practice session. Use a truthful example and non-sensitive notes. No particular framework or answer guarantees an interview outcome.