Interview experience
BigBasket Interview Questions and Answers (2026)
Overview
Section titled “Overview”BigBasket’s fresher SDE loop is a 3-4 stage process where DSA and SQL fundamentals are consistently framed around grocery/e-commerce scenarios - inventory, catalog, and order management - rather than abstract textbook prompts.
BigBasket interview process at a glance
Section titled “BigBasket interview process at a glance”| Round | Duration | What they test |
|---|---|---|
| Online Assessment | ~60 min | DSA problems, SQL queries, API-design based questions |
| Technical Interview 1 | 45-60 min | DSA/coding, problem-solving |
| Technical Interview 2 | 45-60 min | Project deep-dive, hands-on frontend/backend experience |
| HR Interview | 20-30 min | Background, fit, role/location expectations |
Online Assessment
Section titled “Online Assessment”A roughly 60-minute screening test mixing DSA, SQL, and API-design questions - the first filter before any human interview.
Common questions
- Sliding-window and two-pointer array/string problems
- Design or reason about an LRU cache
- SQL joins and aggregation queries (e.g. top-selling products by category)
- Basic API-design/authentication concepts (JWT, REST conventions)
Technical Interview 1
Section titled “Technical Interview 1”A DSA-focused round with a tech panel member, frequently framing standard algorithmic problems around BigBasket’s actual domain - inventory, catalog, and order flows.
Common questions
- Sliding-window or two-pointer problems reframed as an inventory/catalog scenario
- Design a data structure for order-tracking or cart management
- Time/space complexity trade-offs and edge cases on your solution
Technical Interview 2
Section titled “Technical Interview 2”Shifts from algorithms to a hands-on project deep-dive - expect detailed questions on your actual frontend/backend work rather than new coding problems.
Common questions
- Walk through your most complex project’s architecture and your specific contribution
- Frontend or backend implementation details relevant to your resume stack
- What would you change or rebuild if you did the project again?
Round-by-round narratives are on the BigBasket interview experience page.
HR Interview
Section titled “HR Interview”A closing 20-30 minute conversation on background, motivation, and fit - often includes a lightweight system-design sketch relevant to grocery delivery.
Common questions
- Tell me about yourself, and why BigBasket?
- Walk through the design of a feature you’d build for a grocery-delivery or inventory system
- Tell me about a time you optimized something for scale or performance under real-world constraints
- Location and role expectations
Sample answer frameworks for each of these are on the BigBasket HR interview questions page.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: Find the maximum sum of any contiguous subarray of size k.
Use a fixed-size sliding window rather than recomputing each sum. Add the first k elements to get an initial window sum, then slide: for each new index i from k onward, add arr[i] and subtract arr[i - k], tracking the maximum seen. That is O(n) time and O(1) space, versus the O(n times k) brute force that re-adds every window from scratch. The variable-size version of the same pattern - grow the right edge, shrink the left while a constraint is violated - is what solves problems like the smallest subarray whose sum is at least a target, and interviewers usually ask you to extend to it. Note that the shrinking variant only works when all elements are non-negative, since with negatives the window sum is not monotonic and you need prefix sums with a hash map instead.
Q: Given a sorted array, find a pair that sums to a target.
Place one pointer at index 0 and another at index n minus 1. If the pair’s sum equals the target you are done; if it is smaller than the target, move the left pointer right to increase the sum; if it is larger, move the right pointer left. Each pointer moves at most n steps, so the whole scan is O(n) time and O(1) space, and it works because sortedness makes the sum monotonic in each pointer’s direction. If the input is unsorted, a hash set storing complements gives O(n) time with O(n) space and is usually preferred - sorting first would cost O(n log n). Interviewers commonly follow up with three-sum, which fixes one element and runs this two-pointer scan inside a loop for O(n squared).
Q: How do you implement an LRU cache with O(1) get and put?
Combine a hash map with a doubly linked list. The hash map maps a key to the list node holding it, giving O(1) lookup; the doubly linked list keeps entries in recency order, with most recently used at the head and least recently used at the tail. On get, look up the node and move it to the head. On put, either update and move the existing node to the head, or insert a new node at the head and, if capacity is exceeded, remove the tail node and delete its key from the map. The list must be doubly linked because eviction and reordering require unlinking a node in O(1) given only that node, which a singly linked list cannot do. In Java, LinkedHashMap with accessOrder set to true and an overridden removeEldestEntry gives the same behaviour out of the box.
Q: Write a SQL query for the top three best-selling products in each category.
Use a window function to rank within each partition: SELECT category, product_name, total_sold FROM (SELECT p.category, p.product_name, SUM(o.quantity) AS total_sold, ROW_NUMBER() OVER (PARTITION BY p.category ORDER BY SUM(o.quantity) DESC) AS rn FROM order_items o JOIN products p ON o.product_id = p.id GROUP BY p.category, p.product_name) t WHERE rn <= 3; The window function must live in a subquery or CTE because you cannot filter on a window alias in the same SELECT’s WHERE clause - windows are evaluated after WHERE and GROUP BY. Choose ROW_NUMBER when you want exactly three rows regardless of ties, RANK when ties should occupy the same position and skip numbers, and DENSE_RANK when ties share a position without gaps.
Q: Explain JWT authentication and how it compares to server-side sessions.
A JSON Web Token is three base64url-encoded parts - header, payload, and signature - joined by dots, where the signature is computed by the server over the first two using a secret (HMAC) or a private key (RSA/ECDSA). Because the token is self-contained and signed, any service can verify it without a database lookup, which makes it well suited to stateless, horizontally scaled microservices. The catch is revocation: a session can be deleted server-side instantly, whereas a JWT stays valid until it expires, so the standard pattern is a short-lived access token of a few minutes plus a long-lived refresh token that is stored server-side and can be revoked. Two things candidates get wrong: the payload is only encoded, not encrypted, so never put secrets in it, and the server must reject a token whose header claims the none algorithm.
Q: Which HTTP methods are idempotent, and why does it matter for an order API?
GET, PUT, DELETE, HEAD and OPTIONS are idempotent - making the same call repeatedly leaves the server in the same state as making it once - while POST and PATCH generally are not. GET must also be safe, meaning it causes no state change at all, which is why a checkout action must never be a GET. This matters directly for orders: if a mobile client times out after sending a POST to place an order, a blind retry could create a duplicate order, so the standard fix is to have the client generate an idempotency key and the server store the result against that key, returning the original response on retry. The right status codes complete the picture - 201 with a Location header on creation, 409 on a conflicting state such as a duplicate cart merge, 422 for a semantically invalid payload, and 429 when the client is rate limited.
Q: How would you stop overselling the last unit of stock during a flash sale?
The failure mode is a read-then-write race: two requests both read stock as 1 and both decrement. The simplest correct fix is to make the check and the decrement one atomic statement - UPDATE inventory SET stock = stock - 1 WHERE sku_id = ? AND stock > 0; - and treat zero affected rows as sold out, since the database applies row locks and serialises the conflicting updates. Optimistic locking is the alternative: keep a version column, include it in the WHERE clause, and retry on failure, which suits low-contention paths but produces heavy retry churn on a hot SKU. At higher scale you move the counter into Redis and use an atomic DECR or a small Lua script so the decrement and the zero check are one operation, then reconcile to the database asynchronously. Reservations should also carry a TTL so abandoned carts release stock automatically instead of holding it forever.
Q: A category listing page has become slow. How do you diagnose and fix it?
Start with EXPLAIN on the actual query to see whether the planner is doing a full table scan, and check whether the filter and sort columns are indexed - a composite index on (category_id, created_at DESC) serves both the filter and the ordering in one structure, whereas two separate single-column indexes usually will not. Watch for anti-patterns that silently disable an index, such as wrapping the indexed column in a function or leading a LIKE pattern with a wildcard. Deep pagination with a large OFFSET is the other common culprit, since the database still walks every skipped row; keyset pagination, filtering on the last seen sort key, keeps cost constant regardless of page depth. If the query is already optimal and the traffic is read-heavy, add a cache in front keyed by category and filter set, serve reads from a replica, and for genuine text search move to a dedicated inverted-index engine rather than pushing LIKE queries at the primary database.
Frequently asked questions about BigBasket interviews
Section titled “Frequently asked questions about BigBasket interviews”What is the BigBasket interview process for freshers?
BigBasket typically runs 3-4 rounds for SDE roles: 1. Online Assessment (about 60 minutes) - a mix of DSA problems, SQL queries, and API-design based questions, used as a screening round. 2. Technical Interview 1 (45-60 minutes) - DSA/coding and problem-solving with a tech panel member. 3. Technical Interview 2 (45-60 minutes) - more project-heavy, focused on hands-on frontend/backend experience. 4. HR Interview (20-30 minutes) - background, fit, and role/location expectations.
What questions are asked in BigBasket interviews?
Expect DSA patterns like sliding window, two pointers, and LRU caching, SQL joins and aggregations, and API/system-design basics like authentication and JWT. Because BigBasket runs a large-scale grocery e-commerce and delivery platform, interviewers often frame problems around inventory, catalog, or order-management scenarios rather than abstract examples.
How many rounds are there in the BigBasket interview?
Most BigBasket SDE drives run 3-4 rounds: an Online Assessment as a screening step, one or two Technical Interviews, and an HR round. Some experiences report the two technical rounds split as one algorithmic and one project/hands-on focused round.
What is the BigBasket technical interview like?
Technical Interview 1 (45-60 min) is DSA-focused - sliding window, two-pointer, and LRU-cache-style problems, often framed around a grocery/e-commerce scenario (inventory, catalog search) rather than an abstract prompt. Technical Interview 2 shifts to a project deep-dive and hands-on frontend/backend questions, testing whether you actually built and can defend what’s on your resume.
How should I prepare for BigBasket interviews?
Practice DSA patterns (sliding window, two pointers, LRU) and revise SQL joins/aggregations for the OA, and be ready to talk through the design of a feature relevant to e-commerce or grocery-tech - inventory, search, or order fulfillment are common framing devices. Know your projects well enough to discuss real trade-offs in the hands-on/project round.
Who owns BigBasket, and does that affect hiring?
BigBasket has been majority-owned by the Tata Group (via Tata Digital) since a 2021-2022 acquisition, and now operates as part of Tata’s broader digital/retail ecosystem alongside Tata Neu. This mainly affects backend integration priorities (Tata Neu tie-ins) rather than the fresher SDE interview format itself, which stays focused on DSA, SQL, and hands-on project depth.