Burgeon IT Services Business Analyst Interview: Questions, Experience & Prep (2026)

Burgeon IT Services is an IT staffing and managed services firm that places Business Analysts with clients across sectors like BFSI, retail, and technology. As of July 2026, knok jobradar is tracking 4 open BA roles at the company, part of a broader market with 398 active BA postings across India.

Candidates report that the selection process typically involves 2 to 3 rounds: an initial HR screening, a technical or domain round focused on BA skills, and a final managerial or client-facing round. Expect questions on requirement gathering, stakeholder management, process mapping, SQL basics, and Agile delivery. Interviewers want to see that you can translate business needs into clear requirements that a development team can act on.

Roles are currently open across multiple cities, with the highest concentration of BA openings in Bangalore (53), Delhi (48), and Mumbai (24) based on current market data.

Here are the questions candidates report coming up most often in Burgeon IT Services BA interviews:

1. Walk us through a requirements-gathering session you led from start to finish.
2. How do you handle a situation where business stakeholders and the development team disagree on a requirement?
3. Explain the difference between functional and non-functional requirements, with an example from your own work.
4. How do you prioritise a backlog when multiple stakeholders have conflicting priorities?
5. Describe a time you spotted a gap in a business process and recommended a fix. What was the result?
6. What tools do you use for documentation, and how do you keep requirements updated across sprint cycles?
7. How comfortable are you with SQL? Walk through a query you wrote to answer a business question.
8. How do you manage scope creep during a project?
9. Describe how you write user stories and define acceptance criteria.
10. How do you communicate project risks to a non-technical stakeholder?
11. What is your experience working in Agile or Scrum? How did you contribute during sprint planning?
12. A client changes a core requirement mid-project. How do you respond?

Q: Describe a time you spotted a gap in a business process and recommended a fix.

*Situation:* At my previous company, the purchase order approval process relied entirely on email chains, which caused frequent delays and made it hard to track who had approved what.

*Task:* I was asked to analyse the process and suggest a solution that reduced approval time without requiring a full system overhaul.

*Action:* I interviewed several stakeholders across finance and procurement, mapped the current workflow in Visio, and identified multiple handoff points where requests were regularly getting stuck. I proposed a lightweight approval workflow using tools the company already had, wrote the requirements, and worked with the dev team to implement it across two sprints.

*Result:* Average approval time dropped noticeably, and the finance team reported fewer errors. The project was completed within the agreed timeline and budget.

---

Q: How do you handle a situation where stakeholders and the development team disagree on a requirement?

*Situation:* During a CRM migration project, the sales team wanted a custom dashboard that the dev team said would significantly increase the development effort.

*Task:* My role was to find a solution both sides could accept without delaying the release.

*Action:* I arranged a joint workshop, presented data showing which dashboard features the sales team actually used most, and helped both sides agree on a phased approach: core features in the first release and advanced filters in a follow-up sprint.

*Result:* The release shipped on schedule, stakeholders got their priority features, and the dev team avoided rework. The follow-up sprint was planned into the next quarter without friction.

---

Q: How do you manage scope creep in a project?

*Situation:* Midway through a retail analytics project, the product owner began adding reporting requirements that were not in the original scope document.

*Task:* I needed to protect the delivery timeline while keeping the product owner engaged and satisfied.

*Action:* I referred to the signed-off scope document and set up a change request process: every new requirement had to go through an impact assessment covering effort, cost, and timeline. I kept a change log visible to all stakeholders and escalated decisions above a certain effort threshold to the project sponsor.

*Result:* Several of the new requests were deferred to the next release. The project delivered on time, and the product owner appreciated the transparency of the change log.

STAR (Situation, Task, Action, Result) is the format interviewers at most IT services firms expect for behavioural questions. Keep each story to about 2 minutes: spend a short time on situation and task, most of your time on the action you took, and close with a clear result. Always try to quantify the result, even loosely ('reduced approval time', 'delivered on schedule').

For process or domain questions, use a structured walk-through: state your starting point, name the tools or methods you used, and end with what the output looked like. If asked about requirement gathering, describe who you interviewed, what artefacts you produced (BRD, user stories, process maps), and how you validated them with stakeholders.

For SQL or technical questions, do not try to bluff. Say clearly what you know: 'I write basic to intermediate queries covering JOINs, GROUP BY, and subqueries. I use SQL mainly to validate data and answer ad hoc business questions.' That honesty lands better than overclaiming.

For prioritisation questions, reference a framework you have actually used: MoSCoW (Must, Should, Could, Won't), RICE scoring, or stakeholder-weighted ranking. Name it, explain it briefly, and tie it to a real example from your experience.

Burgeon IT Services places BAs with clients, so interviewers are assessing whether you can represent their firm professionally in client-facing situations. Based on what candidates report, the three things they look for most are:

Clear communication. Can you explain a complex requirement in plain language? Interviewers often ask you to explain something technical to a 'non-technical manager' as part of the interview itself.

Structured thinking. Do you approach problems with a clear method, or do you jump straight to solutions? They want to see that you gather data before recommending anything.

Delivery focus. BA roles at IT services firms are accountable to client timelines. Interviewers want evidence that you can manage competing demands, flag risks early, and keep projects moving even when requirements shift.

Domain knowledge in BFSI, retail, or technology is a plus but not always required. A strong grasp of Agile processes and documentation tools like Confluence and JIRA will carry you further than domain jargon alone.

Week 1: Foundations

Revise your core BA artefacts: Business Requirements Document (BRD), Functional Requirements Document (FRD), user stories with acceptance criteria, and process flow diagrams. If you have samples from past roles, read through them and be ready to walk an interviewer through one confidently.

Practise STAR stories covering at least three scenarios: a difficult stakeholder situation, a time you caught a requirement gap, and a delivery challenge you helped resolve. Aim for stories that are specific and end with a measurable or visible result.

Week 2: Tools and technical prep

Brush up on SQL basics: SELECT, WHERE, JOIN (INNER and LEFT), GROUP BY, HAVING, and subqueries. Practise on a free platform like HackerRank or Mode Analytics. Review JIRA and Confluence workflows if you have used them; if not, a short tutorial will help you speak to the interface without hesitation.

If the role mentions a specific domain (BFSI, for example), read one or two recent industry articles so you can speak to current trends without overclaiming expertise.

Before the interview

Look up Burgeon IT Services on LinkedIn to understand the clients they typically serve and the industries they focus on. Prepare a few questions to ask the interviewer: about the client project you would be joining, the team structure, and how success is measured in the BA role. Candidates report that asking thoughtful questions makes a strong impression in the final round.

Being vague about deliverables. Saying 'I gathered requirements' is not enough. Name the artefacts you produced, who reviewed them, and how they were used downstream. Specificity signals real experience.

Overclaiming SQL skills. If you only know basic queries, say so. Interviewers often follow up with a quick question or a short test. Overclaiming leads to an awkward moment that is hard to recover from.

Ignoring the stakeholder angle. Many candidates focus entirely on tools and process but forget that BA work is mostly about communication. If your answers do not mention how you worked with stakeholders, you are leaving out the most important part of the job.

No questions for the interviewer. Arriving with no questions signals low interest. Prepare at least a couple: one about the project or client, one about how the team works day to day.

Treating every round as a technical test. The final round with a senior manager or client is usually about cultural fit, communication style, and career intent. Relax, be direct, and show genuine interest in the role rather than reciting frameworks.

Not tailoring your examples to IT services. If your background is from an in-house or product company, reframe your stories to show you understand the client-vendor dynamic: client deadlines matter, scope changes go through a formal process, and stakeholder satisfaction is measured explicitly.

If keeping track of open BA roles across companies feels like too much to manage alongside interview prep, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you.