Swiggy Software Development Engineer I Interview Experience | DSA & Low-Level Design

Interview Process

The interview process consisted of four rounds covering Data Structures & Algorithms, Golang fundamentals, Low-Level Design (LLD) and problem-solving skills. Most of the technical rounds were coding-intensive, with interviewers paying close attention to both the correctness of the solution and the thought process behind it.

Overall, the coding questions ranged from easy to medium difficulty and were largely based on popular LeetCode-style problems. The final round focused on designing a simple booking system and evaluating communication and design skills.

Round 1 : Technical Interview (DSA)

• Duration: 60 Minutes

The first technical round consisted of three coding questions.

Although I don't remember the exact problem statements, the interview included two array-based questions followed by a graph problem. The first array question was relatively straightforward and tested basic array manipulation techniques. The second array problem was more involved and required careful handling of edge cases along with an optimized solution.

The final question was based on graph traversal. The interviewer expected me to identify the appropriate graph representation and choose a suitable traversal algorithm such as Breadth-First Search (BFS) or Depth-First Search (DFS), depending on the problem constraints.

Throughout the interview, the focus was on explaining the approach before writing code and discussing the time and space complexity of the solution.

Round 2 : Bar Raiser Interview

• Duration: 60 Minutes

The second round was conducted by a Bar Raiser rather than a member of the Swiggy engineering team.

The interviewer was friendly and made the discussion interactive. The coding question was based on the popular LeetCode problem 1711 : Count Good Meals.

Coding Question : Count Good Meals

Problem Statement

You are given an integer array deliciousness, where each value represents the deliciousness of a meal.

A good meal is a pair of meals whose sum is a power of two.

Return the total number of good meal pairs.

Example

Input:

deliciousness = [1,3,5,7,9]

Output:

4

My Approach During the Interview

I initially considered checking every possible pair of meals, but quickly realized that this brute-force approach would require O(n²) time and would not be suitable for larger inputs.

I then optimized the solution using a HashMap.

The idea was to process the array from left to right while maintaining the frequency of previously seen numbers. For every current value, I generated all possible powers of two within the valid range and checked whether the required complement had already appeared. If it existed, I added its frequency to the answer. After processing all possible sums, I inserted the current number into the frequency map.

Since there are only a limited number of powers of two that fit within the problem constraints, the overall complexity remains efficient.

The interviewer appreciated that I first discussed the brute-force solution before deriving the optimized approach.

Java Solution

import java.util.HashMap;
import java.util.Map;

public class CountGoodMeals {

    public int countPairs(int[] deliciousness) {

        int MOD = 1000000007;
        long answer = 0;
        Map<Integer, Integer> frequency = new HashMap<>();
        for (int value : deliciousness) {
            for (int sum = 1; sum <= (1 << 21); sum <<= 1) {
                answer += frequency.getOrDefault(sum - value, 0);
            }
            frequency.put(value,
                    frequency.getOrDefault(value, 0) + 1);
        }
        return (int)(answer % MOD);
    }
}

Complexity

After the coding discussion, the interviewer asked several questions on Golang.

The discussion covered channels, maps, goroutines and a few language fundamentals. The interviewer was more interested in understanding how channels enable communication between goroutines and when maps should be used in concurrent applications.

Round 3 : DSA Interview

• Duration: 60 Minutes

The third round consisted of two well-known LeetCode problems.

Coding Question 1 : Missing Number

Problem Statement

Given an array containing n distinct numbers from the range 0 to n, find the missing number.

Example

Input:

nums = [3,0,1]

Output:

2

My Approach During the Interview

I first discussed the sorting approach but pointed out that it would unnecessarily increase the time complexity.

Instead, I explained that XOR can be used because every number appears exactly once except the missing value. By XORing all indices and all array elements together, identical numbers cancel each other, leaving only the missing number.

The interviewer appreciated this optimization because it achieves linear time while using constant extra space.

Java Solution

public class MissingNumber {

    public int missingNumber(int[] nums) {
        int xor = nums.length;
        for (int i = 0; i < nums.length; i++) {
            xor ^= i;
            xor ^= nums[i];
        }
        return xor;
    }
}

Complexity

• Time Complexity: O(n)
• Space Complexity: O(1)

Coding Question 2 : Remove All Adjacent Duplicates in String

Problem Statement

Given a string, repeatedly remove adjacent duplicate characters until no duplicates remain.

Example

Input:

abbaca

Output:

ca

My Approach During the Interview

I explained that repeatedly scanning the string would lead to unnecessary work.

Instead, I used a stack-like approach. While traversing the string, if the current character matches the top of the stack, it is removed. Otherwise, it is pushed onto the stack.

This naturally removes adjacent duplicates in a single traversal.

// Java Solution
public class RemoveAdjacentDuplicates {

    public String removeDuplicates(String s) {
        StringBuilder stack = new StringBuilder();
        for (char ch : s.toCharArray()) {
            int length = stack.length();
            if (length > 0 && stack.charAt(length - 1) == ch) {
                stack.deleteCharAt(length - 1);
            } else {
                stack.append(ch);
            }
        }
        return stack.toString();
    }
}

Complexity

• Time Complexity: O(n)
• Space Complexity: O(n)

Round 4 : Low-Level Design

• Duration: 60 Minutes

The final round focused on Low-Level Design. The interviewer asked me to design a slot-booking platform for employees where each slot had a fixed capacity.

Before discussing classes or APIs, the interviewer expected me to clarify the functional requirements, constraints, booking rules, concurrency considerations and assumptions.

Unfortunately, this round did not go as planned.

The interview had already been rescheduled several times due to scheduling conflicts. On the day of the interview, a power outage occurred just before the meeting. After switching to backup power, I joined approximately ten minutes late. Because I had already lost valuable time, I became anxious and immediately started discussing the implementation without asking clarifying questions. Looking back, this was my biggest mistake.

Instead of understanding the requirements first, I rushed into designing the solution, which led to gaps in my design and prevented a structured discussion. Although I completed the interview, I felt that I had not demonstrated my actual design ability and I was eventually informed that I had not been selected.

Overall Experience

Overall, the interview process was technically strong and covered a wide range of topics, including DSA, Golang fundamentals and Low-Level Design. The coding rounds were based on standard interview patterns and rewarded candidates who could explain their approach clearly before writing code.

Although I was disappointed with the final outcome, the experience taught me an important lesson. Technical knowledge alone is not enough communication, requirement gathering and staying calm under pressure are equally important during system design interviews.

The rejection ultimately became a valuable learning experience that helped me improve my interview preparation for future opportunities.

Preparation Tips

If you're preparing for Swiggy's SDE interview, build a strong foundation in common DSA patterns such as hashing, sliding window, graph traversal, BFS/DFS, binary search and stack-based problems. Practicing one or two quality problems every day is far more effective than solving a large number of random questions.

In addition to coding, spend time learning Low-Level Design fundamentals. Practice asking clarifying questions before jumping into implementation, identify edge cases early and always explain your design decisions. If you're interviewing in Golang, revise concurrency concepts, channels, goroutines and common data structures, as these topics frequently appear in discussions.

Finally, make sure your interview environment is ready beforehand. Test your internet connection, audio, power backup and meeting setup in advance so that unexpected technical issues don't affect your performance.

My Advice to Other Candidates

One lesson I learned from this experience is to never rush into coding or design, especially if something unexpected happens before the interview. Even if you're running behind schedule, take a minute to understand the problem, clarify requirements and communicate your thought process. A structured discussion creates a much stronger impression than quickly jumping into implementation.

At the end of every interview, when you're asked if you have any questions, take the opportunity to ask thoughtful questions about the team, engineering culture, technical challenges or the role. It shows genuine interest and helps leave a positive final impression.