Tell Me About a Time You Used Data to Make a Decision: Answer Framework and Examples

"Tell me about a time you used data to make a decision" is a behavioural interview question that probes your analytical skills. It appears in interviews for analyst, finance, consulting, marketing, operations and technology roles, and increasingly in general graduate scheme interviews, because almost every modern job involves some numbers: sales figures, survey results, budgets, usage statistics or performance metrics. The question is not a maths exam. It is a test of whether you naturally reach for evidence and whether you can turn information into action.

Interviewers typically listen for four things. First, curiosity: did you notice that data was available, or go and find it? Second, rigour: did you check that the data was reliable and relevant before relying on it? Third, judgement: did you connect the numbers to a real decision rather than just reporting them? Fourth, communication: could you explain your finding to people who were not as close to the numbers as you?

Keep these four qualities in mind as you choose and structure your story. Every sentence should show either how you handled the information or what changed because of it.

Many graduates assume they need a spreadsheet model or a machine learning project to answer this question. They do not. In an interview, data simply means facts you gathered or analysed, usually numerical, that informed a choice. That can be a small survey you ran for a society, sales figures from a part-time job, lab results from a module, website analytics for a student project, or even a simple count of how long tasks were taking.

A useful test is to ask three questions. Was there a decision to make with at least two sensible options? Did you collect or examine information rather than relying on opinion? And did the information change or confirm what you did? If all three are true, you have a candidate story, whatever the scale.

Prepare two or three candidate stories from different settings. If the role is technical, our data analyst interview questions guide shows the depth of detail those interviewers expect. For general graduate roles, the broader competency-based interview guide explains how to match one story to several competencies.

The standard STAR method works well here, but data stories need slightly more structure in the middle. Use the five steps below, which expand the Action section into the stages of analysis that interviewers want to hear. Aim for about two minutes spoken, roughly 250 to 300 words.

1. Question: what were you trying to decide?

Start with the decision, not the dataset. "We needed to decide whether to move our weekly meetings online" is a better opening than "I had a spreadsheet of attendance figures". Twenty seconds is enough for context, and the decision should be clear by the end of the first two sentences.

2. Data: what did you use and why?

Say what information you gathered and why it was relevant. Mention where it came from and roughly how much there was: "forty survey responses from our 120 members" or "twelve weeks of till data". This shows you know that the source and the size of the data matter.

3. Analysis: what did you do with it?

Describe your method in plain language. You might have compared averages, looked for trends over time, split results by group or calculated a percentage change. Keep it proportionate. One or two steps clearly explained are better than a list of techniques.

4. Decision: what did you conclude and do?

State the finding and the action together. "Attendance was 60% higher at evening sessions, so I proposed moving all events to evenings." Mention any alternative you rejected, and who you needed to convince.

5. Result and review: what happened, and what did you learn?

Give the outcome with a number if you can, then add a sentence of reflection on what you would check or do differently. This final step separates mature answers from mechanical ones.

Spoken numbers are harder to follow than written ones. When you describe a figure aloud, the listener cannot scroll back, and a string of percentages quickly becomes noise. Good candidates make numbers easy to hear by choosing a few that matter, rounding them sensibly and giving each one context.

Limit yourself to two or three figures in the whole answer. Round to simple values, such as "about a third" or "roughly 60%", unless precision is the point. Always give a comparison: "response times fell from around eight minutes to five" tells the listener much more than "response times were five minutes". And always translate a figure into meaning: what did the change imply for the decision?

Say the tool only if it adds credibility. Mentioning Excel, Google Sheets, SQL or Power BI is fine for a technical role, but the interviewer's real interest is in what you found and why you trusted it. If you can say "I checked it against the till totals to make sure the figures matched", you will signal rigour more effectively than any software name.

Finally, rehearse out loud. Written answers tend to contain long sentences and nested clauses that sound awkward when spoken. Record yourself once, listen back, and shorten every sentence that makes you run out of breath.

The examples below are illustrations of structure, not scripts. Do not copy them. Replace the details with your own experience, and keep your numbers honest. Each one runs to about two minutes spoken.

Example 1: Society events (any graduate role)

Question: "As events officer for a 120-member society, I had to decide which event format to repeat after a mixed term. Data: I pulled attendance figures from six events and sent a short feedback form, which got 42 responses. Analysis: Comparing attendance by day, evening socials drew about 45 people on average while weekday lunchtime talks drew around 18. The form showed most members who skipped talks said the timing clashed with lectures. Decision: I proposed shifting talks to Thursday evenings and keeping socials as they were, and persuaded the committee by showing the comparison on one slide. Result: Over the next term, average talk attendance roughly doubled to 35. In hindsight I would have tested one evening talk first before changing the whole programme."

Example 2: Part-time retail job (commercial or operations roles)

Question: "In my weekend job at a café, we kept running out of one pastry by midday while another went to waste. Data: I started noting daily sales and leftovers for each item over four weeks, which was about 24 trading days. Analysis: I calculated average sales per day and found the first pastry sold out by 11am most days, while around a third of the second was thrown away. Decision: I suggested increasing the first order by about 20% and reducing the second, and my manager agreed to trial it for a month. Result: Waste on that item dropped noticeably and we stopped running out before lunch. I also learned that four weeks included a bank holiday, so I now check whether unusual days are skewing a pattern."

Example 3: Dissertation survey (research, analyst or consulting roles)

Question: "For my dissertation on student budgeting, I had to decide whether to keep a planned comparison between first-years and final-years. Data: After two weeks my survey had 85 responses, but only 11 from final-years. Analysis: With so few responses, the comparison could easily have been misleading, so I checked how the final-year group differed in course mix and noticed it was mostly one department. Decision: I decided to drop the comparison, widen the survey through other departments' mailing lists and, if numbers stayed low, to focus on a single year group. Result: I reached 38 final-years and kept the comparison, with a note on its limitations. I learned to check sample size early rather than analyse and hope."

If your story is closer to a general problem than a choice between options, you may prefer our guide to solving a difficult problem. For stories where the data pointed one way and you chose another, see making a difficult decision.

The strongest candidates do not treat data as an oracle. They know that numbers can be incomplete, biased or misleading, and they say so. This is a quick way to stand out, because many applicants present data as proof and leave no room for judgement. Interviewers, especially in finance, consulting and analytics, are listening for the instinct to ask "how reliable is this?".

You do not need advanced statistics. A few plain-language checks show good practice: Is the sample large enough? Is it representative of the people or situation I care about? Does the period I looked at include anything unusual? Could something else explain the pattern? Mentioning even one of these in your answer demonstrates critical thinking, which is also measured directly in tests such as the Watson Glaser critical thinking test.

Some situational questions test the same instinct without asking for a past example. In those you may be given a scenario and asked what you would do. Our situational interview questions guide and the situational judgement test guide show how to reason through them. If you have no relevant example, describing exactly how you would approach the problem, step by step, is a legitimate fallback, but say clearly that it is hypothetical.

Most weak answers to this question share a handful of problems. Fix these and your answer will already be stronger than the average. The most common is describing the analysis in detail without ever stating the decision. Another is listing tools and techniques as if the interviewer were marking a CV. A third is quoting so many numbers that none of them lands.

Finally, remember that many employers combine interviews with online assessments. If you are preparing for both, balance your time: build your stories early, then use the final weeks for timed practice so that the two skill sets reinforce each other.