Infosys Business Analyst Interview Questions 2026

Tip: A BRD is the business-facing definition of “what success looks like” for a change. It captures the problem, the outcome, and the boundaries—without committing to implementation details. A strong BRD includes: context and pain points (what is broken today), measurable business objectives (e.g., “reduce TAT from 48h to 12h”), in-scope and out-of-scope items, stakeholders and decision owners, functional requirements written as capabilities, non-functional requirements (latency, audit logs, access control, compliance), assumptions and constraints, dependencies, and success metrics. In interviews, show you can turn vague asks into testable acceptance: “Users should get faster approvals” becomes “95% of approvals within 12 hours, with an audit trail for every decision.”

Tip: Functional requirements define what the system must do: user actions, business rules, workflows, and outputs (e.g., “finance user can export GST report by month”). Non-functional requirements define how well it must do it and under what constraints: performance (p95 < 2s), scalability (10k concurrent users), reliability (99.9% uptime), security (RBAC, encryption), observability (logs/alerts), and compliance. The BA failure mode is shipping “features” that break in the real operating environment. A practical example: “Generate monthly report” is functional; “export must complete in < 30 seconds for 1M rows, with a retry-safe job id and audit logs” is non-functional.

Tip: Start with the workflow, not the feature. Ask them to walk you through the current process step-by-step (who does what, using which tool, where it breaks). Then anchor on outcomes: “What decision are we trying to make faster or safer?” Use probing questions to expose constraints: approvals, policy rules, exceptions, and handoffs. When they are unsure, use concrete artifacts: a rough prototype or a process diagram and ask for reactions (“At this step, what can go wrong?”). Use 5 Whys to separate symptom from root cause. Close by writing acceptance criteria in their language and confirming: “So success is: approvals within 12 hours, manager override allowed with reason, and every state change logged. Correct?” That confirmation is the requirement.

Tip: Use aggregation to count orders per customer, then filter with HAVING (because the filter depends on an aggregate). Example: `SELECT customer_id, COUNT(*) AS order_count FROM orders GROUP BY customer_id HAVING COUNT(*) > 5;`. In interviews, add the two BA signals: (1) state assumptions (“orders has one row per order; cancelled orders excluded via status”), and (2) explain correctness (“WHERE filters rows before grouping; HAVING filters groups after aggregation”). If cancellations matter: `WHERE status != 'cancelled'` before the GROUP BY. This is exactly how you validate business claims like “repeat buyers fell this month.”

Tip: Gap analysis is the structured comparison between the current state (as-is) and the target state (to-be), followed by an actionable plan to close the gaps. In BA work: document the current workflow (swimlanes, pain points, cycle time), define the target outcome and constraints (speed, accuracy, compliance), identify the gaps (missing data, manual handoffs, unclear ownership, tooling limits), then prioritize fixes based on impact and feasibility. Example: if onboarding takes 5 days because KYC is manual, the gap may be “no automated document validation + no SLA tracking.” Your deliverable is not the diagram—it is a recommended initiative list with owners, dependencies, and success metrics.

Tip: A use case diagram is a high-level UML view of system scope: actors (user types or external systems), the system boundary, and the major use cases (capabilities). Use it when you need to align stakeholders on scope and roles early—especially when multiple actors interact with the same system (customer, agent, manager, audit team). User stories are the delivery unit: small, sprint-ready, and tied to acceptance criteria. In interviews, say it plainly: “Use case diagrams reduce scope confusion; user stories reduce build ambiguity.” Often you start with a use case diagram, then break it into stories for delivery.

Tip: Show that you can handle change without chaos. First, capture the change as a clear statement (“Add approval step for refunds above ₹10k with audit trail”). Then run an impact analysis: scope (new screens/states), timeline (extra sprint?), cost, dependencies, and risks (data migration, permissions). Present options: ship current scope first vs include now; explain trade-offs. Get stakeholder sign-off in writing, update the BRD/user stories/acceptance criteria, and align QA on new test cases. A strong BA answer includes the “why”: “We changed because compliance required it; we preserved delivery by slicing an MVP and deferring reporting to Phase 2.”

Tip: Start with decomposition, not guesses. Break revenue into drivers: traffic/volume × conversion × price × retention (or ARPU). Segment quickly: which product line, geography, customer cohort, or channel is responsible for most of the drop? Then validate with data (SQL or dashboards): did orders fall, did AOV fall, or did refunds rise? Correlate with internal events (release, pricing change, payment gateway issue) and external events (seasonality, competitor discount). A BA-quality answer ends with an action: “We isolated the drop to Android checkout conversion after release X; error rate spiked on UPI. Roll back + add monitoring + write a postmortem.”

Tip: Do not defend—diagnose. Ask for the specific rejection reason: data accuracy, methodology, missing context, or an uncomfortable implication. If it is data: re-check definitions, joins, filters, and time windows; share a reproducible query or source. If it is methodology: explain assumptions and show sensitivity (“If we exclude refunds, the trend changes by X”). If it is interpretation: separate facts from recommendations and propose a decision path. Time-box the fix: “I can resolve the accuracy issue in 2 hours; otherwise we ship with the earlier baseline and document the risk.” Escalate with options, not drama.

Tip: A process flow diagram visualizes the sequence of steps, decision points, and ownership in a workflow. Swimlanes make responsibility explicit (Customer vs Ops vs System). Create one by: defining the start and end event, listing the steps in order, adding decision diamonds for branches (“KYC passed?”), annotating inputs/outputs, and marking handoffs (where delays and errors often occur). In BA interviews, mention how you use it: you map as-is to find bottlenecks, propose a to-be, and then derive user stories and acceptance criteria from each step and exception.

Tip: Make priorities explicit, comparable, and documented. First, clarify each stakeholder’s goal and metric (cost, speed, compliance, growth). Then translate requests into impact: user value, risk, effort, and dependency. Use a simple prioritization model (impact vs effort, or MoSCoW) and validate in a joint meeting so trade-offs are visible to all, not negotiated privately. If conflict remains, escalate with a recommendation and rationale (“Compliance requirement blocks release; we must ship audit logs first”). Close the loop by writing the decision, owner, and review date—this prevents priority drift.

Tip: Name tools in context of artifacts. For documentation: Confluence/Notion/Google Docs for BRDs, decision logs, and meeting outcomes (with version history). For backlog: Jira/Azure DevOps for stories, acceptance criteria, and sprint support. For modelling: Lucidchart/draw.io/Visio/Miro for swimlanes and BPMN. For traceability: Excel/Sheets for a requirement-to-test-case matrix when stakes are high (compliance, payments). For analytics: SQL + dashboards (Power BI/Tableau) to validate assumptions. Interviewers are listening for your workflow: “I capture decisions, I turn them into stories, I model the process, and I validate metrics.”