How to explain a data analyst project in an interview

A list of SQL, Python and dashboard tools does not explain how you think. Choose one project where you can connect a business question to data, a method and a decision. The interviewer should understand why your analysis was useful even before you name the software.

Open with the question

Try one sentence: “The operations team wanted to understand why repeat support requests were increasing.” This is a fictional example, but it illustrates a concrete decision context. Compare it with “I analyzed a large dataset,” which says little about the work.

State who would use the result and what they could change. If the work was exploratory, say so. Do not retrospectively turn an exploration into a tightly scoped experiment.

Describe the data before the method

Prepare the unit of analysis, time window, source tables and main exclusions. Could one customer create multiple records? Were missing values meaningful? Did the definition of an event change? How did you detect duplicate joins or incomplete dates?

An interviewer may ask you to explain a query. Be ready to describe the join keys and aggregation level, not just say you used a common table expression. If you cannot share a proprietary query, explain the logic using a small fictional table.

Explain the analytical choice

Describe why the method fit the question. A descriptive breakdown might be enough to locate a workflow problem. A predictive model answers a different question. An experiment can support a causal conclusion only within its design and limitations.

If you compared groups, discuss how they differed before the comparison. If you analyzed a time series, mention relevant changes in tracking or seasonality when you know them. Do not use statistical terminology you cannot explain in plain language.

Show how the result reached a decision

“Built a dashboard” is a deliverable. What decision did it support? Who reviewed it? What action followed? Sometimes the honest outcome is that the result challenged a popular assumption or revealed that the data was insufficient. That can still be a valuable project.

For an illustrative dashboard story, separate these statements: “I built the view,” “the team used it at weekly reviews,” and “the process improved.” The first two do not automatically prove the third. Only claim the improvement if you have evidence and can explain the relationship.

Rehearse these follow-ups

Topic	Follow-up
Data quality	Which error would have changed your conclusion most?
SQL	How did you check that a join did not multiply rows?
Method	What alternative approach did you consider?
Communication	How did you explain uncertainty to the stakeholder?
Impact	What changed because of the analysis?

Write an answer to each question in your own words. When you do not know a detail, write “check” in your notes. This is more useful than filling the gap with a plausible answer generated by a tool.

Keep the opening short

A workable project introduction has four beats: question, data, approach and finding. Save detailed implementation for follow-up questions. Practice it aloud, then ask someone unfamiliar with the project to repeat the conclusion back to you. If they cannot, simplify the explanation before adding more technical detail.

See our data analyst career-change sample for an example report, and review your own resume to identify the claims you should prepare. For help describing impact without invented numbers, read resume bullets without metrics.