Swiggy SDE (Backend Engineer) Interview Experience | Java, System Design, Automation Frameworks & SQL

Ajeet Pawar

Last Updated : 30 August 2026

55 Views

#java

#interview

#swiggy-company

#dsa

#interview-experience

#interview-preparation

#technical-interview

#system-design-interview

#interview-questions

Adℹ

Field	Details
Company	Swiggy
Role	Software Development Engineer (Backend Engineer)
Interview Mode	Remote
Interview Rounds	5
Difficulty Level	Hard
Result	Selected
Interview Timeline	2–3 Weeks

Interview Process

The recruitment process consisted of five technical and behavioral rounds. Although the role was for a Backend Engineer, the interview focused heavily on Java fundamentals, automation engineering, system design, SQL optimization and designing scalable testing frameworks.

Unlike interviews that emphasize coding problems, this process was largely discussion-based. The interviewers were interested in understanding how I approached real engineering challenges, designed maintainable systems and made architectural decisions. Every round involved practical scenarios inspired by problems commonly encountered in production environments.

Round 1 – Java, SQL & Automation Fundamentals

Duration: 90 Minutes

The first round evaluated my programming fundamentals, SQL knowledge and practical automation experience.

The interviewer began by discussing Java concepts and gradually moved toward automation-related questions. Instead of asking theoretical definitions, most questions were scenario-based and focused on how I would solve real-world testing problems.

One of the discussions revolved around handling dynamic web elements in Selenium. I explained how relying solely on implicit waits often leads to flaky tests and described how I implemented a custom explicit wait mechanism that repeatedly checks whether an element satisfies a specific condition before interacting with it. We discussed different waiting strategies, timeout handling, polling intervals and situations where explicit waits are more appropriate than fixed delays.

The interviewer then shifted the conversation to SQL optimization. I was given a complex query involving multiple joins and filtering conditions and asked how I would improve its performance. I explained how I analyze execution plans, identify unnecessary joins, create appropriate indexes, reduce redundant scans and rewrite queries to minimize execution time. The discussion focused more on the optimization process than on writing a single query.

The final task involved generating test data programmatically. I described how I would build a reusable utility capable of producing different combinations of valid and invalid datasets while ensuring consistency across multiple test scenarios. The interviewer appreciated the emphasis on maintainability and extensibility instead of writing a one-off script.

Overall, the first round focused on practical engineering skills rather than algorithmic coding.

Round 2 – Java & Automation Frameworks

Duration: 90 Minutes**

The second round explored my understanding of Selenium, TestNG and automation framework development.

The interviewer started with questions about handling web elements that appear after unpredictable delays. I explained how I use Selenium's WebDriverWait together with expected conditions to synchronize test execution with the application's state instead of relying on hard-coded delays.

The discussion then moved to failure handling within automation frameworks. I described how I implemented a custom TestNG listener that automatically captures screenshots whenever a test case fails. Along with screenshots, I also log the exception details and attach them to the test report, making debugging much easier for developers and QA engineers.

Another topic involved designing a data-driven testing framework. I explained how TestNG's @DataProvider enables the same test to run against multiple datasets and how JSON files can be used to maintain external test data separately from the test logic. This approach improves maintainability and makes it easier to add new test scenarios without modifying the test implementation.

Throughout the interview, the conversation remained highly interactive. Instead of checking whether I knew specific APIs, the interviewer wanted to understand why I chose certain approaches and how those decisions improved reliability and maintainability.

Round 3 – Cross-Platform Automation Framework Design

Duration: 60 Minutes

The third round was the most challenging and focused entirely on system design.

The interviewer asked me to design a scalable automation framework capable of supporting both Android and iOS applications while allowing parallel execution across multiple devices.

I began by proposing Appium as the automation engine because it supports both platforms using a unified programming model. To keep the framework modular and maintainable, I suggested implementing the Page Object Model (POM), allowing UI locators and business logic to remain separated from the test cases.

For execution, I recommended TestNG's parallel execution capabilities so that multiple devices could execute tests simultaneously. We also discussed device management, thread safety and maintaining independent driver instances during concurrent execution.

To improve reporting, I integrated Extent Reports for detailed execution summaries and Jenkins for continuous integration. I also discussed logging, exception handling, retry mechanisms and framework extensibility so that new platforms and features could be added with minimal effort.

The interviewer asked several follow-up questions about scalability, maintainability and handling failures in distributed test execution. The discussion remained architecture-focused throughout the round.

Round 4 – Microservices Testing Framework Design

Duration: 60 Minutes

The fourth round focused on designing an automation strategy for a microservices-based architecture.

The interviewer wanted to understand how I would test services that depend on multiple downstream systems while maintaining fast and reliable feedback during development.

I began by explaining the Test Pyramid and why a balanced combination of unit tests, integration tests and end-to-end tests provides the best trade-off between execution speed and confidence.

For scenarios where dependent services were unavailable or expensive to maintain, I suggested using service virtualization to simulate external dependencies. We then discussed contract testing using Pact to ensure that service providers and consumers remain compatible even as APIs evolve independently.

The conversation concluded with performance testing. I explained how JMeter could be used to generate realistic workloads and how monitoring solutions such as the ELK Stack could help identify bottlenecks by collecting logs, metrics and application traces.

Rather than expecting a single correct architecture, the interviewer evaluated how I reasoned about trade-offs, reliability and scalability.

Round 5 – Hiring Manager Discussion

Duration: 45 Minutes

The final round was conversational and focused on understanding my work style and career aspirations.

We discussed my experience working with distributed teams, collaborating remotely, handling challenging situations and adapting to changing priorities. The interviewer also asked about my long-term goals, why I wanted to join Swiggy and how I saw myself contributing to the engineering team.

The discussion was relaxed and provided an opportunity to talk about my previous projects, learning experiences and professional growth.

Interview Questions

Java & Backend

Core Java concepts
Exception handling
Writing reusable utilities
Multithreading basics

SQL

Query optimization
Joins
Indexing
Execution plans

Automation

Selenium waits
WebDriverWait
Custom wait implementation
TestNG Listeners
Data-driven testing
JSON test data management

System Design

Cross-platform automation framework
Android & iOS automation
Parallel execution
CI/CD integration
Reporting framework

Microservices

Test Pyramid
Service Virtualization
Contract Testing
Pact
JMeter
ELK Stack

Behavioral

Team collaboration
Remote work experience
Career goals
Why Swiggy?

Overall Experience

Overall, this was one of the most practical engineering interviews I have participated in. Instead of concentrating on algorithmic coding questions, the interview process emphasized solving real-world engineering problems, designing scalable automation frameworks, optimizing backend systems and making sound architectural decisions.

Each round became progressively more design-oriented. The interviewers consistently encouraged discussion, asked follow-up questions and evaluated how I approached problems rather than looking for memorized answers. Having practical experience with automation frameworks, Java, SQL and distributed systems proved to be more valuable than simply knowing theoretical concepts.

I found the interview process engaging and it offered a good opportunity to discuss real engineering challenges encountered in production environments. Successfully clearing all five rounds was a rewarding experience.

Preparation Tips

If you are preparing for a similar role at Swiggy, focus on strengthening your Java fundamentals and becoming comfortable with automation frameworks such as Selenium, Appium and TestNG. Practical knowledge of SQL optimization, indexing and query tuning is equally important because backend engineers frequently work with performance-critical database operations.

In addition to implementation skills, spend time learning system design concepts related to automation infrastructure, CI/CD pipelines, reporting, distributed execution and microservices testing. Interviewers are particularly interested in understanding your reasoning, trade-off analysis and ability to design scalable, maintainable systems.

Advice for Future Candidates

Approach every design question as if you were building a production-ready system. Clearly explain your assumptions, justify each architectural decision and discuss possible alternatives along with their trade-offs. Breaking large problems into smaller components and reasoning through each step leaves a much stronger impression than trying to arrive at a perfect solution immediately.