District by Zomato | SDE-1 | R-2 | Interview
- Posted
- 6 Oct 2026
Summary
I interviewed for a Backend Engineer/SDE-1 role at District by Zomato, where I faced a system design and backend implementation round; I was ultimately rejected.
How it went
Company: District by Zomato
Role: Backend Engineer / SDE-1
Experience: 0 (1 year of internship experience)
Round 1: https://leetcode.com/discuss/post/8550229/district-by-zomato-sde-1-r-1-interview-e-chtp/
Started with a backend/API design problem:
Design an API to fetch a user's District Money transaction history in a paginated manner.
Discussed offset vs cursor-based pagination, cursor design using createdAt + transactionId, composite indexes, API contracts and SQL queries.
Then the interviewer added more constraints, the transaction history was coming from three independent tables. Discussed JOIN vs UNION ALL, querying the tables separately and merging the results at the application layer, and how pagination would work across multiple sources.
There was also a coding part where I was expected to write the backend implementation and SQL rather than just explain the approach.
One interesting follow-up was:
"Apart from offset and cursor, what other way can you paginate?"
I said I couldn't think of another one. He pointed out page-number pagination. In hindsight, page-number pagination is basically another interface over offset pagination (offset = (page - 1) * limit), I told in the interview also but don't know what he was expecting or maybe i am wrong here.
The interviewer kept pushing on the why/how behind each decision and how the design behaves at scale.
I was also expected to write the code fairly cleanly without relying on AI assistance, and honestly that part exposed a weakness — I've gotten a little too comfortable with AI-assisted coding lately, so my implementation was much messier than I'd have liked.
Ended up getting rejected. More than anything, it showed me that I need to get comfortable coding backend stuff from scratch again, not just being able to explain the architecture.
Questions asked (2)
- 01
Design API for paginated transaction history
System Design
Design an API to fetch a user's District Money transaction history in a paginated manner. The design should consider offset vs cursor-based pagination, cursor design using
createdAt+transactionId, composite indexes, API contracts, and SQL queries. Additional constraints include that the transaction history is stored in three independent tables, requiring decisions on JOIN vs UNION ALL, querying tables separately, merging results at the application layer, and handling pagination across multiple data sources. - 02
Alternative pagination methods
System Design
Apart from offset and cursor, what other way can you paginate?