Business Analyst interview questions for experienced

User Acceptance Testing (UAT) is the final test phase. Business users confirm that the solution meets their needs before go-live.

BA role:

• Help define the UAT scope and scenarios from the requirements and acceptance criteria.
• Write or review test cases in business language.
• Arrange users, test data, and the environment.
• Sort defects: a real defect, a change request, or a misunderstanding.
• Track results and get formal sign-off.

UAT is not for finding every bug. That is QA's job. UAT checks that the solution fits real business processes.

What they are checking: Do you know how UAT differs from QA testing?

A BA should be able to read data and answer questions. Use SELECT, WHERE, ORDER BY, GROUP BY with aggregates, HAVING, JOINs, and simple subqueries. Writing data (INSERT, UPDATE, DELETE) is usually left to developers.

Example: total claim amount per provider for 2025, only for providers above 100000:

SELECT p.provider_name, SUM(c.amount) AS total_amount
FROM claims c
JOIN providers p ON p.provider_id = c.provider_id
WHERE c.service_date >= '2025-01-01' AND c.service_date < '2026-01-01'
GROUP BY p.provider_name
HAVING SUM(c.amount) > 100000
ORDER BY total_amount DESC;

Use SQL to check requirements against real data, find duplicates and nulls, and check reports.

What they are checking: Do you have practical data skills, not just theory?

I treat it as an analysis problem. I bring a recommendation, not just a complaint to the sponsor.

1. Clarify each position. Separate the real need from the proposed solution. Often the needs fit together even when the solutions do not.
2. Check each position against the business goal and success measures. Measure the...

First I find out why. It could be a new business need, a missed requirement, or just a preference. Then I run an impact analysis using the traceability matrix. I check which requirements, designs, and tests change. I check the effect on effort, schedule, cost, and risk.

I make my case with evidence. Then I support the decision. First I make sure I understand their reasons and the problem behind the request. Then I bring analysis: user data or research, cost and complexity, risk, conflict with other priorities, and the likely effect on the business goal. I suggest simpler options that meet the same need. I also suggest a cheap test, such as a prototype or a limited release, to check the idea.

A use case describes how an actor (a user or another system) interacts with the system to reach a goal. It includes the main flow, other flows, and exceptions. A user story is a short statement of a need, with acceptance criteria.

An RTM is a table that links each requirement to its source (a business goal). It also links forward to design, development, test cases, and release. It proves that every requirement is covered. It also shows that every test or feature has a reason to exist.

Gap analysis compares the current state (as-is) with the wanted state (to-be). It finds what is missing to get there.

Steps:

1. Define the wanted future state and the success measures.
2. Document the current state (process, systems, skills).
3. List the gaps.
4. Suggest actions, rank them, and estimate the effort.

I document a process by interviewing the people who do it. I walk through real examples. Then I draw it as a flow with clear owners and decisions.

The product backlog is the ordered list of everything that might be built: features, fixes, and technical work. The product owner owns the order.

Verification checks that requirements are well written. Validation checks that they are the right requirements.

A good requirement is one clear statement that you can test, with a measurable result. For example: "The system shall show search results within 2 seconds for 95% of queries."

A want is a proposed solution ("add an export button"). A need is the real problem behind it ("finance must reconcile weekly figures without typing the data again"). If you take wants literally, the solution is often poor.

A practical BRD includes:

• Executive summary and the business problem.
• Objectives and success measures (KPIs).
• Scope: what is in and what is out.
• Stakeholders and their roles.
• Current state and wanted future state.
• Business requirements and business rules, with priorities.
• Assumptions, limits, and dependencies.
• Risks and how to reduce them.
• Cost-benefit or a summary of the business case.
• Glossary and approvals.

I check the change against everything it touches before anyone approves it.

1. Understand the request and the business reason.
2. Use the traceability matrix to find the affected requirements, designs, tests, and interfaces.
3. Estimate the effect on effort, cost, and schedule with the technical team.
4. Find the...

First I find the cause. It may be unclear first requirements, a changing business situation, or a stakeholder who was not involved enough. Then I do these things:

• Confirm the baseline again and show the agreed change process.
• Ask for each change to come with a reason and business value, and run an impact analysis....

I compare the behaviour with the approved requirement and acceptance criteria.

• If the system does not behave as written, it is a defect. It goes to the development team by severity.
• If it behaves as written but the user wants something different, it is a change request. It needs an impact analysis.
• If the requirement was unclear or missing, it is a requirements gap. I own the fix of the document. After that it is handled as a defect or a change, depending on what was agreed.

I ask questions until it is concrete. Who uses it, and which decision does it support? Which metrics and definitions? Which data sources? How fresh must the data be? Who may see what? What do they do today, and what is the pain? What does success look like?

I make the criteria clear and use data. With stakeholders I agree on the goals and a scoring method (MoSCoW, weighted scoring on value, effort, risk, and urgency, or value versus effort). I measure value where I can (revenue, cost saving, compliance deadline). I get effort estimates from the team. I check...

The product owner owns the product vision and the backlog priorities. They make the value decisions. The BA analyses the problem, gathers and writes down the details, and helps the team understand and deliver.

Use the STAR structure and focus on your own analysis:

• Situation: the business problem and its measurable pain (for example, orders took 5 days to process).
• Task: your role and the goal.
• Action: how you collected data, interviewed stakeholders, and modelled the as-is process. Then how you found the root cause, compared options, and recommended one. Include any conflict you solved.
• Result: the measured outcome (cycle time down to 2 days, errors cut by 40%) and what you learned.

These are requirement levels in the BABOK view.

• Business requirements: high-level goals of the organisation. Example: reduce claim processing time by 30%.
• Stakeholder requirements: needs of specific groups or roles that must be met to reach the business goal. Example: claims adjusters need one view of the...

A DFD shows how data moves through a system: external entities, processes, data stores, and data flows. A context diagram is the top-level (level 0) DFD. It shows the system as one process, with its external entities, and it shows the system boundary.

I make it easier for them and escalate through the right channel. I send short, specific questions with options, not open requests. I book short, fixed time slots. I use existing documents and data to prepare a draft that they can correct. People react to a draft faster than they write from scratch. I find a delegate...

I go back to the real need. I work with the architect or lead developer to understand the limit and the cost. Then I offer alternatives: a simpler version that gives most of the value, delivery in phases, a ready-made product, or a manual workaround for now. I show the cost, benefit, and risk of each, with a recommendation, to the stakeholder and get a decision. Saying "it cannot be done" without options is not useful.

I ask them to explain it back in their own words. I walk through examples and acceptance criteria. I use models or prototypes together with text. Before development, I hold a three amigos session (BA, developer, tester), so questions come up early. I stay available during the sprint. Reviewing test cases against the requirement is another good check, because testers read requirements very literally.

Root cause analysis finds why a problem happens, so the fix removes the cause and not just the symptom. Techniques:

• The 5 Whys: ask why many times.
• The fishbone (Ishikawa) diagram: group causes by people, process, system, data, and environment.
• Pareto analysis: find the few causes behind most of the effect.

I keep documents small but alive. I use user stories with acceptance criteria in the backlog tool, a short product vision, and a decision log. I add process or data models where they help. I use visuals (wireframes, flow diagrams) and examples instead of long text. I keep details close to the story and update them...

I would not stay silent, and I would not argue from opinion. A BA is accountable for the quality of the analysis. So I bring a recommendation backed by evidence.

I work from the message to the cause:

1. Get the failing raw message and the ACK or error code from the engine logs.
2. Check the header: version, message type and event, sending application, and delimiters.
3. Check the required fields against the interface specification. Look at the PID-3 identifier, the name, the...

ORU^R01 is an unsolicited observation result message. It is used mostly for lab and radiology results. It carries the patient (PID), usually the visit (PV1), the order (ORC and OBR), and one or more OBX segments with the results.

FHIR itself does not define security. So servers use OAuth 2.0 and OpenID Connect over TLS. SMART on FHIR is the standard profile for this. It defines how an app is launched (EHR launch or standalone). It defines how the app finds endpoints (.well-known/smart-configuration). It uses the authorization code flow with PKCE. It also defines scopes such as patient/Observation.read or user/*.read.

C-CDA (Consolidated Clinical Document Architecture) is an XML document standard, based on HL7 CDA. It summarises a patient's clinical information. A document has a header (patient, author, custodian) and a body made of sections. Sections include problems, medications, allergies, immunisations, vital signs and results. Each has a readable narrative and coded entries.

837P is the professional claim. Doctors and other practitioners use it. It maps to the CMS-1500 form. 837I is the institutional claim. Hospitals, nursing facilities and other facilities use it. It maps to the UB-04 form. 837D is for dental.

An 837 is organised in loops that sit inside each other:

• 2000A: billing provider (NM1*85, plus NPI and tax ID)
• 2000B: subscriber/insured (SBR segment, member ID, payer in 2010BB)
• 2000C: patient, only when different from the subscriber
• 2300: claim information (CLM with claim ID, total charge and place of service; HI with diagnosis codes; DTP dates)
• 2400: service lines (SV1 for professional, SV2 for institutional, with procedure code, charge and units)

Use layers of controls:

• Encrypt data in transit (TLS) and at rest.
• Use role-based access, least privilege, MFA, and audit logs of who accessed what.
• Minimum necessary: pass only the fields that are needed.
• Do not use real PHI in lower environments. Use de-identified or synthetic data, masking or tokenisation...

HCC (Hierarchical Condition Category) risk adjustment is used by CMS for Medicare Advantage. It predicts the expected cost of a member from age, sex and diagnoses. Diagnosis codes on claims and encounters map to HCCs. Each HCC has a weight. The weights add up to a risk adjustment factor (RAF) score. This score raises or lowers the payment to the plan. Hierarchies keep only the most severe condition in a related group.

HL7 v2 is event driven and push based. A system sends a message when something happens. Formats differ between sites, and mapping is often custom. FHIR is based on resources and APIs. Clients query or subscribe to well-defined resources over REST. It has built-in versioning, search and standard profiles (such as US Core).

I start with the 835 or the payer response. The group and reason codes (CARC/RARC) usually name the field. Then I trace the claim data back through the 837 to the source (registration, charge capture). I check the member ID format, subscriber and patient details, billing and rendering NPI, taxonomy, diagnosis pointer,...

Likely causes: the sender retried because the ACK was missing or slow. The engine reprocessed a queue. Result corrections arrived as new results. Or two sources feed the same system. I check the message control IDs (MSH-10), the placer/filler order numbers and the OBR/OBX result status (F final, C corrected).

I would not just pick one. First I confirm that the records are really the same person. I use the MPI match evidence (identifiers, name, date of birth). Then I define survivorship rules (which value wins) with the data owners. For each field, decide which system is the source of truth, or let the most recent verified...

A clearinghouse sits between providers and payers. It receives claims, checks them against payer rules, and changes the format if needed. It sends them to the right payer. It returns acknowledgements (999, 277CA) and remittances. It reduces rejections. A provider needs only one connection, not one for each payer.

CARC (Claim Adjustment Reason Codes) explain why the paid amount differs from the billed amount. They appear in CAS segments on the 835, together with a group code: CO (contractual obligation), PR (patient responsibility), OA (other adjustment), PI (payer initiated). RARC (Remittance Advice Remark Codes) give more information or next steps. Together they drive denial management and automatic posting rules.

They are clinical terminologies. They give coded data that different systems can share.

• LOINC: identifies lab tests and clinical observations (for example 718-7 hemoglobin).
• SNOMED CT: a full set of clinical terms for conditions, findings and procedures.
• RxNorm: standard names and identifiers for medicines.

MLLP (Minimal Lower Layer Protocol) is the simple wrapper used to send HL7 v2 over TCP. A message is wrapped with a start block character (0x0B) and an end block (0x1C followed by carriage return 0x0D). The receiver reads the message and returns an ACK in the same wrapper. It is not encrypted. So it is normally used inside a private network, or over a VPN or TLS tunnel.

An ACK is the receiver's reply to an HL7 v2 message. MSA-1 holds the code. MSA-2 holds the control ID of the original message.

• AA: application accept. It was processed successfully.
• AE: application error. There was a problem processing it. The sender may fix it and send it again.
• AR: application reject, for example an unsupported message type or version. Sending it again as is will not help.

An MPI links records from different systems to one person. Matching is hard because of typos, nicknames, changed names or addresses, missing data, and shared identifiers like a family phone number. Approaches: deterministic matching on exact keys, probabilistic matching that scores how similar fields are, and manual review of unclear pairs. A wrong merge (two people joined into one) is a patient safety risk. So the thresholds are set carefully.

First I clarify the requirements. How many checks, and how fast? Which payers? Does the payer have a real-time API, or is there a clearinghouse? What does the screen need from the 271 (active status, copay, deductible, plan type)?

Bring in the 837/835 and 834 files (by SFTP or from the clearinghouse) into a landing zone, and keep the raw file. Parse them into staging tables and validate them (envelope counts, required fields). Standardise codes and map member IDs through the member master. Remove duplicate claim versions (original, replacement,...

Business: which workflow (eligibility, claims, prior auth, status), what outcome, volumes and service levels. Technical: which standard and version (X12 5010, FHIR R4), transport and authentication, test environments, who sends first. Data: required fields, code sets and mapping, and how corrections and cancellations...

The Cures Act (US) promotes interoperability and bans information blocking. Patients and their approved apps must be able to access their electronic health information. USCDI (United States Core Data for Interoperability) is the standard set of data classes and elements, such as allergies, medications, problems, lab results and notes. Certified systems must be able to exchange them. US Core FHIR profiles implement it. For a BA or integrator, this defines what patient access APIs must provide.