Swiggy SDE-2 Backend Bangalore 2025: ₹40 LPA Role, Rejected at Train Booking LLD

TL;DR. Backend developer, 2+ years experience in Java/Spring and Node.js, Bangalore-based. Applied for Swiggy SDE-2 Backend, a ₹40 LPA role. Cleared the online assessment (solved all problems). Cleared Round 1: DSA plus LLD, where the DSA was "find smallest element in rotated sorted array" and the LLD was a Parking Lot System. Got rejected in Round 2: LLD plus HLD, where the problem was a Train Ticket Booking System with concurrency control, seat allocation, and waitlist logic. The candidate's own assessment: "Even if you do well but struggle briefly in a part of the problem, they will likely reject you." Source linked at the bottom.

This is not a "Swiggy interview preparation guide." Those exist, and they list the same 15 design patterns. This is one specific December 2025 candidate's specific 2-round loop at Swiggy, with the exact problems they were asked, the exact entities they had to design, and the exact point where the process ended.

The verified candidate

The candidate, identified as Kumar K, was a Bangalore-based backend engineer with production experience in two of the three most common Indian backend stacks (Java/Spring and Node). Two years of backend experience is the minimum threshold for SDE-2 at Swiggy; most selected candidates have 3 to 4 years. The candidate was at the lower end of the experience band for the role, which becomes relevant when evaluating the rejection.

How Swiggy SDE-2 Backend interviews work in 2025

Swiggy's backend SDE-2 interview pipeline in late 2025 follows this structure:

The critical observation: Swiggy combines DSA with LLD in a single round, and LLD with HLD in the next round. There is no standalone DSA round and no standalone design round. Every round is a hybrid. This means you cannot rely on "I am strong at DSA, I will make up for weak design in the next round." Each round is pass/fail on both dimensions simultaneously.

At ₹40 LPA, the SDE-2 Backend role is one of the higher-paying lateral positions in the Indian startup ecosystem for engineers with 2 to 4 years of experience. The competition is accordingly intense. Swiggy can afford to reject candidates who perform well in most areas but show a gap in one specific area. And they do.

Online Assessment: solved all problems

The candidate reported solving all questions in the online assessment. The problems were described as medium to hard DSA-focused. Specific problem statements were not recalled in the source, but the candidate cleared the OA stage without difficulty.

This is the baseline. Swiggy's OA pass rate for SDE-2 candidates is reportedly around 30 to 40%. If you are struggling with medium-level DSA problems on LeetCode, the OA itself becomes the filter. Clearing it is necessary but tells you nothing about your chances in the interview rounds.

Round 1: DSA + LLD (60 minutes)

DSA: Find smallest element in rotated sorted array

The classic binary search variant. A sorted array [1, 2, 3, 4, 5] rotated to [3, 4, 5, 1, 2]. The minimum is at the rotation point. The O(n) linear scan is trivial; the O(log n) binary search variant is the signal.

The approach: compare mid with right. If nums[mid] > nums[right], the minimum is in the right half. If nums[mid] <= nums[right], the minimum is in the left half (including mid). Shrink the search space accordingly. Key edge case: duplicates (LeetCode 154), which degrades worst case to O(n).

The candidate cleared this problem. At SDE-2 level, this is expected to take 10 to 15 minutes including edge case discussion. If it takes longer, the LLD portion of the round gets time-starved.

LLD: Parking Lot System

The Parking Lot is one of the 5 most commonly asked LLD problems across all Indian tech companies (alongside Splitwise, BookMyShow, Snake and Ladder, and Elevator System). If you have not practiced it to the point where you can produce a clean class hierarchy in 15 minutes, you are not prepared for LLD interviews at the SDE-2 level.

The expected entities: Vehicle (base class with subclasses Car, Bike, Truck), ParkingSlot (with size, floor, availability), Ticket (entry time, vehicle, slot assignment), Payment (amount, method, timestamp). The allocation strategy is where candidates differentiate: nearest-to-entrance, floor-based, vehicle-size-matched.

The candidate cleared this round. Both the DSA and LLD portions were handled well enough to advance.

Round 2: LLD + HLD (60 minutes), the rejection round

The problem: Train Ticket Booking System

This is where the interview ended. The Train Ticket Booking System is a step up in complexity from the Parking Lot because it introduces three hard problems simultaneously: seat allocation with real-time availability, concurrency control under high contention, and waitlist management with automated promotion.

Seat allocation. Unlike a parking lot where a vehicle occupies one slot, train booking involves selecting specific seats within specific coaches within specific trains on specific dates. The search space is large, and the allocation must respect constraints: window/aisle preference, same-coach grouping for families, RAC (Reservation Against Cancellation) limits per coach.

Concurrency control. This is the killer. When 10,000 users simultaneously try to book the same train on Tatkal opening day, how do you prevent double-booking? The expected answer involves either pessimistic locking (database-level row locks on seat records) or optimistic locking (version numbers with retry on conflict). Each has tradeoffs. Pessimistic locking prevents conflicts but creates lock contention bottlenecks. Optimistic locking scales better but requires a retry mechanism and can frustrate users when their booking fails after filling the form.

The Swiggy-specific twist: the interviewer expected the candidate to discuss both approaches, justify one, and then explain how to handle the failure mode of the chosen approach. A one-line "use database locks" is not sufficient.

Waitlist logic. When a confirmed seat is cancelled, how does the waitlist promote the next candidate? The IRCTC model uses a priority queue ordered by booking time within the same coach class. The candidate must design the data structure (priority queue or sorted list), the promotion trigger (cancellation event), and the notification mechanism (async vs. sync).

The candidate struggled with the concurrency control portion. In their own words: "Even if you do well but struggle briefly in a part of the problem, they will likely reject you."

Why this problem is harder than it looks

The Parking Lot System has fixed entities (vehicle parks, vehicle leaves), no concurrent writes (one car enters at a time), and no waitlist. The Train Ticket Booking System has all three: dynamic entity relationships, high-concurrency writes, and a waitlist state machine. The jump from Round 1 LLD to Round 2 LLD is not incremental. It is a tier change.

Most candidates prepare 5 to 8 standard LLD problems (Parking Lot, BookMyShow, Splitwise, Elevator, Snake and Ladder, Tic Tac Toe, Library Management, URL Shortener) and assume they are covered. The Train Ticket Booking System is not in most standard LLD prep lists. It appears more frequently at Indian companies (Swiggy, Flipkart, PhonePe, Paytm) because it maps directly to Indian-context systems that the interviewer understands intimately.

The HLD component

The Round 2 HLD asked the candidate to extend the Train Ticket Booking System to high-level architecture: how would you design the system to handle 10 million concurrent searches, 500,000 concurrent bookings, and sub-second response times?

Expected components:

• Search Service: read-heavy, can be served from a read replica or cache (Redis/ElastiCache). Pre-computed availability index, updated on every booking event.
• Booking Service: write-heavy, requires strong consistency. Database with row-level locking or distributed lock manager (Redlock).
• Payment Service: async, idempotent. Two-phase: reserve seat first (holding period), then confirm on payment success.
• Waitlist Service: event-driven. Listens to cancellation events, promotes next candidate, sends notification.
• Notification Service: async (SQS/Kafka). SMS, email, push notification on booking confirmation, waitlist promotion, or cancellation.

The candidate did not reach the full HLD discussion in sufficient depth, having spent too much time on the LLD concurrency portion.

Real questions asked in this loop

1. Find smallest element in rotated sorted array: modified binary search, O(log n), handle duplicates.
2. Parking Lot System LLD: Vehicle/Slot/Ticket/Payment entities, allocation strategy, class diagram.
3. Train Ticket Booking System LLD: Train/Coach/Seat/Booking/User/SearchService entities, seat allocation, concurrency control (pessimistic vs. optimistic locking), waitlist with priority-based promotion.
4. Train Ticket Booking System HLD: search service scaling, booking service consistency, payment idempotency, waitlist event-driven promotion.

The candidate's own verdict

Direct quote from the source: "Even if you do well but struggle briefly in a part of the problem, they will likely reject you." And: companies expect candidates to "mug up all LLD/HLD patterns and solve instantly."

This is a real observation, not bitterness. At the SDE-2 level with ₹40 LPA at stake, Swiggy has the applicant volume to reject candidates who demonstrate gaps in any single area. The interview is not curved. A strong DSA performance does not compensate for a weak concurrency discussion. A clean Parking Lot design does not carry forward to the next round. Each round is independently evaluated, and each round contains multiple assessment dimensions.

What the rejection says about Swiggy's bar

1. Practice LLD problems beyond the standard 8. Parking Lot, BookMyShow, and Splitwise are necessary but not sufficient. Add Indian-context problems: Train Ticket Booking (IRCTC), UPI Payment System (PhonePe/GPay), Food Delivery Order Management (Swiggy/Zomato). These appear at Indian companies more frequently than the standard Western LLD list.
2. Concurrency is the SDE-2 separator. At SDE-1, interviewers accept "use a lock." At SDE-2, they expect you to compare pessimistic vs. optimistic locking, discuss contention under load, and handle the failure mode of your chosen approach. Practice explaining concurrency control for 3 systems: booking, inventory management, and rate limiting.
3. Time management in hybrid rounds is critical. When DSA and LLD share a 60-minute round, the DSA problem must be solved in 15 minutes to leave 45 minutes for design. If DSA takes 25 minutes, the LLD discussion is rushed, and the interviewer scores "insufficient depth on design."
4. Startups at ₹40 LPA are not forgiving. The compensation tier means the applicant pool is deep. One moment of hesitation on concurrency control, one incomplete waitlist design, one missing entity in the class diagram, and the process ends. Over-prepare design, not DSA. DSA is a pass/fail filter at SDE-2. Design is the discriminator.
5. The candidate was right about one thing. "Mug up all LLD/HLD patterns and solve instantly" is harsh but accurate. At scale, interviewers cannot spend 10 minutes waiting for you to derive the entity relationships. They expect recognition: "this is a booking system, here are the entities, here is the concurrency model, here is the waitlist." If you need to derive it from first principles during the interview, you are 15 minutes behind someone who recognized the pattern.

Where this comes from

This analysis is based on a published interview experience on DesiQnA, attributed to Kumar K, describing a Swiggy SDE-2 Backend interview in Bangalore, December 2025. The source includes: role (SDE-2 Backend), target CTC (₹40 LPA), experience level (2+ years Java/Spring, Node), specific problems asked in each round (rotated sorted array, Parking Lot System, Train Ticket Booking System), entities discussed, and the explicit rejection outcome.

Original post: Swiggy SDE-2 Backend Interview Experience, Kumar K, December 2025

PapersAdda verification standard: publicly accessible URL, per-round detail, named problems, and explicit outcome. This source meets all four criteria.

Questions about Swiggy SDE-2 Backend hiring

What is Swiggy SDE-2 Backend CTC in Bangalore? The role in this specific interview was listed at ₹40 LPA. Swiggy SDE-2 Backend compensation in Bangalore in late 2025 ranges from ₹35 to ₹50 LPA depending on experience, stock allocation, and negotiation. Base salary is typically ₹25 to ₹30 LPA with the rest in ESOPs and joining bonus.

How many rounds does Swiggy SDE-2 have? Three rounds after the online assessment: DSA+LLD (60 min), LLD+HLD (60 min), Hiring Manager (45-60 min). The candidate in this experience was rejected after Round 2 and did not reach the Hiring Manager round.

Is 2 years enough for Swiggy SDE-2? It is the minimum. Most candidates selected for SDE-2 at Swiggy have 3 to 4 years of backend experience. At 2 years, you are at the lower bound and the expectation for design depth is not reduced to match your experience level.

What languages does Swiggy accept for coding rounds? Java, Python, C++, and Go are the most common. The candidate used Java/Spring Boot for the LLD portions. Swiggy's backend is primarily Java and Kotlin, so Java expertise is a minor advantage in LLD discussions where framework-specific patterns (Spring dependency injection, repository pattern) are relevant.

Related verified interviews

• The machine coding counterpart: Flipkart SDE-2 Bangalore 2024: Wallet Machine Coding to Offer, a different format where machine coding precedes design
• Another startup rejection story: Zepto SDE-1 Bangalore 2025: Air Traffic Controller LLD to HM Rejection, how clearing technicals still leads to rejection at the HM stage
• The Uber machine coding format: Uber SDE-2 L4 India 2025: Job Scheduler Machine Coding in a 6-Round Offer, similar LLD depth at a different company
• FAANG baseline comparison: Amazon SDE-1 Onsite 2026: Tier-2 Engineer's Real 4-Round Loop, how FAANG rounds differ from startup intensity