Business analysis interviews probe a craft that is easy to claim and hard to fake: getting the real requirement out of people who arrive holding a solution. Anyone can document what stakeholders say; the job — and therefore the interview — is about what they meant, what they forgot, what they'd never say in a workshop, and what to do when the loudest person in the room has already decided the answer.
The recurring UK BA interview set reflects that. Expect elicitation stories drilled for technique, a solution-first stakeholder scenario in some form, translation evidence in both directions (business to build team, build team to business), and prioritisation under someone else's politics. The marked answers below model the standard: named methods, real friction, and outcomes measured in decisions rather than documents.
One path note: a large share of UK BAs arrive from adjacent roles — operations, service, testing, finance — carrying exactly the domain knowledge the discipline needs. If that's your route, the fourth marked answer shows how to convert operational history into analysis evidence rather than apologising for the missing title.
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 defining BA scenario, asked because it happens on most projects and the wrong responses are both common: compliant documentation of the pre-decided answer, or an analysis crusade that reads as obstruction. Interviewers want respectful verification — the solution treated as a hypothesis and tested against the problem, fast.
This is my favourite question because I have the scars. Our client services director opened a project with the solution fully formed: 'we need a client portal — clients keep phoning about payslip queries, it's drowning the service team. Scope a portal.'
What I didn't do is argue, and what I also didn't do is scope the portal. I asked for two weeks to 'make the portal business case as strong as possible' — true, and also the analysis window. Framing matters: verify the hypothesis, don't fight the person.
The elicitation: I sat with the service team for three days and coded 240 inbound queries against a simple taxonomy. The picture that emerged: over half the calls weren't payslip queries at all — they were chasing the same three processing-status questions ('has my starter been set up', 'did the amendment go through', 'when does the run close'). A portal showing payslips would have answered the minority need and left the phones ringing.
How I took it back — carefully: 'the portal instinct is right, and the data says its killer feature is processing status, not payslip access. Smaller build, bigger dent.' I showed her the coded query data, one page. She moved in the meeting — her actual concern was the drowning team, not the portal per se, and the data served that concern better than her own solution had.
What shipped: a status-tracking page plus automated run-close notifications. Inbound queries fell from around 240 a week to under 90 within two months. The portal's payslip features went into phase two, right-sized.
The principle I run on: stakeholders bring solutions because solutions are how humans carry problems. My job is to receive the problem gently and test the carrying case.
Marking guide
Why it's asked: Elicitation technique beyond the workshop: the requirements that sink projects are the unspoken ones — assumed knowledge, workarounds too habitual to mention, the exception path everyone handles manually. Interviewers want your method for finding what people don't say, evidenced with one that mattered.
The requirement that never appeared in six workshops: that a third of repairs bookings were being made by someone other than the tenant.
Context: I was the BA on a housing association's repairs-booking replacement. Workshops with the contact-centre team had produced a solid requirements set — or so it looked. My habit on any process with a human front end is to spend at least two days observing the real thing after the workshops end, because workshops collect what people believe they do.
What observation showed: again and again, the caller wasn't the tenant. It was a daughter phoning for her elderly mother, a support worker for a client, a neighbour holding a key. The advisors handled it fluidly — verifying differently, recording contact details in a notes field, arranging access through the third party. Nobody had mentioned it in workshops because, in their words when I asked: 'that's not the process, that's just what happens.' The old system had no concept of it, so the workaround lived entirely in the notes field and the advisors' heads.
The requirement that came out of it — authorised representatives as first-class data, with verification rules and access arrangements — turned out to touch consent handling, the engineer's mobile app, and the appointment-reminder flows. Sized honestly, it was eleven days of build. Missed, it would have been the workaround reborn in a new system: the notes field again, day one.
My elicitation rule since: workshops for the process people believe in, observation for the process that exists, and the requirements document isn't done until the gap between the two has been walked.
Marking guide
Elicitation is a live skill. Your stories get elicited too.
Notice what the marked answers share: methods named, friction kept in, outcomes counted. Interview panels drill BA stories exactly the way BAs drill requirements — probing what you're not saying. A live aurate session does that drilling before the real panel: it pushes on your elicitation and pushback stories, marked on the same four criteria this page uses. Two free sessions. No credit card.
Try it freeWhy it's asked: The fidelity test, asked concretely: interviewers want the actual before-and-after, because the craft lives in the transformation — ambiguity resolved, edge cases surfaced, acceptance made checkable — while the business's intent survives recognisably. Candidates who can't produce a real example reveal documentation-by-paraphrase.
As the admissions manager said it: 'the system should flag applications that look like they might need a second look before we make an offer.'
That sentence contains four decisions wearing a trench coat, and my job was to get each one made by the right person.
What I did with it: a one-hour structured conversation, not a rewrite at my desk. 'Might need a second look' — against what signals? We listed them together: predicted-versus-required grades gap, a personal statement flagged by the similarity checker, qualifications from an awarding body not on the recognised list, and a declared break in education. 'Flag' — blocking or advisory? Her instinct was blocking; when I walked her through the volume consequence using the previous cycle's data — a blocking flag on those four signals would have held around 900 of 6,000 applications in a two-person team's queue — she chose advisory-with-reason-shown, blocking only on the awarding-body case. 'Before we make an offer' — turned out to mean before the offer letter generates, not before assessors read the file, which is a different system moment entirely.
As I wrote it for the build team, condensed: four rules, each with its data source, evaluation moment (on submission versus pre-offer-generation), display behaviour (advisory banner with named reason; hard-stop for unrecognised awarding body with an override role), and an acceptance test per rule — including the volume assertion that advisory flags must not gate the assessor queue.
At delivery, the admissions manager recognised her own intent in the shipped behaviour — flags that inform assessors without drowning the team. That recognition moment is my definition of translation fidelity: nothing lost in either direction.
Marking guide
Why it's asked: The adjacent-mover question, asked with genuine interest: operations-sourced BAs carry process reality that career BAs must dig for. But the advantage needs evidencing and the gaps need owning — interviewers probe for translated capability, not asserted equivalence, plus honest awareness of the technique catch-up.
The case in one sentence: I've been the stakeholder BAs interview, so I know exactly where requirements go to die — and I've already done the job's core loop without its title.
The evidence. As an operations team leader I was the business side of two system projects, and on the second one I effectively became the analyst mid-project. The vendor's BA gathered requirements in workshops I attended; what shipped in phase one missed the three exception paths that made up a fifth of our daily volume — returns without receipts, part-shipped orders, manual credits. I'd mentioned none of them in workshops, and neither had my colleagues, for the reason operational people never do: exceptions feel like failures, and nobody presents their failures to a stranger with a laptop.
So for phase two I did the analyst's job from the inside: documented all eleven of our exception paths with volumes from our own queue data, wrote them as scenario walkthroughs — trigger, decision points, who can authorise what — and sat with the vendor's team until each had a home in the design. Phase two landed with no workaround spreadsheets; phase one had spawned four.
What that path gives your team: I know the difference between the process people describe and the one that exists, because I've been the person describing it wrong. Stakeholders talk to me as a former one of them — the defensiveness that slows elicitation just isn't there.
The honest gaps: my modelling notation is self-taught — I completed the BCS business analysis foundation in April, and my process maps are correct but not yet elegant. And I've worked one domain deeply rather than several shallowly. Both fix with time. The instinct for where requirements hide doesn't teach so easily — and that's the trade I'm offering.
Marking guide
Why it's asked: The politics question wearing a process mask: naming a prioritisation scheme is trivial, running one against real seniority is the job. Interviewers want the mechanism plus the friction — the moment a senior stakeholder's 'critical' scored low, and what you did with the score.
Why it's asked: Workshop craft revealed through failure: the dominated room, the wrong attendees, the session that produced agreement without information. Owning a real one — with the specific facilitation change it taught — reads as practice; claiming uniformly successful workshops reads as either luck or low standards.
Why it's asked: The integrity-under-sunk-cost probe: build has started, the requirement traces to you or your predecessor, and the fix costs someone money and face. Interviewers listen for disclosure speed, impact sizing before the conversation, and whether the correction improved the checking process afterwards.
Why it's asked: A boundary-awareness check, practical rather than theoretical: the roles blur on real projects, and interviewers want evidence you can hold the analysis seat — problem definition, requirement integrity — while collaborating with delivery ownership rather than drifting into it or abandoning it. Cite a real boundary moment if you have one.
Why it's asked: The perfectionism probe: analysis can always go deeper, and projects die of both under-analysis and analysis paralysis. Strong answers name a stopping rule — decisions enabled, risks priced, diminishing returns visible — and one honest example of stopping too early or too late and recalibrating.
Why it's asked: The motivation question with a discipline-specific edge: BA sits between louder roles, and interviewers want candidates who chose the seat rather than settled for it. Truthful answers name the specific satisfaction — the moment the real problem surfaces, the translation landing — and connect it to evidence you're shaped for it.
Craft evidence over framework recitation: elicitation technique beyond workshops, the solution-first-stakeholder moment, translation fidelity in both directions, and prioritisation that survives politics. Certifications and notation fluency screen CVs; the interview probes what you actually did when the requirement was hidden, wrong, or pre-decided.
Helpful for screening, rarely decisive in the room: BCS and IIBA qualifications signal commitment and shared vocabulary, and some employers filter on them. But UK BA hiring leans heavily on evidenced practice — one well-told elicitation story with numbers beats a certificate list. If you're moving in from an adjacent role, a foundation-level certificate plus translated experience is the standard combination.
Do the job before the title, then translate deliberately: document the exception paths in your own process, run the volumes, write scenario walkthroughs for your next system change — the artefacts this page's fourth marked answer describes. Add a foundation certificate for vocabulary, and present your operational history as elicitation advantage rather than a gap.
The ones you've genuinely used, with a story each: workshops (including one that failed), observation or job-shadowing, data analysis on real volumes, structured one-to-ones, and process mapping at whatever notation you actually work in. Interviewers probe claimed techniques for texture — one honest 'I haven't used that; here's my equivalent' outperforms a bluffed checklist.
Ones that reveal whether analysis is respected or decorative: what happened to the last analysis that contradicted a senior stakeholder's plan, where BAs sit when scope decisions get made, how requirements changes reach the build team, and what the team's most expensive missed requirement taught them. Their answers tell you if the seat has a spine there.
Two free sessions. No credit card.