Business Analyst interview questions for freshers

A business analyst (BA) connects the business and the technical team. They understand a business problem. They turn it into clear requirements that can be tested. They make sure the final solution really solves the problem.

Typical work:

• Ask stakeholders what they need, through interviews, workshops, and watching the work.
• Analyse and write down requirements (user stories, use cases, process models).
• Find gaps, risks, and conflicts early, and suggest options with trade-offs.
• Help developers and testers with questions, and help run UAT (user acceptance testing).
• Track changes and keep every requirement linked to a business goal.

A BA owns the quality of the analysis. The value is not in taking notes. The value is in asking why, questioning assumptions, and recommending a solution.

What they are checking: Do you see the role as analysis and advice, not just writing documents?

They record requirements at different levels, for different readers.

In practice, a BRD explains why the project is needed. An FRD describes what the solution does. An SRS is the detailed agreement that developers build from and testers check against. Many agile teams replace all three with a backlog of user stories and a short vision document.

What they are checking: Can you place each document in the right level of requirements?

Elicitation means drawing requirements out of stakeholders. Common techniques:

• Interviews: one to one. Good for depth and sensitive topics.
• Workshops (JAD sessions): group sessions that align many stakeholders quickly.
• Observation (job shadowing): watch the real work to find steps that people forget to mention.
• Document analysis: read existing manuals, reports, and policies.
• Surveys and questionnaires: reach many people at low cost.
• Prototypes and wireframes: let users react to something they can see.
• Brainstorming and focus groups: collect ideas.
• Reverse engineering of an old system.

Use a mix. Interviews plus observation usually show the gap between what people say and what they do.

What they are checking: Do you know many techniques, and can you match them to situations?

A user story is a short description of a need from the user's point of view: "As a <role>, I want <goal>, so that <benefit>."

A good story follows INVEST:

• Independent: can be built without depending on another story.
• Negotiable: details are discussed, not fixed.
• Valuable: gives value to a user or the business.
• Estimable: the team can size it.
• Small: fits within a sprint.
• Testable: has clear acceptance criteria.

Example story: "As a patient, I want to reschedule an appointment online, so that I do not need to call the clinic". The story starts a conversation. It is not a full specification.

What they are checking: Do you know INVEST and the "so that" part?

Acceptance criteria are the specific conditions a story must meet to be accepted. You can test each one. They remove doubt about what "done" means.

They are often written in Given/When/Then form:

• Given a registered user is on the login page
• When they enter a valid email and password
• Then they land on the dashboard

Add negative cases and edge cases too. A wrong password shows an error and does not say which field was wrong. After five failed attempts the account locks for 15 minutes.

Good criteria are pass or fail. They cover the normal path, errors, and limits. You can turn them directly into test cases.

What they are checking: Can you test your criteria, and do they include negative cases?

Functional requirements describe what the system does. Non-functional requirements describe how well it does it.

• Functional: "The system shall let a user reset a password using an emailed link."
• Non-functional (quality attributes): performance (page loads in under 2 seconds) and security (data encrypted at rest). Others are availability (99.9% uptime), scalability, usability, compliance (audit logging), and maintainability.

People often forget non-functional requirements. Then they cause the most costly rework. So a BA should ask about them directly and make them measurable.

What they are checking: Do you capture quality needs, not just features?

MoSCoW sorts requirements into four groups:

• Must have: without it the release fails, or it is illegal or unsafe.
• Should have: important, but there is a workaround for now.
• Could have: nice to have. Include it if time allows.
• Won't have (this time): agreed to be out of scope for this release.

Tips: keep Musts to about 60% of the effort, so there is room for risk. Agree on the groups with stakeholders in a workshop. Write down the Won't haves so expectations are clear. Other methods include value vs effort, Kano, and weighted scoring.

What they are checking: Do you know prioritisation words, and can you use them?

In Waterfall, the BA gathers detailed requirements up front and gets them signed off. Then design, build, and test follow in phases. Change is formal and costly.

In Agile, the BA works all the time with the product owner and the team. They refine the backlog and write user stories. They clear up details just in time and support each sprint review.

The BA skills are the same: elicitation, analysis, and communication. Only the rhythm and the documents change.

What they are checking: Can you adapt to different ways of delivering projects?

INNER JOIN returns only the rows that have a match in both tables. LEFT JOIN returns all rows from the left table, plus the matching rows from the right. Where there is no match, the right side is NULL.

A user directly uses the solution. A stakeholder is anyone who is affected by the project or can influence it. This includes sponsors, regulators, support teams, and users.

Scope creep is uncontrolled growth of scope after the baseline is agreed. It usually comes from small requests that nobody records.

A flowchart shows the steps and decisions of a process in order. A swimlane diagram is a flowchart split into lanes, one lane for each role, team, or system. It shows who does each step and where the hand-offs happen.

The as-is model shows how the process really works today, including workarounds. The to-be model shows the better process after the change.

A RACI matrix assigns each task or deliverable to roles:

• Responsible: does the work.
• Accountable: owns the result and signs off (only one per item).
• Consulted: gives input before the work.
• Informed: is told afterwards.

A business rule is a policy or limit of the organisation. It exists whether or not there is a system. Example: "a refund over 500 needs manager approval". A requirement is what the system must do or support. Example: "the system shall send refunds over 500 to the manager approval queue".

• Wireframe: a simple layout sketch that shows structure and flow, with no styling.
• Mock-up: a static, detailed visual design with colours, fonts, and real content.
• Prototype: an interactive model that users can click through to test the flow.

Unit testing (developers, one component). Integration testing (components together). System testing (end to end, against the requirements). Regression testing (old features still work). Performance and security testing. User acceptance testing (business sign-off).

HL7 (Health Level Seven) is a set of standards for sharing health data between systems.

v2 is by far the most used for internal hospital interfaces. CCDA is used to exchange documents. FHIR is the direction for new APIs and rules.

What they are checking: Can you place each standard and say where it is used?

An HL7 v2 message is a text message made of segments, one per line. Inside a segment, fields are separated by |, components by ^, repetitions by ~, the escape character is \ and sub-components are separated by &.

Common segments:

• MSH: message header (sender, receiver, message type, control ID, version)
• EVN: event
• PID: patient identification
• PV1: patient visit
• OBR: observation request
• OBX: observation result
• ORC: common order
• NK1: next of kin
• AL1: allergy
• DG1: diagnosis
• IN1: insurance

MSH|^~\&|ADT|HOSP|EHR|HOSP|20250101120000||ADT^A01|MSG0001|P|2.5
EVN|A01|20250101120000
PID|1||123456^^^HOSP^MR||DOE^JANE||19900101|F
PV1|1|I|WARD1^101^A

MSH-9 tells the receiver what the message is. The receiver replies with an ACK.

What they are checking: Can you read a raw HL7 message?

ADT (Admit, Discharge, Transfer) messages tell other systems about patient registration and movement. The trigger event is the part after the caret in MSH-9.

• A01: admit/visit notice
• A02: transfer a patient
• A03: discharge/end visit
• A04: register a patient (outpatient/ED)
• A08: update patient information
• A11: cancel admit
• A40: merge patient identifiers

ADT feeds keep lab, radiology, pharmacy and billing systems in sync with the patient master record and bed status.

What they are checking: Do you know the most common message type?

A FHIR resource is a small unit of healthcare data with a standard structure. It is identified by a type and an id. Examples: Patient, Practitioner, Organization, Encounter, Observation, Condition, MedicationRequest, AllergyIntolerance, Procedure, DiagnosticReport, Claim, ExplanationOfBenefit, Coverage, and Bundle (a container for resources).

{"resourceType": "Patient", "id": "123", "name": [{"family": "Doe", "given": ["Jane"]}], "gender": "female", "birthDate": "1990-01-01"}

Resources point to each other. An Observation points to a Patient through subject. This forms the data model.

What they are checking: Do you know the core FHIR words?

FHIR uses standard HTTP verbs on resource URLs, with JSON or XML bodies:

GET    /Patient/123                       read one
GET    /Patient?family=Doe&birthdate=1990-01-01   search
POST   /Patient                           create (returns 201 and Location)
PUT    /Patient/123                       update (replace)
PATCH  /Patient/123                       partial update
DELETE /Patient/123                       delete
GET    /metadata                          CapabilityStatement
GET    /Patient/123/_history              versions

A search returns a Bundle of type searchset with paging links. Use _include and _revinclude to get related resources. Use Observation?patient=123&code=http://loinc.org|718-7 to search by code.

What they are checking: Can you use APIs in practice?

EDI (Electronic Data Interchange) is the structured exchange of business documents between computers. In US healthcare, HIPAA requires the ASC X12 standard (version 5010) for admin transactions between providers, payers and clearinghouses.

X12 files are made of segments that end with ~. Elements are separated by *, and sub-elements by :. The envelope has ISA/IEA (interchange), GS/GE (functional group) and ST/SE (transaction set). Key transactions: 837 claims, 835 remittance, 270/271 eligibility, 276/277 claim status, 278 prior authorisation, 834 enrolment, 820 premium payment.

What they are checking: Do you know EDI basics and the envelope structure?

A 999 confirms that a file was accepted in terms of syntax.

What they are checking: Do you know the core transaction map?

1. Registration and eligibility: collect insurance, check coverage (270/271), and get prior authorisation if needed.
2. Service delivery and notes.
3. Charge capture and coding: assign ICD-10 diagnosis codes and CPT/HCPCS procedure codes.
4. Claim creation and scrubbing: build the 837 and run checks to catch errors.
5. Submission to the payer through a clearinghouse.
6. Adjudication: the payer checks eligibility, medical need, coding and price. Then it pays, denies or holds the claim.
7. Remittance: the 835 and the EOB explain the payment and adjustments.
8. Payment posting and billing the patient for the balance.
9. Denials and appeals, then follow-up.

A BA should know where data can break at each step.

What they are checking: Do you understand the domain from start to end?

A rejection happens before adjudication. The claim failed format or front-end checks, for example missing data, an invalid code or a wrong member ID. It was never processed. You must correct it and send it again.

A denial happens after adjudication. The payer processed the claim and refused to pay. Typical reasons are no coverage, no authorisation, not medically necessary, or filing too late. You handle a denial by correcting the claim and appealing. Use the CARC and RARC codes on the 835 to understand why.

What they are checking: Do you know the difference between a rejection and a denial?

HIPAA (Health Insurance Portability and Accountability Act, US) protects health information and sets standard transactions. Main rules:

• Privacy Rule: who may use or share PHI. Patients can see their data and ask for changes. Share only the minimum necessary.
• Security Rule: admin, physical and technical safeguards for electronic PHI (access control, audit logs, encryption, risk analysis).
• Breach Notification Rule: after a breach, tell the people affected, the regulators, and sometimes the media.
• Transactions and Code Sets Rule: standard X12 formats and code sets.
• Enforcement Rule: penalties.

It applies to covered entities (providers, plans, clearinghouses) and their business associates. Business associates sign a Business Associate Agreement (BAA).

What they are checking: Do you know the compliance rules?

PII (personally identifiable information) is any data that can identify a person, such as name, national ID or email. PHI (protected health information) is health information that identifies a person. It covers past, present or future health, care, or payment for care. It is held or sent by a HIPAA covered entity or business associate, in any form.

• ICD-10-CM: diagnosis codes (what is wrong). They are alphanumeric, up to 7 characters, for example E11.9 for type 2 diabetes without complications. ICD-10-PCS is used for hospital inpatient procedures.
• CPT: procedure and service codes kept by the AMA. They have five characters, for example 99213 for an office visit. Modifiers change them.
• HCPCS Level II: codes for supplies, equipment, drugs and services outside CPT, for example J-codes for injectable drugs.

A Bundle is a resource that holds a collection of other resources. Its type sets its purpose: searchset (search results), document (a clinical document), message, collection, batch and transaction.

HEDIS (Healthcare Effectiveness Data and Information Set) is a set of quality measures kept by NCQA. Health plans report them. They cover areas such as breast cancer screening, diabetes care (HbA1c control), childhood immunisations and taking medicines as prescribed. The data comes from claims, EHRs and registries. The results feed plan ratings and Medicare Star ratings. To find gaps in care, check whether an eligible member had a qualifying service in the measurement year.

An interface engine is middleware. It receives messages from one system, checks and changes them, and sends them to other systems. So each system needs only one connection. Typical features: connectors (MLLP, HTTP, SFTP, database), filters, mapping and transformation, queuing and retry, logging and monitoring.

The National Provider Identifier is a unique 10-digit number. CMS gives it to US healthcare providers and organisations. HIPAA requires it on standard transactions such as claims. Type 1 NPIs are for individuals. Type 2 NPIs are for organisations.

Prior authorisation is the payer's approval. It is required before some services or drugs. It confirms medical need and coverage. The provider sends a request (X12 278, a portal, or more and more a FHIR-based API) with clinical details. The payer approves, denies or asks for more information. It returns an authorisation number that must go on the claim. Missing or expired authorisations are a common cause of denials. So track them when the visit is scheduled.

An EMR is the digital chart inside one practice. An EHR is built to share patient information across organisations and care settings. A provider gives care (doctor, hospital, lab). A payer pays for it (insurer, government programme). Providers send claims to payers and receive payment. Payers also run eligibility checks, utilisation management and quality programmes.