Role guide and interview toolkit

Business Analyst

What the work looks like, the contexts behind the title, what each level means and the training that helps, then how interviews run and how to prepare for each step.

Requirements·Process mapping·User stories·BPMN·SQL·UAT
The role in practice

What a business analyst actually does

An analyst who turns business needs into clear requirements that technical teams can build and test, and who knows the processes behind them.

The work

A business analyst helps business teams and technical teams understand each other. They run workshops, map the current processes, find what needs to change and write clear requirements or user stories.

They often support the testing, prepare user acceptance tests with business users and check that the delivered solution meets the need. Some business analysts use SQL to check data, or process mining tools such as Celonis to study processes.

Business analysts work in consulting firms, in IT services companies and in the IT teams of large companies, on ERP, CRM, data or custom software projects.

A typical week
  • A workshop with business users on a process
  • Writing requirements or user stories
  • Answering questions from developers
  • Preparing user acceptance tests
  • Checking data with SQL queries
Often confused with
Product OwnerOwns the backlog of a product and its priorities sprint after sprint.
Data AnalystAnalyses data and builds reports to answer business questions.
IT ConsultantAdvises clients and manages projects, often with a wider scope.
Project Manager / PMOOwns the plan, the budget and the risks of a project.
Contexts and tools

The same title, very different contexts

Most business analysis searches are defined first by the type of project, then by the ground every business analyst shares.

Process and ERPMethodsBPMN · CelonisTypical workProcess mapping · Fit-gap
Agile teamsMethodsScrum · KanbanTypical workUser stories · Backlog
Data and reportingMethodsSQLTypical workReporting needs · Data checks
RequirementsWorkshops, specs
ProcessesBPMN
TestingUAT
ToolsJira, SQL
Process miningCelonis
Levels

What each level means in practice

Titles vary from one company to the next. What changes from one level to the next is the scope you own and the decisions you take.

01Consultant
  • Works on a project with a senior analyst
  • Learns the business, the processes and the tools
  • Writes requirements with review
02Senior Consultant
  • Owns the requirements of a project on their own
  • Runs workshops with business users
  • Supports testing and the go-live
03Manager
  • Leads analysis on large projects
  • Manages several analysts or business areas
  • Shapes the solution with architects
04Director
  • Leads business analysis across projects
  • Sets the methods and the standards
  • Advises leadership on processes and systems
Education and certifications

The paths into the role, and what really counts

Companies look first at requirements you wrote and processes you understood. Education and certifications help most early in a career, or to change field.

Common paths
  • Business school or university degreeA common path for business analysts who work closely with business teams.
  • Engineering school or master's in ITA common path in France, often valued for technical projects.
  • Business user firstMany business analysts start in finance, logistics or sales before moving to IT projects.
  • Graduate programs in consultingConsulting firms recruit young graduates as junior business analysts.
Certifications
CBAP or other IIBA certificationsSometimes askedBusiness analysis certifications from IIBA, more common in large companies.
Scrum certifications (PSPO, CSPO)Rarely decisiveUseful in Agile teams, and your requirements count more.
Process mining certifications (Celonis)Rarely decisiveHelpful for process projects that use Celonis.

Our view: for this role, requirements you wrote and can walk through, from the workshop to the test, often say more than any certificate.

Your interview with us

A conversation with a senior tech recruiter

Your first interview is with one of our senior tech recruiters, who knows the role, the methods and the levels in this guide. The conversation covers your own work through real examples, and the case studies come later, with the company. Before the call, we send you the six themes we will cover so you can prepare your examples.

The six themes we share before the call
  1. What you owned yourselfThe requirements, processes or projects you were responsible for, and your own part in the team's work.
  2. Your environment and its constraintsBusiness needs, existing systems, deadlines or the people involved: what shaped your technical choices.
  3. The decisions you madeHow you captured the need, which solution you supported and why, the options you compared and the reasons for your choice.
  4. The impact of your workWhat changed thanks to your work, with numbers when you have them: time saved, errors removed, adoption or test results.
  5. How you work with other teamsYour work with business users, developers, testers and project managers, and how you settle a disagreement.
  6. What you want nextThe kind of projects, domain and scope you are looking for in your next role.
What we look at
  • Clear requirements
  • Process understanding
  • Bridge between business and IT

The same ground for every candidate. For a given role, every candidate answers the same final questions, built with the hiring manager around what the role really needs.

Ready for the next steps. After our call, we tell you how the company runs its interviews, who you will meet at each step and what each step is meant to assess.

Interviews with the company

What the company will assess, step by step

Each company runs its own process, and we walk you through its steps before you start. Business analysis processes often combine the steps below, and the depth expected at each step grows with your level.

The steps you will often meet
  1. A case studyA business need to analyse, with the questions you would ask and the requirements you would write.
  2. A requirements exerciseUser stories or a process map to write from a short description, live or as a take‑home.
  3. A deep dive on a past projectOne project you worked on, discussed in depth: the need, your requirements and the result.
  4. Meeting the manager and the teamHow you work, how you take decisions with others and what the team expects in your first months.
What changes with your level
  • Senior ConsultantYou ask the right questions, write clear requirements and explain them in simple words.
  • ManagerYou lead the analysis, connect the need to the process and point out gaps and risks before you are asked.
  • DirectorYou run most of the interview as a peer, think about several processes and connect them to the goals of the company.
Your interview toolkit

How to prepare as a business analyst

Practical advice for each step of a business analysis process, from the way you introduce yourself to the questions you ask at the end of each interview.

01Introduce yourself in two minutes

Start with the projects and processes you worked on, their context and your part in them. Mention your main methods and tools in one sentence, then close with what you want next.

02Prepare two projects

For each one, prepare the context, the constraints, your decision, the options you set aside, the result and what you would change today. Say "we" for the team and "I" for your own part.

03Ask before you write

In a case study, ask who the users are, what the process is today and what success looks like before you write anything.

04Bring an example

Prepare one real requirement or user story you wrote, anonymised, and explain why you wrote it that way.

05Show the bridge

Prepare one example where you explained a business need to developers, or a technical limit to business users.

06Check the rules on AI tools

Rules on AI tools differ from one company to the next, especially for take‑home cases. Ask before each step, and when they are allowed, explain what you asked the tool and how you checked its output.

Questions you will often hear
  • Walk us through a project where you wrote the requirements.
  • How do you run a workshop with business users?
  • How do you handle conflicting needs from two teams?
  • How do you check that the delivered solution meets the need?
Questions worth asking them
  • Which projects and business areas would I work on?
  • How do business analysts and product owners share the work?
  • Which methods and tools does the team use?
  • How are business users involved in testing?
  • How is the work of a business analyst reviewed?
  • How does the team use AI tools in its daily work?
Where the role leads

Where business analysts come from, and where they go

The roles people most often hold before this one, and the ones they most often move to.

Many business analysts also start as business users, data analysts or testers.