How to Interview a Data Analyst for a Story: A Guide (2026)

To interview a data analyst for a story, prepare the story question, learn enough about the dataset to ask real questions, then work through methods, uncertainty and limitations before asking for a quotable line. A 45-minute session built around open questions and a written verification checklist gets you a finding you can publish and a source who trusts you with the caveats.

The hardest part is not finding a finding. It is knowing which parts of the finding the data can carry and which parts the analyst is adding from experience, training or hope. Interviewers who blur those two things publish numbers that a reader can check and a conclusion that falls apart on contact.

Most reporters get one shot at this. The analyst has a day job, a communications team or a public affairs office between you and the analysis, and the first ten minutes of any technical interview decide whether you get the plain-language version or a recital of the methodology section.

What You Need

Most of the work happens before you dial. Bring five things to this interview and the rest of the session stops being an interrogation.

The story question, in one sentence

Write down the single question the piece has to answer. If you cannot finish that sentence, you do not yet have an assignment, you have a curiosity, and the analyst will notice the difference within two questions.

Background on the analyst, not just the dataset

Read the institution they work for, the papers they have published, the dashboards they maintain. You are not trying to out-read them. You want one or two specific, non-hostile questions that show you arrived prepared, such as when the dataset changed or what their team argued about internally.

Enough of the dataset to ask real questions

Open the file or the dashboard yourself. Know the time range, the unit of analysis, the geography and the size of the population underneath. If a figure looks wrong to you, ask about it — that is the moment an interview turns into reporting.

A recording or a reliable note method

Technical interviews need both. Quotes arrive late and out of order, and a paraphrase of a caveat is a distortion of it. Ask permission to record at the top, and write down caveats in the analyst’s own words as they happen rather than reconstructing them later from a recording.

A list of claims that must be verified

Before you start, write down every number you are considering putting in the piece, with the exact source it came from. That list becomes your fact-check list later, and it tells you in advance which claims cannot be vague.

Step-by-Step

1. Define the story question before the interview

Start by turning the assignment into one or two precise questions. Not “tell me about crime trends” but “did the reporting requirement reduce pedestrian deaths in the two years after it took effect, and by how much.” Precision here pays off for the whole session, because every question afterwards becomes an attempt to answer it.

Then decide what the story should illuminate. A trend means little until someone asks why it moved. Decide in advance whether you are chasing a decision (a budget, a policy, a staffing change), a trend (a pattern over time), or a human consequence (what the pattern does to a specific group of people). Each one needs a different line of questioning.

2. Ask the analyst to explain the analysis in plain language

Open with something like: “Talk me through what you did, as if I am smart but not a statistician.” You want five things before any numbers: what population, what time period, what unit, what geography, and what the central finding is in one sentence.

Most analysts can do this. The ones who cannot are telling you something about how much weight the analysis will bear, and that is useful to know early. People who work in analytics describe the job as data storytelling for stakeholders first and analysis second, so the plain-language version usually exists — it just rarely gets asked for.

Listen for what they do not say. If you never hear a denominator or a time range in their first three minutes, that is your next question.

3. How to interview a data analyst for a story about methods and uncertainty

Methods questions feel technical, so frame them as interest rather than interrogation. “How did you decide which records to include?” lands better than “what was your inclusion criteria?” The first asks about a judgment they made; the second asks them to recite a specification.

Work through the pipeline in order, and do not skip cleaning. Ask how the data was collected, what was missing, how missing records were handled, which definitions changed mid-series, and how outliers were treated. Data cleaning is where most of the hidden decisions live, and analysts are used to being asked about it.

Then push on the interpretation. What would have to be true for this finding to be wrong? What changed your mind during the project? Which result surprised you? These questions respect the work rather than challenge it, and analysts consistently report that they prefer being asked about their reasoning over being asked to defend a number.

Do not accept “the correlation is strong” as an explanation. Follow with: what else could be producing this pattern? A shared cause, a third variable, or plain coincidence all survive that question, and any of them changes what you can write.

4. Test the finding with concrete examples

Ask the analyst to anchor the finding somewhere real: one county, one hospital, one quarter, one demographic group. Concrete detail is what makes a reader see the pattern, and it is also how you find out whether the pattern holds where the analyst is claiming it holds.

The trap is over-reading the example. If the analyst describes one practice that changed its numbers after a new intake form, that is a case, not a cause. Ask whether anything else changed at that site in the same period, and how many other sites had the same change with the same result.

You will also learn something about the analyst’s own blind spots here. People narrate the example they remember best, which is often the one that worked.

5. Separate raw evidence from interpretation

Sort the answers into three buckets as you go, and say out loud which bucket you are in. “The dataset shows X” is raw evidence. “X likely means Y” is an analytical conclusion. “X suggests Y will continue” is a forecast or an opinion, and it needs to be attributed as one or cut.

Asking for the confidence behind each type costs one sentence: “How sure are you about that, and what would make you less sure?” An analyst who cannot rank their own claims is telling you the confidence is uneven, and uneven confidence belongs in the story even when it is awkward.

Watch for the opposite failure too. Some analysts under-claim because they expect to be challenged. If someone minimises a well-supported result three times in a row, it is fair to say so: “You keep saying this is interesting rather than telling me how solid it is.”

6. Ask for sources, code and documentation

Ask what you would need in order to reproduce the key number yourself: the source link, the methodology note, the codebook, the calculation in full, or the query. Data teams usually have at least one of these written down, and the ones that do are the easiest to work with.

Expect limits and ask for them in advance rather than hitting them. Confidential source material, licensing restrictions, small numbers that could identify individuals, internal policy on what staff may share, or a funder’s rules about public methods. Note the limit, say so in the story, and move on. A source who tells you up front that they cannot hand over a table has given you something publishable.

Keep the specific numbers you intend to use. Ask for them in writing before you hang up, with the denominator and the time range attached, so nobody has to reconstruct them from memory three weeks later.

7. Develop answers for different audiences

Ask for the same finding three times at three depths: once for a general reader, once for a specialist who will check your work, and once as a single sentence that could survive as a headline or a nut graf. Analysts are used to restating findings, and most do it faster and more cleanly than reporters do.

The general-reader version gives you your nut graf. The specialist version tells you which words need defending, because that is where precision returns and hedging creeps in. The one-sentence version shows you whether the finding is actually simple or whether you have been carrying a complicated result in a tidy sentence.

Take the phrasing from the general version and the honesty from the specialist version. That combination is where good data prose lives.

8. Close with a verification checklist

Reserve the last five minutes. Read back, one at a time: the claim, the evidence behind it, the time frame, the denominator, the limitations, and the questions you could not resolve. Have the analyst confirm or correct each item while the conversation is still live.

Then handle the housekeeping while you are both still there. Confirm spellings of names, datasets and systems. Get the links for the methodology documentation and the source file. Agree on how you will attribute the analysis, whether on the record or with a role and no name. Note any fact-checking they want to do, and note the point at which that has to happen.

If the analyst is inside an institution, remind yourself that you may still need to speak to the communications office. That is a normal part of reporting on a public or corporate body, not a sign the source was unhelpful.

Common Mistakes

Accepting jargon because you are afraid to interrupt

The fix is a request, not a confrontation: “Say that again without the statistics words.” If you cannot restate a sentence after the second attempt, you do not yet have the sentence you need for the piece.

Asking for the conclusion instead of the reasoning

Analysts are trained to give you the result quickly. Ask for the reasoning anyway, because the reasoning is where the caveats are and the caveats are what protects you when the finding is contested.

Skipping the denominator

Rates without a denominator produce stories that fall apart. A count of 4 sounds alarming until you learn the base population is 60. Ask what the number is a count of, out of what, before you write anything.

Treating correlation as proof of cause

When an analyst offers a causal story, ask what a controlled comparison would look like and whether anyone ran one. If not, the sentence in your piece has to say the two things moved together, not that one caused the other.

Letting one vivid example stand in for the pattern

A single case makes the story readable. It does not make it representative. Ask how common the case is relative to the total before you build a paragraph on it.

Leaving the methodology questions until after the story is drafted

If you never asked how the data was cleaned, you cannot write the caveat paragraph later. Pull it into the interview where you can still get an answer.

Pressing for a stronger quote than the evidence supports

Analysts are unusually careful about being quoted accurately, particularly around uncertainty, and pushing past that produces a sentence they will not stand behind. Ask for the honest version instead; it is usually stronger in print anyway.

Taking the first dashboard answer

The summary chart is where the tidy findings live. The anomalies, the excluded regions and the missing quarters are where the actual story is. If the walkthrough ends with the dashboard’s headline number and nothing else, you stopped one question early.

Forgetting that you are interviewing a person with a job

Some of the best material arrives after the formal questions, when the recording is off and the meeting is ending. Build in the slack, and do not reach the exit too early.

Frequently Asked Questions

Conclusion

Start with the story’s central question, write it down before the call, and open the data yourself so the first five minutes produce real questions rather than polite ones. Then work from methods to uncertainty to a concrete example, keep a running list of every number and its denominator, and read that list back before you hang up. That habit, more than any single question, is what keeps a data-driven piece accurate after the analyst stops answering your calls.