Updated 5 October 2026 by Ben Gallagher. Sources below.
This page covers data analyst interviews in any industry. The Analysis Function, the Code of Practice for Statistics and the UK GDPR described below are UK public-sector and legal references and are labelled; the habits of checking, explaining uncertainty and respecting personal data apply everywhere. Data analyst panels test judgement as much as tools. They give you a number that has just fallen, a join that has doubled revenue, a test that looks good after three days or a stakeholder who wants the awkward part left out, and they ask what you do next. Prepare examples where you framed a vague question, found a data problem before anyone else did, explained uncertainty to a non-specialist and changed a decision. Say which checks you ran, what you told people and what you would do differently.
These are common questions for this job. Your panel will also ask about the advert and about you.
What they're testing: Turning a vague request into an answerable question and following it through to a decision.
What they're testing: Choosing metrics that answer the business question and spotting proxies that mislead.
What they're testing: A structured diagnosis: data pipeline and definitions first, then segments, time and causes.
Check whether it is real before explaining it. First the pipeline and the definition: has anything broken or changed? Then split by channel, device, region and time to see where the drop sits. Report what I know and do not know by lunch, with a next step.
When weekly sign-ups showed a fall of about a fifth overnight, I first asked whether the tracking had changed. I checked the event table for the sign-up event and saw it had stopped firing on one mobile app version released the previous evening. To confirm, I compared the sign-up counts in the production database, which had fallen by far less. I split the dashboard figures by device and the whole drop sat in that app version. I messaged the product owner with a three-line summary: the drop is mostly a tracking fault, true sign-ups are down about three per cent, which I am still looking at, and the tracking fix is with engineering. I marked the dashboard with a note so nobody quoted the figure that afternoon. The fault was fixed next day, and I added an alert for sudden event drops.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: Sample size, duration, pre-set success measures and the risk of stopping a test early.
Ask what was planned before the test started: the success measure, the sample size and the duration. Three days is often too short, because early results swing and weekday patterns matter. I would recommend letting it run to the planned end, unless there is harm.
A team showed me a new checkout design ahead after three days and wanted to ship. I asked what we had agreed at the start. The plan was two full weeks and a minimum number of orders per version, which we had not yet reached. I showed them that conversion for the new version had swung from three points ahead on day one to one point ahead on day three, so the early lead was unstable. I also pointed out that three days missed a weekend, when buyers behave differently. I suggested we keep the test running, and that I would send a short update at the halfway point with the range, not just the headline. At the planned end the difference was smaller than the early figure but still positive, with a range that did not include zero. We shipped with a realistic expectation of the gain.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: Separating correlation from cause and looking for confounders and alternative explanations.
Treat it as a hypothesis. Ask how regions were chosen for the course, compare them before it ran, look for other differences such as size, season and local campaigns, and test whether sales rose more than comparable regions did. Say what I can show, and what I can only suggest.
Regions that took the training course had higher sales, and the sales director wanted to credit it. I asked who chose the regions. Managers had volunteered, so they were probably the stronger teams already. I compared sales in the year before the course and found those regions were already about ten per cent higher. I then compared the change in sales, before and after, between the course regions and similar regions that did not run it. The difference was small and the range was wide, so I could not show the course made the difference. I told the director that the evidence suggested a possible benefit but did not prove it, and proposed running the course in a random half of the next regions so we could compare fairly. He agreed to that.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: Cleaning data defensibly, recording each decision and being open about limits.
Decide what each problem does to the question. Fix what is clearly mechanical, such as formats and exact duplicates, record every change, and ask the owner about anything ambiguous. Report what I excluded and why, and what difference it makes, instead of quietly tidying it away.
A department sent a spreadsheet of complaints with two date formats, repeated rows and a blank category for about a third of entries. I kept the original file untouched and worked on a copy. I standardised the dates, checking a sample against the source, and removed exact duplicates, logging the count. The blank categories were different: I could not guess them. I asked the sender, who explained that the category field had been added halfway through the year, so earlier rows were empty. I analysed only the period after it started for the category question, and said so, but used the full year for volumes. In my summary I listed the changes in six lines with the number of rows affected. The sender used the note to ask her team to complete the category field going forward.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: Recognising biased missingness and choosing between excluding, imputing or reporting the gap.
What they're testing: Spotting a many-to-many join, checking row counts and grain, and fixing the query.
Almost certainly a join that multiplies rows, probably a many-to-many relationship, so each order is repeated. I would check the row counts before and after the join, find the key that is not unique, and then aggregate to the right grain before joining.
When revenue doubled after I joined orders to customers, I counted rows in each table and after the join. Orders had 50,000 rows but the join returned more than 100,000, so rows were repeating. I grouped the customers table by the join key and found some customers appeared twice because of an address history table that had been combined into it. Each order matched both rows. I fixed it by selecting only the current address per customer before the join, and I checked that the row count matched the orders table and that revenue reconciled to the finance figure. I also added a short check at the top of the query to compare the total with the source. I told the colleague who had been using the old version, so they could correct their numbers, and I noted the grain of each table in the team's documentation.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: Tracing definitions and data lineage and agreeing one source of truth rather than picking a winner.
What they're testing: Investigating unusual values before removing them and documenting the decision.
What they're testing: Choosing a modest method for the data available and being honest about uncertainty.
What they're testing: Understanding sampling error and communicating what small samples can and cannot show.
What they're testing: Reproducibility: documented, versioned, automated analysis that others can check.
What they're testing: Matching the tool to the task and judging when automation is worth the effort.
What they're testing: Giving a clear message while stating the range and what it depends on.
Give the headline and the range together: what we expect, how sure we are, and what it depends on. A single number with no range invites false confidence. Offer the director a decision rule, such as what we would do at the low and the high end.
I had to tell a director how many extra staff next winter's demand would need, and my forecast was uncertain. He wanted one number. I gave him one, with the range straight after it: about 40, probably between 30 and 55, and I explained in one sentence that the width came from having only fourteen months of data. Then I turned it into a decision: if we hire 40 and demand is at the low end, we are slightly over, and if it is at the high end we need agency cover for the peak. He decided to hire 35 and keep an agency option. I showed a simple chart with the central line and the shaded range and no equations. In the spring we compared actual demand with the range, and it fell inside it, which gave him more confidence in the next forecast.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: Linking analysis to action and measuring the result honestly.
What they're testing: Designing for the audience's decisions and cutting what does not help them.
What they're testing: Defending work with evidence while staying open to finding you were wrong.
What they're testing: Integrity under pressure and finding a constructive way to present the whole picture.
I would not leave it out. I would explain that the full picture protects their case, because someone will find the gap. Then I would look for a constructive framing: present the finding with the caveat, show what the data does support, and suggest what to test next.
A manager asked me to remove two months from a chart because they showed a dip that weakened his argument for a new service. I asked why, and he said it would confuse people. I said I was worried that if someone else noticed the missing months, it would damage trust in the whole report. I looked at the cause of the dip and found it matched a system outage, which meant the months were unrepresentative for a clear reason. So I kept them in, annotated the outage, and showed the trend with and without those months, so the reader could see both. The manager was happier because the argument now anticipated the obvious question. I told him I would always show the full data and explain it, but that I was glad to help him present it in the best honest light.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: Data protection: purpose, minimisation, anonymisation and who has agreed.
Pause and ask what the data was collected for. A new purpose may need a lawful basis and may be incompatible with the original one. I would ask whether I need names and addresses at all, minimise the extract, check with the data protection lead and agree who sees it.
A marketing colleague asked me to analyse customer records, including names and addresses, to find which customers might respond to a new product. The data had been collected for delivering orders. I told her I wanted to check before starting, and I read our privacy notice and spoke to the data protection lead. She said the notice did not clearly cover marketing analysis. We agreed I could analyse purchase patterns using an anonymised customer reference with no names or addresses, which was enough to segment customers. She could then decide how to approach each segment within what the notice allowed. I stored the extract in a restricted folder and deleted it when the project finished. My colleague got the segments she needed, and we avoided using people's details in a way they had not expected.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: Telling people quickly, correcting it and fixing the process that let it through.
Tell the people affected straight away, before they find it. Say what was wrong, how big the effect is and what the corrected figure is. Then fix the cause, whether a check, a review or documentation, and tell them what changed.
A week after sending a weekly report, I noticed that a filter had excluded one region, so the total was too low by about six per cent. A manager had already used it in a staffing decision. I messaged him within the hour: I had found an error in last week's report, the corrected total was higher, and the regional split changed slightly. I attached the corrected version and a note of what had been wrong. I asked him whether the decision needed revisiting, and offered to talk through the difference. In his case the decision still stood. Afterwards I traced how it happened, which was a hard-coded list of regions, replaced it with a lookup from the master table, and added a reconciliation row so the total is checked against finance every week. I told my team lead what I had done.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: Protecting accuracy under time pressure and agreeing a sensible scope.
What they're testing: Prioritising by impact and urgency and telling the others openly.
What they're testing: Right-sizing work and agreeing what level of rigour the decision needs.
In the UK, the apprenticeship standard and the Government Analysis Function are used below. Employers elsewhere use their own job profiles, so read the advert for the tools and the business questions you will own.
The data analyst apprenticeship standard on Skills England describes the role as collecting, organising and studying information to provide business insight, and its duties include selecting appropriate data sources, collecting and cleansing data, building dashboards and reports, analysing trends, drawing conclusions and recommendations, presenting findings to different audiences and storing and archiving information in line with legislation. Panels build their questions on the same chain, from question to cleaned data to recommendation.
In the public sector, the Government Analysis Function describes quality as fitness for purpose, and says analysts should understand the whole journey of the data, investigate unusual patterns rather than accept data at face value, and document who performed each quality check. Interviews in any sector reward the same habits.
The guidance here is from the UK Government Analysis Function and the Office for Statistics Regulation. Official statistics bodies in other countries publish similar principles, but you can use these in any interview: be honest about quality and say what you do not know.
The Analysis Function's guidance on communicating quality, uncertainty and change says producers should explain clearly the extent and nature of any uncertainty in estimates, describe the direction and size of any change, and show ranges or confidence intervals, which it calls a powerful tool for conveying uncertainty. It also says that important quality information should be prominent and not buried in footnotes, and that different audiences need different levels of detail.
The Code of Practice for Statistics, which the Office for Statistics Regulation oversees, rests on three pillars: trustworthiness, quality and value. The ONS points to the same Code and to the Analysis Function's guidance as its policy on accuracy, avoiding bias and clear communication. You do not have to quote either in an interview, but a strong answer to a question about a shaky number sounds like them: say what you know, how sure you are and what would change your mind.
In the UK, the ICO's guide to the UK GDPR principles applies. Other regions have their own privacy laws, so ask which applies to the data you would use.
The ICO's guide to the data protection principles sets out the UK GDPR principles most relevant to analysis. Data must be collected for specified, explicit and legitimate purposes and not further processed in a way that is incompatible with them. It must be adequate, relevant and limited to what is necessary, accurate and kept up to date, and kept in an identifiable form for no longer than necessary.
So when you are asked to analyse customer records for a new purpose, a strong answer asks first what the data was collected for, whether you need names and addresses at all, who has agreed to the new use and how long the extract will be kept. Say you would raise it with the data protection lead instead of deciding alone.
When the panel asks whether you have anything to ask, say yes. The National Careers Service and Prospects both treat your own prepared questions as part of a good interview, and Indeed and The Muse add that the best ones come from your research and from the real work: what the first weeks involve, how you are trained and how success is judged, never something a quick look at the website would have told you.
For this job, good questions come from the work itself:
Questions about data quality and the people who use your work show maturity.
If this would be your first job of this kind, you are in good company: panels interview freshers and career changers all the time. The Muse suggests using school or university work, volunteering and hobbies as evidence, practising each story until it is comfortable, and showing that you want to learn. The National Careers Service says to prepare examples and use STAR, and the University of Arizona's career service says it is fine to admit a gap and explain how you would approach the situation.
Show how you check for errors. It is the clearest sign of a good analyst.
It depends on the post. Many include a SQL or spreadsheet exercise or a case study, plus questions about how you handle bad data and explain findings. Read the job advert for the tools it names and practise explaining your choices aloud.
Use a project from study, volunteering or a personal dataset. Show the question you set, how you checked the data, what you found and how you told others. Panels want the method more than the employer's name.
You need to know enough to avoid misleading people: sampling, correlation versus cause, uncertainty and bias. Explain these in plain language rather than reciting formulas.
Pick a real error, say how you found it, whom you told, what the corrected figure was and what check you added afterwards. Panels trust analysts who find and own their errors.
Related topics: Behavioral interview questions, Common interview questions.
Related: Project manager, Business analyst, Software developer, Sales executive.
