Zepto SDE-1 Interview Experience (Backend Developer) : Real DSA, LLD, Chess Game Design

Published : 26 May 2026

775 Views

#interview-experience

I interviewed for an SDE-1 Backend Developer role at Zepto and the entire experience felt very similar to a fast-paced product-company backend interview process. The rounds were highly focused on problem-solving speed, clean coding, low-level design, database schema design and practical backend engineering discussions.

At the time of the interview, I had around 1 year 4 months of experience as a Backend Developer. Unfortunately, my previous startup company in Hyderabad had gone through layoffs, so I was actively looking for opportunities. I applied for the role through a Google Form shared by a Zepto employee on LinkedIn and after a short wait, I started receiving interview communication.

One thing I realized very quickly during this process was: Zepto expects strong execution speed. It’s not enough to just know DSA or system design concepts. The interviewers expect you to: think fast, communicate clearly, code cleanly and optimize quickly. especially during the BarRaiser rounds.

The overall difficulty level of the process was medium to hard, mainly because of the time pressure and interviewer expectations. If you’re preparing for:

Zepto SDE-1 interview
backend developer interviews
BarRaiser coding rounds
chess game low-level design
DSA interviews for product companies

then this detailed experience can genuinely help you understand what to expect.

Interview Process Overview

The process mainly consisted of 2 technical rounds.

Round	Focus Area
Round 1	DSA + Problem Solving
Round 2	Low-Level Design + DB Schema + APIs

Both rounds were conducted on BarRaiser. Even though there were only two rounds, the discussions were intense and heavily technical.

Round 1 : DSA & Problem Solving Round

This round was entirely focused on coding. The interviewer clearly mentioned at the beginning that the expectation was: Solve 2 DSA questions within roughly 25 minutes each That immediately created pressure because both correctness and speed mattered heavily. The interviewer was collaborative but also closely evaluated: coding speed, optimization, communication, naming conventions and thought process.

One thing I noticed was that they were not interested in brute-force thinking. They expected optimized solutions almost immediately.

Problem 1 : Minimum Cost For Tickets (Leetcode)

The first problem asked was: Minimum Cost For Tickets This is actually considered a fairly difficult dynamic programming problem, especially under interview pressure.

The problem gives:

a list of travel days
ticket costs for:
- 1-day pass
- 7-day pass
- 30-day pass

Example :


Input: days = [1,4,6,7,8,20], costs = [2,7,15]
Output: 11

The goal is: Find the minimum total cost required to cover all travel days. At first glance, the problem can feel confusing because there are multiple overlapping choices at every step. The interviewer mainly wanted to evaluate:

recursive thinking
dynamic programming optimization
state transition understanding

My Initial Thought Process

I first explained the brute-force recursive idea. At every travel day: buy 1-day pass or 7-day pass or 30-day pass and recursively compute the minimum remaining cost. After discussing recursion, I optimized it using memoization because overlapping subproblems were clearly visible.

Honestly, this problem consumed much more time than expected. The interviewer expected it to be solved within around 25 minutes, but I took nearly 35 minutes to fully complete and explain the optimized solution. Still, the interviewer appreciated the approach because I continuously communicated my reasoning instead of staying silent.


class Solution {

    public int mincostTickets(int[] days, int[] costs) {
        Integer[] dp = new Integer[days.length];
        return solve(0, days, costs, dp);
    }

    private int solve(int index, int[] days, int[] costs, Integer[] dp) {
        if (index >= days.length) {
            return 0;
        }
        if (dp[index] != null) {
            return dp[index];
        }
        int oneDay = costs[0] + solve(index + 1, days, costs, dp);
      
        int i = index;
        while (i < days.length && days[i] < days[index] + 7) {
            i++;
        }
        int sevenDay = costs[1] + solve(i, days, costs, dp);

        i = index;
        while (i < days.length && days[i] < days[index] + 30) {
            i++;
        }
        int thirtyDay = costs[2] + solve(i, days, costs, dp);

        return dp[index] =
                Math.min(oneDay,
                Math.min(sevenDay, thirtyDay));
    }
}

Key Learning from This Problem

One important thing I learned from this round was: Interviewers value communication during difficult problems Even if you are stuck temporarily, continuously explaining:

what you are thinking
why a solution fails
how you are optimizing

creates a much better impression. Silence during interviews usually hurts more than imperfect approaches.

Problem 2 – Daily Temperatures (Leetcode)

The second question was Daily Temperatures. This problem is a classic stack-based problem and comparatively easier once you identify the pattern.

Given an array of temperatures, for every day we need to determine: How many days must pass before a warmer temperature appears If no warmer day exists, return 0 for that position.

Example:


Input:
[73,74,75,71,69,72,76,73]

Output:
[1,1,4,2,1,1,0,0]

The interviewer specifically mentioned that this was a variation of a standard monotonic stack problem.

My Approach

The brute-force approach would compare every future temperature for every index, leading to O(N²) complexity. Instead, I used a monotonic decreasing stack.

The idea is:

maintain indices in decreasing order of temperatures
whenever a warmer temperature appears, resolve pending indices

This reduces complexity to O(N). I solved this problem in around 10 minutes because I had practiced similar stack problems before.


class Solution {

    public int[] dailyTemperatures(int[] temperatures) {
        int n = temperatures.length;
        int[] result = new int[n];
        Stack<Integer> stack = new Stack<>();
        for (int i = 0; i < n; i++) {
            while (!stack.isEmpty() &&
                    temperatures[i] > temperatures[stack.peek()]) {
                int index = stack.pop();
                result[index] = i - index;
            }
            stack.push(i);
        }
        return result;
    }
}

After the round, I received positive feedback from the interviewer. The interviewer mentioned that problem-solving ability was good and optimization understanding was decent. but suggested improving variable naming, coding speed and implementation fluency under pressure

Honestly, this feedback was very fair. At product companies, even small improvements in coding speed make a huge difference because interviewers intentionally keep time pressure high.

I received the Round 2 interview invitation around two days later.

Round 2 : Low-Level Design + Database Schema + APIs

This round was much more backend engineering focused. The interviewer asked me to: Design a Chess Game

Initially, it sounded simple, but the discussion quickly became deep. The interviewer expected:

class structures
design patterns
APIs
database schema
move validation logic
extensibility discussions

This was not just a UML exercise. The interviewer wanted to understand how I think while designing real systems.

Chess Game LLD Discussion

I started by identifying the major entities: Player, Board, Piece, Move, Game and Position. Then I discussed how inheritance can be used for chess pieces. For example: King, Queen, Bishop, Knight, Rook and Pawn. Can inherit from a base Piece class.

I also discussed: encapsulation, abstraction and polymorphism. during the design.

Design Patterns Discussion

The interviewer specifically asked where design patterns could be useful.

I discussed:

Factory Pattern for piece creation
Strategy Pattern for move validation
Singleton Pattern for game manager (optional discussion)

The interviewer seemed more interested in my reasoning than memorized definitions.

Database Schema Design

The next discussion focused on schema design.

I designed tables for players, games, moves and match history. I also explained relationships between entities and why indexing would matter for querying ongoing games efficiently.

The interviewer asked follow-up questions around:

scalability
storing board state
move history optimization

which made the discussion feel very practical.

API Design

The interviewer then asked me to define APIs.

I designed APIs such as:

Start New Game
POST /games/start
Make Move
POST /games/{id}/move
Fetch Game State
GET /games/{id}

I also explained request payloads, responses, status codes and validation handling.

This part of the interview honestly felt very similar to real backend development discussions.

Overall Experience at Zepto

Technically, the interview process at Zepto was genuinely good. The interviewers were technically strong and the rounds tested:

DSA fundamentals
optimization skills
object-oriented design
backend engineering thinking
API design capability

The main challenge was speed, time pressure and implementation clarity.

Important Preparation Advice

If you're preparing for backend-focused SDE-1 interviews at product companies like Zepto, focus heavily on:

dynamic programming
stack problems
recursion + memoization
LLD fundamentals
API design
database schema design
OOP principles
design patterns

Most importantly: Practice solving problems under time pressure Because knowing the solution and implementing it quickly are two completely different skills during interviews.