Swiggy Business Analyst Interview: Questions, Experience & Prep (2026)

Swiggy is one of India's most recognised food-delivery and quick-commerce platforms, and its Business Analyst roles sit at the centre of decisions around growth, operations, and product. As of July 2026, Swiggy had 26 open Business Analyst positions across India, reflecting active and ongoing hiring in this function.

Candidates report a process that typically spans three to four rounds: an online aptitude or SQL assessment, a data analysis or case study round, and one or two rounds with hiring managers or cross-functional stakeholders. The focus is heavily on structured thinking, SQL fluency, and the ability to draw a clear story from data. Familiarity with how food-delivery and quick-commerce platforms work gives you a genuine edge, since many case questions are grounded in Swiggy's own business: delivery operations, Instamart, Swiggy One, and city-level expansion.

These questions are drawn from candidate-reported experiences and reflect themes that appear consistently in Swiggy BA interviews. Exact questions vary by team and level, but the patterns below are reliable.

1. Walk us through a time you used data to change a business decision at your previous job.
2. Swiggy's average delivery time increased sharply last week. How would you diagnose the root cause?
3. How would you measure the success of Swiggy Instamart after a new city launch? What is your north star metric?
4. Write a SQL query to find the top five restaurants by order volume in Bangalore over the past month.
5. A product manager wants to test free delivery for Swiggy One members. How would you design the experiment?
6. What metrics would you track to understand customer retention on the Swiggy app?
7. How would you build a weekly operations dashboard for Swiggy's delivery partner team? What would you include and why?
8. Swiggy is seeing high cart abandonment on weekday afternoons. What could be causing this, and how would you investigate?
9. Describe a situation where you presented a complex analysis to a non-technical stakeholder and had to adjust your communication style.
10. If you had to prioritise between improving delivery speed and reducing order cancellations, how would you decide?
11. How would you estimate the total number of food orders placed in Mumbai on a typical Friday night?
12. Swiggy wants to expand Instamart to new cities. What data would you use to shortlist and rank those cities?

These three answers follow the STAR format (Situation, Task, Action, Result). Adapt them to your own real experience.

Q: Walk us through a time you used data to change a business decision.

*Situation:* At my previous company, the marketing team planned to shift a large portion of ad spend to weekends, assuming that was when customers were most active.

*Task:* I was asked to validate this assumption before the budget was committed for the quarter.

*Action:* I pulled two months of transaction data, segmented users by acquisition channel and day of week, and built a comparison using Excel and SQL. I found that weekday evening campaigns had a higher conversion rate for our core user segment. I created a one-page summary with charts and presented the finding to the team in a focused session.

*Result:* The team reallocated a portion of the weekend budget to weekday evenings. Campaign performance improved in the following quarter, and this data-first check became the team's standard before any major budget decision.

---

Q: Describe a time you presented a complex analysis to a non-technical audience.

*Situation:* I had completed a churn analysis involving cohort breakdowns and retention curves, and I needed to present the findings to the sales leadership team, who had no data background.

*Task:* I needed them to understand the findings clearly enough to approve a retention initiative in that same meeting.

*Action:* I stripped out all technical language and built a single summary slide with three charts. I translated metrics into plain business language: instead of 'cohort retention rate,' I said 'how many customers are still ordering after their third month.' I used a simple analogy to explain the trend and focused on revenue impact rather than methodology.

*Result:* Leadership approved the retention initiative on the spot. It was the first time the data team had directly influenced a sales planning decision in that organisation.

---

Q: Tell me about a time you worked with incomplete or messy data.

*Situation:* I was building a delivery partner productivity report, but the raw dataset had significant gaps in GPS logs and shift timing records.

*Task:* I needed to deliver a reliable productivity metric to operations leadership despite the data quality issues.

*Action:* I documented all identified gaps, made conservative assumptions where data was missing, and flagged outliers in a separate section rather than folding them into the main figures. I also raised a short note to the engineering team describing the gaps and asked for a data quality alert to be set up.

*Result:* The report was delivered on time with clear caveats documented. The engineering team found and fixed a pipeline bug that had been causing the gaps, and the alert I requested caught two similar issues in the months that followed.

For behavioural questions: Use STAR (Situation, Task, Action, Result) consistently. Keep Situation and Task brief, spend most of your answer on Action (what you specifically did, not what 'we' did as a team), and always close with a concrete Result. Vague endings like 'the team was happy' are weak. Quantify the outcome wherever you can.

For metric and diagnostic questions: A structured approach works better than jumping straight to an answer. First, clarify the scope: is this a data pipeline issue or a real business change? Then break the funnel or user journey into stages and check each one. Finally, look for correlations with external factors such as app version releases, competitor promotions, city-level events, or seasonal patterns. Swiggy interviewers value candidates who think out loud and state their assumptions before committing to a conclusion.

For estimation (guesstimate) questions: State your assumptions before you calculate anything. Break the problem into components you can reason about (population size, ordering frequency, average basket size). Sense-check your final answer by asking whether it sounds plausible in the real world. If not, revisit your assumptions and say so out loud.

For SQL questions: Candidates report questions involving GROUP BY, window functions (RANK, ROW_NUMBER, LAG), and subqueries. Write clean SQL, use aliases to keep it readable, and explain what each part of your query does as you write it. Talking through your logic as you go shows structured thinking even if you make a small syntax error.

Swiggy BA roles span product analytics, growth, and operations, so interviewers typically look for a combination of technical fluency and business communication.

Structured thinking. When given an open-ended problem, strong candidates ask clarifying questions before diving in. They define what success looks like, name the metrics that matter, and walk through their reasoning step by step. Jumping to an answer without framing the problem is one of the most common signals that a candidate will struggle in the role.

SQL confidence. You will likely be asked to write a query on the spot or walk through your SQL approach in detail. If SQL is on your resume, expect to be tested on it. Struggling with window functions or joins under time pressure is one of the most commonly cited reasons candidates do not move forward in Swiggy BA processes.

Product curiosity. Candidates who use Swiggy regularly, understand how Instamart differs from the core food-delivery business, and can speak to real user pain points consistently stand out. Saying 'I noticed that X in the app and thought it was an interesting trade-off because...' signals genuine engagement with the product.

Clear communication. The BA role involves presenting findings to non-technical stakeholders regularly. Interviewers listen for candidates who can simplify without losing accuracy, and who do not default to jargon when a plain sentence would work better.

Two to three weeks out: Get familiar with the full Swiggy product: the main app, Swiggy One, Instamart, and Swiggy Genie. Understand how each works from both a user and a business perspective. Read any publicly available articles or interviews about how Swiggy approaches data and operations decisions. This context will make your case answers far more specific and credible.

One to two weeks out: Focus on SQL. Practice window functions, GROUP BY aggregations, and multi-table joins on datasets that resemble food-delivery data (orders, restaurants, delivery partners, timestamps). StrataScratch and LeetCode both have relevant question sets. Separately, revise A/B testing basics: how to frame a hypothesis, how to think about sample size, and how to interpret test results in a business context.

One week out: Practice two or three STAR answers for the most common behavioural themes: using data to influence a decision, working with a difficult or non-technical stakeholder, and handling ambiguous or incomplete data. Record yourself or practice with a friend. Concise, structured answers consistently outperform long, unfocused ones in Swiggy interviews, candidates report.

Day before: Re-read the job description and map your strongest experiences to the specific requirements listed. Prepare two or three thoughtful questions to ask your interviewer about the team, the data stack, or the business problem they are currently focused on.

If keeping track of new Swiggy BA listings feels like one more thing to manage during prep, knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR for you, so you do not miss a new opening while you are busy practising SQL.

Jumping to answers without clarifying. For open-ended questions like 'how would you measure success,' candidates who immediately list metrics without asking about the goal or user segment often miss what the interviewer is actually testing. Pause, ask one or two focused clarifying questions, then answer.

Being too generic. Saying 'I would look at relevant metrics' without naming specific ones signals that you cannot connect a business question to a concrete analysis. Swiggy interviewers expect you to name the metric, explain why it matters, and say how you would measure it with the data available.

Weak SQL under pressure. Many candidates claim SQL fluency on their resume but struggle with window functions or complex joins when asked to write live. If SQL is listed as a core requirement, expect to be tested on it seriously and practice writing queries by hand before the interview.

Missing the operations context. Swiggy is not just a product company. A large part of the BA role touches delivery partner operations, city-level expansion, and supply-demand balancing. Candidates who only think in product terms miss half the picture. Ground your answers in both product and operations wherever the question allows.

Not asking questions. Treating the interview as entirely one-way reduces your chances. A sharp, specific question about the team's current data challenges or how success is measured in the role signals that you have thought carefully about the position, not just practised answers.