Scope, stated upfront: this page is not a SQL quiz. Query syntax, join types, and window functions are screened by technical tests, and practising them belongs in a code editor, not a prep page. What decides data analyst offers between technically-passing candidates is the other round — the one about judgement: what you did when the data said something inconvenient, how you carried uncertainty to people who wanted certainty, and whether your analysis ever actually changed a decision.
That judgement round is systematically under-prepared, partly because the big technical-prep resources barely touch it. Yet its questions are highly predictable — a handful of behavioural probes recur across UK analyst interviews at every level, and each one is testing a specific professional property: intellectual honesty, translation skill, stakeholder spine, and the discipline to check your own work before someone else has to.
The marked answers below span the settings UK analysts actually work in — commercial, operational, public-sector-adjacent — and one is written from the mover's path, because a large share of analyst hires arrive from operational roles carrying domain knowledge that interviews chronically undervalue unless the candidate translates it deliberately.
Practise these questions out loud with a live AI interviewer — free. Start with Try Me
How the marking guidance works
Each model answer below is marked against the four criteria a live aurate session scores:
See how a full session is scored
aurate is a practice tool. Marking guidance describes what strong practice answers show — it isn't an employability assessment.
Why it's asked: The value question. Plenty of candidates can describe analysis; far fewer can evidence consequence. The second clause matters most — interviewers want proof you carried the finding into the room where the decision lived, because analysis that stops at the dashboard is cost, not contribution.
My depot-loading analysis reversed a decision that had already been announced — which is the hardest kind of change to cause.
The company had committed to closing our smallest regional depot; the board pack showed it handling the fewest parcels per day, and the closure would save £480,000 a year in fixed costs. The plan was public internally when I was asked to model the routing consequences — as a formality, I think.
The formality turned up something the parcels-per-day metric hid: that depot sat on the only corridor that let vans from two neighbouring regions avoid the motorway junction that fails most winter mornings. I rebuilt the analysis around delivery-promise risk instead of volume — using two years of our own late-delivery data mapped against weather and traffic records — and the picture inverted: closure moved an estimated 40,000 deliveries a year onto our least reliable corridor, in the season when failure costs most.
Carrying it mattered more than computing it. I asked for fifteen minutes at the operations review, led with the one map that made the corridor problem visible, and put the £480,000 saving beside a costed range for promise-failures — honestly labelled as a range. The decision went back to the board with my map in the pack; the depot stayed open, and the closure saving was found instead through consolidating two overlapping urban routes — a proposal that came out of the same analysis.
What I'd emphasise: the volume metric wasn't wrong. It was answering a different question than the one the decision needed.
Marking guide
Why it's asked: The spine question — asked because it happens to every analyst, usually with someone senior on the other side. Interviewers are listening for the difference between rigidity and integrity: whether you found a way to serve the stakeholder's legitimate need without corrupting the finding.
Our head of brand wanted the quarterly report to show that the TV campaign had driven the subscriber jump — and our attribution data genuinely couldn't say that.
The jump was real: sign-ups up by around 3,000 in the campaign months. Her difficulty was that the board had approved the TV spend on her case, and she needed the story to close. My difficulty was that the same quarter contained a price promotion and a competitor's outage, and our attribution setup — last-touch, with TV inherently unmeasurable in it — couldn't separate the three. Anyone honest with the data could see the ambiguity; the report she drafted said 'campaign delivered 3,000 subscribers'.
What I did was refuse the sentence but serve the need. I told her plainly I couldn't sign the causal claim — and then built her the strongest honest case that existed: sign-up lift in TV regions versus non-TV regions, which showed a real but smaller regional effect; brand-search volume against the campaign's broadcast schedule, which tracked convincingly; and a plain-language box stating what we could and couldn't attribute, and what test design would answer it properly next time.
The report went out with the honest version. The board approved a second campaign — with a regional holdout built in, which was the real win: the next argument would be decidable.
She and I had one hard conversation in the middle of that week. We've had none since, because the ground rule got named: I'll make your best honest case as strong as it can be, and nothing beyond it.
Marking guide
Judgement questions have follow-ups. Dashboards don't answer them.
The two marked answers above survive because they hold up under probing — the confounders, the hard conversation, the range defended twice. That probing is what analyst interviews actually do, and it's exactly what a live aurate session rehearses: your analysis stories, pushed on, and marked against the same four criteria this page uses. Two free sessions. No credit card.
Try it freeWhy it's asked: Uncertainty communication is the analyst skill most exposed in review meetings and least practised beforehand. The interviewer wants a working method — ranges, assumptions named, what would change your mind — and evidence you've held the line when a decision-maker pushed for false precision.
With the confidence stated as part of the number, not as an apology after it — and I'll give you the example where that discipline earned its keep.
Our commercial team needed a forecast of how many customers would switch away when a major price change landed. The honest answer lived in a wide band: our historical switching data covered nothing this size, so I was extrapolating beyond the data's support — exactly where false precision does the most damage.
What I presented: a central estimate of 9,000 leavers over the quarter, inside a stated range of 6,000 to 14,000, with the three assumptions that drove the width listed beside it — competitor response, media coverage, and the share of customers on lapsed contracts. Then the sentence I now use in some form every month: 'the range is the finding — a single number here would be a guess wearing a suit.' And crucially, the operational translation: staff the retention line for 11,000, because under-staffing costs more than over-staffing at that margin.
The commercial director pushed for one number for the exec summary — genuinely pushed, twice. I gave him 9,000 with the range attached in the same sentence, and I didn't produce a version without it.
Actual leavers: about 10,500. Inside the range, above the central estimate — which is the outcome that teaches the organisation to trust ranges. If I'd said 9,000 flat, I'd have been 'wrong'. The range was exactly right.
Marking guide
Why it's asked: A large share of UK analysts arrive sideways — from operations, service, finance admin — and interviewers ask this genuinely: domain-carrying movers de-risk the commonest analyst failure, which is technically correct work built on misunderstood data. The answer needs the advantage evidenced, not asserted, plus honesty about the technical catch-up.
It gives you someone who knows what the data lies about — because I spent four years generating it.
As a workforce planner I lived inside the contact-centre datasets your analysts work with from the outside. So I know, concretely: that 'average handle time' dips every February not because agents speed up but because the annual-statement calls are short and boring; that the wrap-code taxonomy has three codes agents use as 'miscellaneous' when the queue is hot; and that any analysis of Monday absence that doesn't separate term-time parents from the rest will find a pattern that isn't there. None of that is in a data dictionary. All of it changes conclusions.
The evidence it matters: my first analysis project — done while still in planning — was the attrition review our people team had run twice with external analysts. Both prior versions blamed pay. My version found that leavers clustered in the teams whose rotas broke the published pattern most often, because I knew rota-deviation was a thing that could be counted and asked for the log. Fixing rota discipline in two pilot teams cut their quarterly leavers from nine to four while pay stayed flat.
The honest catch-up: my SQL is functional and my statistics are self-taught — I finished a six-month evening certificate in May, and I'd expect your code review to sharpen me for a year. What can't be taught in a year is knowing which questions the data can actually answer. That I'm bringing on day one.
Marking guide
Why it's asked: Data scepticism as evidence: every experienced analyst has caught a definition change, a broken pipeline, or a silently-defaulted field before it poisoned a conclusion. The question rewards specifics — what made you suspicious, the check you ran, what would have happened downstream — and quietly filters out candidates who treat datasets as given.
Why it's asked: Translation under scepticism is harder than translation alone — operational audiences have often been burned by dashboards before. Interviewers listen for audience empathy (leading with their problem, not your method), concrete language, and the move that converts a sceptic: letting them interrogate the analysis until it survives.
Why it's asked: A method probe wearing casual clothes: the answer reveals whether you have a disciplined intake routine — row counts, date coverage, null patterns, definition-checking with whoever owns the data — or whether you start building on unexamined ground. Strong answers include one war story about why a specific check exists.
Why it's asked: The error question, analyst edition. What's being measured: whether your own checks caught it or a stakeholder did, disclosure speed, and whether the fix was systemic (a validation step, a definition documented) rather than just a corrected number. No-errors claims read as low-volume work or low honesty.
Why it's asked: A modern classic, because self-serve analytics made misreading scalable. The question probes product-thinking about your own outputs: whether you treat misuse as user error or design feedback, and what you actually change — annotations, defaults, definitions on the chart, or a conversation with the misreader's team.
Why it's asked: A sneaky maturity probe: analyst work is full of invisible rigour — the check that found nothing, the automation that quietly saved hours. The honest answer reveals your relationship with unglamorous quality, and interviewers read it as a proxy for how you'll behave when nobody is marking the work.
The judgement layer: whether your analysis has changed real decisions, how you communicate uncertainty, what you do when stakeholders push for a different answer, and how sceptically you treat data before trusting it. Technical screens establish you can compute; the behavioural round establishes you can be trusted with what the computation means.
Assemble five or six real stories against the recurring probes — decision changed, stakeholder pressure, uncertainty communicated, error owned, data problem caught — each with its numbers intact and its follow-ups anticipated. Then practise them aloud: analyst stories fail in interviews through vagueness about consequence, not through technical thinness.
It is one of the commonest UK routes in — and operationally-sourced analysts carry an advantage this page's fourth marked answer demonstrates: they know what the data lies about. Close the technical gap with a structured certificate and one real analysis project in your current role; translate the domain knowledge deliberately rather than assuming interviewers will infer it.
Most include a practical screen — SQL exercises, a take-home analysis, or a live walkthrough of your approach to a dataset — pitched at working competence rather than leetcode difficulty. The advert's stated stack is usually what gets tested. Passing it earns you the judgement round, which is where offers are actually decided.
Ones that reveal how analysis is treated: what decision the team most recently changed, who owns data definitions when teams disagree, how much of the role is reporting versus investigation, and what happened the last time analysis contradicted something a senior person wanted. The answers tell you whether you'd be an analyst there or a chart producer.
Two free sessions. No credit card.