How employers assess practical BA capability

How Recruiters Really Test Whether You Can Do Business Analysis

Written by Jude Mahoney

Agile Delivery Lead | Business Analyst Mentor | 20 Years Experience

LinkedIn: Jude Mahoney

One trend that I’m seeing far more frequently is some form of Business Analysis assessment to decide who can actually do the role, usually prior to (or during) interview. Ultimately, a polished CV might get you a Business Analyst interview, it cannot prove (to the organisation) that you can actually do the job, hence why more recruiters/organisations are bringing in these types of assessments.

That distinction matters because BA recruitment is increasingly capable of moving beyond questions such as “What is a user story?” or “Tell me about a difficult stakeholder.” Employers can give you an unfamiliar business problem and watch what you do with it. They may send an analysis task before the interview, ask you to present a case study, put a process on screen and ask you to improve it, or share their screen and ask you to write user stories and acceptance criteria while they watch.

At that point, knowing the terminology is not enough. The employer is looking for evidence that you can think like a Business Analyst when the answer has not already been prepared for you.

That is the real purpose of practical BA assessment.

Why employers use practical BA assessments

Business Analysis is unusually difficult to assess from a CV alone. I know, I’ve hired good and… less good over the years.

Two candidates might both claim five years of experience in requirements elicitation, process mapping, Agile delivery, Jira and stakeholder management. One may genuinely have led discovery, challenged assumptions, modelled processes, uncovered requirements and helped a team decide what to build. The other may largely have attended meetings and updated Jira tickets created by somebody else. Still, some will eloquently explain a BDD style A/C and in detail during an interview and then not know how to do it when they’re in the role!

On paper, this distinction can be surprisingly difficult to see.

A practical exercise changes that.

Current interview guidance reflects this broader approach. BA assessments can cover requirements, process analysis, user stories and acceptance criteria, stakeholder management, data, UAT and prioritisation. Case-study interviews are specifically used to assess how candidates solve problems, communicate and work analytically, rather than simply whether they know the right vocabulary. (Capital One Jobs)

There are also current UK examples of employers formally building this into recruitment. A recent Ministry of Justice Senior Business Analyst recruitment process, for example, included a scenario-based technical exercise and presentation designed to assess BA capability and professional judgement. (VERCIDA)

The important lesson is simple: prepare to demonstrate Business Analysis, not merely talk about it.

1. The pre-interview analysis task

You may receive an exercise before you ever meet the hiring manager.

The employer might provide a short business scenario, a collection of requirements, some process information, customer data, stakeholder comments or a description of a problem. You could then be asked to analyse it and return your findings.

Depending on the role, that might mean producing:

• a set of requirements
• user stories and acceptance criteria
• an AS-IS and TO-BE process
• a stakeholder analysis
• a problem statement
• assumptions and questions
• prioritised requirements
• a gap analysis
• a short business case
• recommendations
• a presentation explaining your approach.

Some written case exercises give candidates several hours to prepare, while live exercises may be deliberately much shorter. The important point is that employers are not necessarily looking for the largest possible collection of BA artefacts. Over-documenting a case can actually obscure whether you understood the underlying problem. (Voco)

If you receive a task saying that a company has an inefficient customer onboarding process, for example, resist the temptation to immediately start drawing a beautiful future-state process. You should challenge yourself, first:

• ·      What do you actually know?
• ·      What don't you know?
• ·      Who uses the process?
• ·      Where is the evidence that it is inefficient?
• ·     What does “inefficient” mean in this context?

Is the problem time, cost, errors, customer abandonment, manual effort, regulatory risk or something else?

What constraints exist?

What would success look like?

That questioning instinct is part of what is being assessed, not always the outcome.

A candidate who leaps immediately from problem to solution may inadvertently demonstrate the opposite of good analysis. (Solution led requirements are rarely good in my view).

2. The live case study

The live case study removes another advantage: unlimited preparation.

You are given a problem and have to work through it with the interviewer.

This is where candidates sometimes become uncomfortable with silence and start throwing techniques at the problem:

“I'd run a workshop, use MoSCoW, create user stories, build a process map and do a gap analysis…”

That sounds busy, but again it doesn't necessarily demonstrate analysis.

A stronger response begins by establishing the problem.

Imagine the interviewer says:

“Our customers are abandoning the online application process. How would you approach this?”

There is no sensible solution yet because there isn't enough information.

A capable BA might begin by exploring:

What do we know about the problem?
What proportion of customers abandon it? Where in the journey do they leave? Has that changed recently?

Who is affected?
All customers? Mobile users? Particular products? Particular demographics or channels?

What evidence exists?
Analytics, customer complaints, contact-centre data, session data, usability research?

What is the business impact?
Lost sales? Increased support calls? Regulatory concerns? Operational cost?

What has changed?
New functionality? New compliance requirements? A redesigned journey?

Only then should you start determining how you would investigate further.

This is one reason case interviews are valuable to employers. They can reveal communication, conceptual problem-solving and quantitative analytical ability in a way that rehearsed competency answers cannot. (Capital One Jobs)

3. Writing user stories while somebody watches

This can feel very different (and a little awkward admittedly) from writing stories during an ordinary working day. Think of it like a development task that software developers have been forced to do for years.

The interviewer shares a screen, opens Jira, Miro, a document or simply a blank page and says:

“Write me a user story for this.”

Now they can see your thought process.

Suppose the scenario is an ecommerce website where customers need to narrow search results by product category.

It is easy to type:

As a customer, I want to select a product category, so that I can narrow my search.

Fine. But that's only the beginning.

The interviewer may then ask:

“What acceptance criteria would you add?”

This is where practical understanding begins to show.

You might consider:

• Which categories are displayed?
• Is there an “All categories” option?
• What happens if no category is selected?
• Does changing category automatically rerun the search?
• What happens when a category contains no matching products?
• Is the selected category retained when the search term changes?
• What happens on mobile?
• What happens if categories cannot be loaded?
• Are there accessibility requirements?
• Is there a performance expectation?
• Can categories themselves contain subcategories?

The exercise may then develop further:

“Is there anything wrong with the requirement I've given you?”

“What would you ask the Product Owner?”

“Write the acceptance criteria in Given/When/Then.”

“Which of these are business rules rather than acceptance criteria?”

“Would you consider this story ready for development?”

That conversation is considerably more revealing than asking somebody to define a user story. Interview material for BA roles increasingly focuses not only on writing stories, but identifying poorly written stories, improving them and demonstrating that the resulting requirements are clear and testable. (The Business Analyst Job Description)

Don't race to start typing

This is particularly important during a shared-screen exercise.

If the interviewer gives you a scenario and you immediately start writing, you may miss an opportunity to demonstrate one of the strongest BA behaviours available to you:

clarification.

Say:

“Before I write the story, can I clarify a couple of things about the user and the outcome we're trying to achieve?”

That is not hesitation.

That is Business Analysis. Always take the time to think, this is especially powerful at interview, it shows you to be someone who is measured and thoughtful in their approach, and not inclined to blurt out what you think is “the correct answer”, this is something you can and should learn to do (taking your time before answering immediately – it’s a power move).

4. Acceptance criteria may reveal more than the user story

Writing the basic user-story sentence is relatively easy. Acceptance criteria force you to think.

A recruiter may therefore be looking at whether you can turn a broad statement of intent into something sufficiently precise to discuss, develop and test.

For example:

Given a customer has entered a search term
When they select a product category
Then the search results should display only matching products within that category.

The interviewer can now challenge it.

What if there are no results?

What if the customer changes category?

What if the category becomes unavailable?

What does “matching” actually mean?

Could the tester determine from your acceptance criteria whether the feature works?

Good acceptance criteria create shared understanding. They should not merely repeat the user story using different words.

5. Process-mapping exercises

Another practical assessment is to ask you to construct, interpret or improve a process.

You might receive a scenario such as:

A customer submits an application. Customer Services check it. Incomplete applications are returned. Complete applications are sent to Finance for approval. Applications over £10,000 also require director approval.

You may be asked to map it.

The interviewer isn't necessarily interested in whether your BPMN notation would survive an academic examination. They may be looking at whether you identify:

• actors and responsibilities
• start and end points
• decisions
• hand-offs
• exceptions
• duplication
• delays
• bottlenecks
• dependencies
• business rules
• opportunities for improvement

Process-mapping questions can also probe whether you understand when a formal notation such as BPMN is useful and when a simpler process representation is more appropriate for the audience.

An interviewer might deliberately leave something ambiguous.

Don't silently invent the missing information simply because you want to finish the diagram.

Flag it. Call it out. Doing that in a real role is again a power move, it shows you understand sufficiently the issues that need calling out and challenging.

“I don't know from the information provided what happens if Finance rejects the application, so I'd mark that as a question rather than assume the process ends.”

That sentence demonstrates judgement.

6. Requirements elicitation role-play

This is one candidates can overlook.

Instead of asking how you would conduct requirements elicitation, an interviewer can become the stakeholder or product owner.

You become the BA.

They might say:

“We need a new reporting dashboard.”

Your job is to interview them.

A weak response immediately asks what fields they want on it.

A stronger BA tries to understand why the dashboard is needed in the first place.

·      Who will use it?

·      What decisions will they make from it?

·      What do they use today?

·      What is wrong with the current approach?

·      Which measures matter?

·      How frequently does the information need updating?

·      Where does the data originate?

·      Who owns it?

·      Are there access restrictions?

·      What would make the dashboard successful?

The employer can now observe elicitation, active listening, follow-up questioning and your willingness to challenge assumptions.

They can even play a deliberately difficult stakeholder.

That's useful because stakeholder management is easy to claim on a CV and considerably harder to fake in a live conversation.

7. Prioritisation exercises

You may be handed ten requirements and told that the delivery team can only build five.

Which five?

This is a trap if you simply start assigning MoSCoW labels. (“It’s a trap!” – Admiral Ackbar).

The technique isn't the analysis.

What information determines priority?

Business value, regulatory necessity, risk, dependencies, customer impact, implementation effort and strategic importance might all affect the decision.

Perhaps Requirement 7 looks unimportant but is a technical dependency for Requirements 1, 2 and 3.

Perhaps Requirement 4 has little commercial value but is legally mandatory.

Perhaps the stakeholder has labelled everything “Must Have”.

Your job is not merely to know that MoSCoW means Must, Should, Could and Won't.

Your job is to facilitate a defensible decision, that’s the key part of these types of assessments.

8. Data and analytical exercises

For some BA roles, particularly those with a stronger systems, product or data element, expect numbers.

Assessment material can include SQL, Excel, data interpretation and metrics alongside the more traditional BA disciplines.

You could be given:

• sales figures
• customer-conversion data
• process timings
• error rates
• support volumes
• transaction data
• a spreadsheet requiring analysis
• a simple SQL task

You may then have to identify a trend, investigate a problem or make a recommendation.

The principle remains the same.

Don't just calculate. Analyse.

If completion time fell from 12 minutes to eight minutes after a new system was introduced, what can you reasonably conclude?

·      Was the sample comparable?

·      Did transaction volume change?

·      Did error rates increase?

·      Was the measurement period long enough?

·      Did something else change simultaneously?

A BA should be capable of distinguishing what the data says from what somebody would like the data to prove.

9. Reviewing somebody else's bad requirements

This is an excellent assessment technique because real BA work rarely starts with a perfectly blank page.

You might be given something deliberately poor:

“The new system must be user friendly and load quickly.”

Then asked:

“What's wrong with this?”

You should immediately recognise the ambiguity.

·      What does user friendly mean?

·      For whom?

·      How will it be measured?

·      What does quickly mean?

·      One second? Three seconds? Ten?

·      Under what load?

·      From which location or device?

The employer is testing whether you recognise requirements that cannot be objectively validated.

You might similarly receive:

• an enormous user story
• contradictory requirements
• a solution masquerading as a requirement (as mentioned, we don’t want solution led requirements)
• missing acceptance criteria
• an incomplete process
• an untestable non-functional requirement
• a requirement with no identifiable business value

Finding problems in existing analysis can be just as important as creating artefacts from scratch, you may inherit this in real life, in fact, there’s a probability you will at some point.

10. Presenting your analysis

You may do excellent analysis and still be assessed poorly if you cannot explain it.

A presentation exercise tests something fundamental to BA work: can you take complexity and make it understandable?

You might have 10 or 15 minutes to explain:

The problem → what you discovered → what you don't know → your analysis → your recommendation → risks/next steps.

Do not spend eight minutes explaining your methodology.

The audience is interested in the problem (and your approach to understanding and defining it).

If you used a process map, explain what the map revealed. If you prioritised requirements, explain why. If you recommend Option B, explain why B is preferable to A and C.

The current Ministry of Justice Senior BA example is particularly instructive because its scenario exercise is followed by a presentation assessing technical BA skills and professional judgement. (VERCIDA)

The artefact isn't necessarily the final test.

Your ability to defend your thinking may be.

11. The interview questions after the exercise

Expect challenge (DO NOT SEE THIS AS BAD! IT’S NORMAL!).

A good interviewer may deliberately question your conclusions:

“Why did you prioritise that?”

“Why did you use a process map?”

“You've assumed the customer needs this. Where did that assumption come from?”

“What would you do if the stakeholder disagreed?”

“How would you validate that requirement?”

“What would you do next?”

Don't interpret challenge as evidence that you've failed, far from it.

They may be testing whether you can receive new information and change your position intelligently.

If the interviewer reveals something that invalidates your recommendation, saying:

“In that case, I'd change my recommendation because…”

can be a much stronger BA response than desperately defending your original answer. From a military perspective, they would say “never push a bad position”, in other words, if you’re wrong because new information has come to light, alter your position!

Business Analysis is not, repeat NOT, a competition to be right first time.

It is a discipline for getting closer to the right answer.

What are they actually assessing?

Different organisations will weight capabilities differently, but practical exercises tend to expose several things simultaneously:

• Problem definition: Do you understand what problem you are solving?
• Curiosity: Do you ask useful questions?
• Structure: Can you turn ambiguity into something manageable?
• Requirements capability: Can you create clear, testable requirements?
• Analysis: Can you distinguish symptoms, causes, assumptions and evidence?
• Stakeholder skills: Can you listen, challenge and communicate?
• Prioritisation: Can you make and explain trade-offs?
• Process thinking: Can you understand how work actually happens?
• Commercial awareness: Do you understand why the organisation is doing this?
• Delivery awareness: Can developers, testers and Product Owners actually use your analysis?
• Adaptability: What happens when new information appears?
• Communication: Can you explain complicated thinking simply?
• Professional judgement: Do you know when you have enough information to proceed and when you need to investigate further?

This is why memorising Business Analyst interview questions is valuable, but only a part of the problem to solve, i.e. “being selected for and then passing your BA interview.”

How to prepare for a practical BA assessment

The most effective preparation is surprisingly obvious:

… practise doing Business Analysis.

Take an everyday digital product and analyse it.

Choose online grocery shopping, booking a train ticket, making a GP appointment, ordering food or opening a bank account.

Give yourself 45 minutes.

Define a problem. Identify stakeholders. Write questions. Map part of the process. Create three user stories. Add acceptance criteria. Identify assumptions. Prioritise the stories. Consider non-functional requirements. Then explain your work aloud.

Next time, give yourself 30 minutes.

Then 20.

Practise sharing your screen while you do it. It sounds trivial but typing while talking and being observed is a different experience from quietly preparing an answer beforehand.

You should also practise deliberately incomplete scenarios. Don't give yourself all the information. Train yourself to recognise what is missing rather than unconsciously inventing it.

And prepare examples of your previous BA work that you can discuss without breaching client confidentiality. A sanitised process map, requirements example or case study can give you something concrete to explain if an employer asks how you have applied a technique in practice. I used to talk to myself imagining I was being interviewed (yes, I’m aware that makes me sound mad), so by the time the interview came, I felt as though I’d already had the conversation. Just make sure you do that bit when you’re alone, or people might actually think you’re mad.

Don't prepare to look perfect

This may be the most useful advice in this article.

A practical assessment isn't necessarily designed to see whether you can produce a flawless user story in 90 seconds.

It is designed to make your thinking visible.

So make it visible.

Say:

“I'm making an assumption here.”

“I don't think we have enough information to decide that yet.”

“I'd want to validate this with the user.”

“There are two possible interpretations of that requirement.”

“Before I recommend a solution, I'd like to understand the underlying problem.”

“I'd probably split this story because…”

“I've changed my view based on that information.”

Those are not signs of weakness.

They are evidence that analysis is taking place.

Practical BA capability is difficult to bluff

Business Analyst recruitment becomes much more revealing when an employer stops asking candidates what they would do and gives them something to actually do.

That is why you should prepare for more than just competency questions.

You could face a take-home analysis task, case study, requirements exercise, shared-screen user-story exercise, process-mapping problem, stakeholder role-play, data assessment, prioritisation challenge or presentation. Different employers will use different combinations, and some will use none at all. Current interview resources nevertheless consistently cover case studies, requirements, process analysis, user stories, acceptance criteria, data, stakeholder management and business judgement as areas candidates may be asked to demonstrate. (FirstHR)

The best preparation is therefore not to predict the exact exercise.

It is to strengthen the underlying capability.

Understand how you move from business problem → questions → evidence → analysis → requirements/options → validation → recommendation. Practise doing that with incomplete information and under time pressure. Practise explaining why you made each decision. Practise writing user stories and acceptance criteria while somebody watches. Practise challenging a requirement rather than obediently documenting it.

Because when an interviewer shares their screen and says, “Right, show me how you'd approach this,” your CV has finished doing its job.

Now they are assessing the Business Analyst.

 

Develop your practical Business Analysis skills with Elisto

Elisto's paid Business Analysis courses are designed around the practical application of BA techniques rather than simply learning terminology. If you want to strengthen the skills employers can test at interview, including requirements analysis, Agile Business Analysis, user stories, acceptance criteria and working through realistic delivery situations, please explore Elisto's wider Business Analyst training courses and downloads career support.

Knowing the theory can help you answer an interview question. Being able to apply it is what helps you prove you can do the job.