Swiggy Data Scientist Interview Experience

When I interviewed for the Data Scientist role at Swiggy, I expected the interview to revolve around machine learning algorithms, deep learning concepts, and statistics. While those topics did appear, what surprised me was the interviewers’ focus on understanding my projects, my reasoning behind technical decisions, and how I approached real-world business problems.

In this article, I’ll share my interview experience, the types of questions I was asked, and the key lessons that I believe will help anyone preparing for similar roles.

I submitted my application for the Data Scientist position through Swiggy’s careers portal in March 2026. Just two days later, HR reached out to let me know that my resume had been shortlisted, and the interview process began.

Swiggy Interview Experience

Round 1: Coding Round

The first round began with coding.

I was asked to solve two coding problems on an online compiler:

• One based on Strings
• One based on Binary Trees

Fortunately, I was able to solve both problems successfully and execute them without any issues. Once the coding section was complete, the interview shifted toward concepts related to large-scale data processing.

Some of the topics discussed included:

• Lazy Execution
• Rate Limiting Errors
• PySpark Transformations vs Actions

I received a call from HR within 30 minutes confirming that I had cleared the first round.

Round 2: Machine Learning Round

I spent the week before this round revising Machine Learning algorithms, Deep Learning and nuances of these topics. I expected a theory-heavy discussion. But the interviewer asked me about the project which I have done in the company. For almost the next hour, the interview revolved around that single project.

The discussion began with the complete RAG pipeline.

Some of the questions included:

• Explain your RAG project end-to-end.
• What are the different chunking strategies?
• How do you decide chunk overlap?
• What is semantic chunking?
• Which chunking strategy would you choose for different scenarios?

These weren’t definition-based questions. The interviewer was trying to understand whether I had actually designed and implemented the system myself.

The conversation then shifted to embeddings. Some of the questions included:

• Which embedding model did you use?
• Why did you choose ADA embeddings?
• Did you evaluate other embedding models?
• How are embeddings generated?
• How would you compare two embedding models?

What stood out was that every answer was followed by another “Why?” Knowing what you used wasn’t enough. You also had to justify why it was the right choice.

Next, the interviewer focused on evaluation. Questions covered:

• BLEU Score
• ROUGE Score
• Precision vs Recall
• Comparing generated answers against ground truth

Instead of asking for textbook definitions, the interviewer expected practical explanations with examples.

The discussion gradually moved toward LLM fundamentals.

Some of the questions included:

• Explain the Transformer architecture.
• Are embeddings generated for words or tokens?
• Why do we need tokenization?
• Which tokenizer did you use?
• What are BPE and WordPiece tokenization?
• How do BPE and WordPiece differ?

This section was particularly interesting because the interviewer didn’t stop after asking whether I knew a concept. They kept drilling deeper until they understood the depth of my knowledge.

What I learned

I realized that interviewers are often less interested in whether you’ve used a particular model or library and more interested in whether you understand the reasoning behind your choices. Preparing only interview questions isn’t enough. Preparing your own projects thoroughly is far more important. Later, I received confirmation that I had cleared this round as well.

Round 3: Problem Solving Round

In this round, the interviewer presented a business scenario and asked me to think through it like a Data Scientist.

The problem statement was simple:

Suppose a user adds an item to the cart on Swiggy. How would you build a meal recommendation system that suggests what the user is likely to order next?

From that single question, the conversation expanded into the discussion covering recommendation systems, SQL, machine learning, experimentation, and product thinking.

Designing the Recommendation Pipeline

I broke the solution into three broad stages:

1. Candidate Generation
2. Ranking
3. Real-time Serving

From there, the interviewer began exploring each stage in detail.

Some of the follow-up questions included:

• How would you generate candidate meals?
• How would you implement association rules using SQL?
• Explain exactly what your SQL query is doing.
• Why do association rules work?

One interesting moment was when the interviewer connected association rules in recommendation systems with the mathematical concept of the associative law. It wasn’t about proving mathematics — it was a way of checking whether I could clearly distinguish between similarly named concepts.

Once candidate generation was discussed, the interviewer shifted to ranking. Some of the questions included:

• Why did you choose Logistic Regression?
• What labels would you use during training?
• How would you generate negative samples?
• Why is a ranking model necessary?

These questions focused on understanding the reasoning behind model selection rather than recalling algorithms.

The final discussion centered around deployment and evaluation. Some questions included:

• Once the model is deployed, how would you know whether it is performing well?
• Which offline metrics would you monitor?
• How would you conduct an A/B test?
• What business metrics would improve if the recommendation system works?

This was perhaps my favorite part of the interview because it reflected how machine learning systems are evaluated in production rather than in notebooks.

What I learned

This round taught me that product companies expect Data Scientists to think beyond model accuracy. A good solution isn’t just one with a strong algorithm — it should also be measurable, deployable, and capable of improving user experience and business metrics.

Although I wasn’t able to clear this round, it gave me valuable insights into the kind of thinking required for real-world machine learning problems.

Final Thoughts

Although I couldn’t clear the last round, I genuinely enjoyed the interview process.

Each interviewer focused less on memorized answers and more on understanding how I approached problems, justified technical decisions, and communicated my thinking.

I hope sharing my experience helps someone prepare a little better for their own interview journey. If you found this article useful, consider giving it a clap👏. If you’ve also gone through a similar process or have additional preparation tips, I’d love to hear about them in the comments.