Flipkart Interview Questions (2026): Most Asked, With Answers

Candidates typically report four to five rounds for SDE-2 and above: one or two DSA/coding rounds, one system design round, one round that mixes low-level design with a bit of debugging, and a final hiring-manager or bar-raiser style round that covers behavioral fit alongside technical depth. Entry-level SDE-1 loops usually drop the system design round entirely and replace it with a second coding round instead. A recruiter phone screen and an online coding assessment (usually on a platform like HackerRank) often happen before any of this, especially for campus and early-career hiring.

The DSA bar is comparable to what you'd see at any large product company. The gap shows up in the system design and product-sense rounds, which assume familiarity with problems that are specific to running e-commerce at Indian scale: cash on delivery reconciliation, serviceability by pin code, seller-side inventory that updates from thousands of independent warehouses, and traffic patterns that spike violently around named sale events rather than staying roughly flat year-round. A candidate who's only designed systems for steady, predictable traffic tends to underestimate how much the flash-sale pattern changes the answer.

The iterative version keeps three pointers, previous, current, and next, and walks the list once, rewiring each node's next pointer to point backward. It runs in O(n) time and O(1) space.

def reverse_iterative(head):
  prev = None
  current = head
  while current:
    next_node = current.next
    current.next = prev
    prev = current
    current = next_node
  return prev

The recursive version is shorter to write but costs O(n) call-stack space, one frame per node, which matters if the list is long enough to risk a stack overflow. Interviewers usually want to hear you name that trade-off unprompted rather than write only one version and stop.

A single pass to build a frequency count, then a second pass over the original string in order, returning the first character whose count is exactly one. The second pass has to walk the original string, not the frequency map, because a hash map in most languages doesn't preserve insertion order the way you'd need for "first."

def first_non_repeating(s):
  counts = {}
  for ch in s:
    counts[ch] = counts.get(ch, 0) + 1
  for ch in s:
    if counts[ch] == 1:
      return ch
  return None

Sort both strings and compare, O(n log n), or build a frequency count for both and compare the two maps, O(n). The frequency-count version is the one worth leading with, since it's both faster and the more natural extension if the follow-up adds Unicode or case-insensitivity.

def is_anagram(a, b):
  if len(a) != len(b):
    return False
  counts = {}
  for ch in a:
    counts[ch] = counts.get(ch, 0) + 1
  for ch in b:
    if ch not in counts or counts[ch] == 0:
      return False
    counts[ch] -= 1
  return True

When the recursion depth could realistically approach the language's call-stack limit, a few thousand frames in most runtimes without tail-call optimization, or when the overhead of function calls actually matters in a hot loop that runs millions of times. For a tree with a few hundred nodes, recursion is fine and usually more readable. For processing a linked list with a hundred thousand nodes, recursive reversal risks a stack overflow that the iterative version simply doesn't have.

Abstraction hides complexity by exposing only what's necessary, an interface or abstract class describing what a payment processor does (charge, refund) without exposing how each provider implements it. Encapsulation bundles data with the methods that operate on it and restricts direct access to that data, private fields on a class accessed only through defined methods. They're related but not the same thing, abstraction is about what's exposed conceptually, encapsulation is about what's protected structurally.

A subquery excluding the max, or a LIMIT/OFFSET after sorting descending, both work. The subquery version handles ties more predictably (it returns the second-highest distinct value, not just the second row).

SELECT MAX(price) AS second_highest
FROM products
WHERE price < (SELECT MAX(price) FROM products);

INNER JOIN returns only rows where the join condition matches in both tables, customers who have at least one order. LEFT JOIN returns every row from the left table regardless of a match, filling in NULLs for the right table's columns when there's no match, every customer, including ones who've never placed an order, with NULL order columns for those.

SELECT c.name, o.order_id
FROM customers c
LEFT JOIN orders o ON c.customer_id = o.customer_id;
-- includes customers with zero orders, order_id is NULL for them

A clustered index determines the physical order rows are stored on disk, so a table can have only one (usually the primary key). A non-clustered index is a separate structure that points back to the row's location, and a table can have several. Reading via the clustered index is faster since the data is right there. Reading via a non-clustered index costs an extra lookup back to the actual row unless the query only needs columns already in the index itself.

Both run a hybrid model, some inventory owned directly, most sold through third-party sellers on the platform, but Flipkart built and owns its logistics arm, Ekart, rather than relying purely on India Post or third-party couriers the way a lot of marketplaces do. Flipkart also owns Myntra (fashion) as a largely separate app and brand rather than folding fashion fully into the main Flipkart experience, which shapes how category-specific teams operate internally.

Ekart is Flipkart's in-house logistics and delivery network, warehouses, delivery partners, the last-mile piece that gets a package from a seller's shelf to a customer's door. Owning it gives Flipkart direct control over delivery speed and reliability during sale events, when third-party courier capacity is exactly the thing every e-commerce player in the country is competing for at once. The trade-off is Flipkart carries the operational cost and complexity of running a logistics company on top of running an e-commerce company, which is a genuinely different business with its own hiring, tech, and ops needs.

Own inventory (sometimes called first-party or 1P) means Flipkart itself purchases stock and sells it directly, taking on inventory risk but controlling price and fulfillment fully. The marketplace model lets independent sellers list and price their own products on the platform, with Flipkart taking a commission and, often, handling logistics through Ekart on the seller's behalf. Most large e-commerce platforms, Flipkart included, lean heavily marketplace at this point, since it scales selection without the company having to buy and warehouse everything itself.

The interviewer isn't looking for a story where you were simply right and your manager was simply wrong. They want to see that you raised the disagreement directly and early, backed it with something concrete (a benchmark, a smaller prototype, a specific failure mode you'd hit before), and that you committed fully to the final decision once it was made, whichever way it went, rather than quietly under-delivering to prove a point.

A strong answer names the specific piece of information that was missing, explains what you did to reduce the uncertainty that was actually reducible in the time available, and is honest about the risk you accepted on the part that wasn't. Naming the risk you knowingly accepted, rather than pretending the decision was fully informed, is usually the detail that separates a genuine answer from a rehearsed one.

Pick a real bug with real user impact, not a cosmetic one, and walk through detection, mitigation, root cause, and the actual process change afterward, not just "I fixed it and added a test." Interviewers are listening for whether you take ownership of the mistake itself before pivoting to what you learned, since jumping straight to the lesson without acknowledging the impact reads as deflection.

Generic answers about "impact at scale" apply to a dozen other companies and tend to fall flat. A specific answer references something concrete about Flipkart's actual business, the logistics challenge of Ekart, the marketplace-fairness problem across thousands of sellers, the flash-sale traffic patterns, and connects it to something specific you've actually built or debugged that's genuinely similar in shape, not just adjacent in industry.

Junior and mid-level rounds do look close to standard LeetCode-medium territory, arrays, trees, graphs, dynamic programming, with one or two rounds per loop. For senior and staff-track candidates, the coding round often shrinks to a single round, sometimes folded into the system design conversation as a "code the core data structure" ask rather than a full standalone problem. The weight shifts toward system design, low-level design, and how you reason about trade-offs out loud, not just whether the final code compiles.

The diameter at any node is the sum of the heights of its left and right subtrees, and the overall answer is the maximum of that value across every node in the tree, not just the root. The trick is computing height and updating a running maximum in the same post-order traversal instead of two separate passes.

def diameter(root):
  best = [0]

  def height(node):
    if not node:
      return 0
    left = height(node.left)
    right = height(node.right)
    best[0] = max(best[0], left + right)
    return 1 + max(left, right)

  height(root)
  return best[0]

Candidates who compute height and diameter as two separate recursive functions get a correct but O(n squared) answer. Folding them into one pass gets O(n), and that's usually the follow-up question if you don't volunteer it.

The O(n squared) version is a classic DP: for each index, look back at every earlier index and extend the best subsequence that ends smaller than the current value. It's the correct starting answer and worth writing out even if you already know the faster one, because it shows you understand why the fast version works.

The O(n log n) version keeps an array of the smallest possible tail value for each subsequence length seen so far, and uses binary search to find where the current number belongs, either extending the array or replacing an entry in place. The array of tails isn't the actual subsequence, that trips people up, it's a bookkeeping structure. Reconstructing the real subsequence afterward needs a separate parent-pointer array if the interviewer asks for it.

Track the minimum price seen so far while scanning left to right, and at each index compute the profit if you sold today against that running minimum, keeping the best result. One pass, O(n) time, O(1) space, and no need to look ahead.

def max_profit(prices):
  min_price = float("inf")
  best_profit = 0
  for price in prices:
    min_price = min(min_price, price)
    best_profit = max(best_profit, price - min_price)
  return best_profit

Interviewers at Flipkart sometimes reframe this one around flash sale pricing, "find the best window to drop the price during a sale to maximize units sold given a demand curve", which is the same underlying pattern with a business story wrapped around it.

Reverse the whole array, then reverse the first k elements, then reverse the remaining n minus k elements. Three reversals, each O(n), no extra array needed. It's not the most obvious approach the first time you see it, but it's the one that actually satisfies "in place" cleanly.

def rotate(nums, k):
  n = len(nums)
  k %= n
  nums.reverse()
  nums[:k] = reversed(nums[:k])
  nums[k:] = reversed(nums[k:])

When the behaviors you're combining don't form a clean "is-a" hierarchy. A payment that's both "refundable" and "requires two-factor confirmation" doesn't fit neatly into a single inheritance chain, since some refundable payments don't need 2FA and vice versa. Composition, injecting a RefundPolicy and a ConfirmationPolicy as separate objects into a Payment class, lets you mix and match those behaviors without a combinatorial explosion of subclasses (RefundableConfirmedPayment, RefundableUnconfirmedPayment, and so on).

Strategy pattern. Define a PaymentMethod interface with a single pay(amount) method, then implement it separately for credit card, UPI, cash on delivery, and wallet. The checkout flow holds a reference to whichever PaymentMethod the customer picked and calls the same method regardless of which one it is, so adding a new payment method later means writing one new class, not touching the checkout flow's existing logic at all.

Group by customer, count distinct months within the date range, and filter for a count equal to the number of months in the range (three, for a quarter). The distinct is the part people forget, without it, a customer with five orders in January and none in February or March could still pass a naive count check.

SELECT customer_id
FROM orders
WHERE order_date >= '2026-01-01' AND order_date < '2026-04-01'
GROUP BY customer_id
HAVING COUNT(DISTINCT DATE_TRUNC('month', order_date)) = 3;

Neither on its own, honestly, and I think a candidate who picks one exclusively is giving an incomplete answer. Orders, payments, and inventory decrements need strong consistency and transactions, that's relational territory, a lost or double-counted inventory decrement is a real financial problem. The catalog itself, product descriptions, images, variable per-category attributes, read far more than it's written and doesn't need cross-row transactional guarantees, which is where a document store or search index earns its keep on read latency and flexible schema. Most systems at this scale end up polyglot rather than picking a single database for everything, and saying so out loud is usually the stronger answer.

Sizing uncertainty is the biggest single driver of fashion returns, and it's largely a data problem before it's a UX problem: a size-recommendation feature needs a customer's past purchase and return history across brands (since a Medium in one brand doesn't map cleanly to a Medium in another) to actually reduce mis-sized purchases, rather than a generic size chart that customers already mostly ignore. Better product photography and a genuine "true to size" signal aggregated from other buyers' reviews helps too, but it's a smaller lever than fixing the size-recommendation problem itself.

Segment before theorizing. Break the drop down by Android OS version, device tier (low-end versus flagship), app version, and network condition, since a 10% aggregate drop that's actually concentrated on, say, older low-RAM devices points somewhere completely different than a drop spread evenly across all Android users. Check whether a recent app release shipped alongside the sale start, since a regression from a build that went out days earlier can look like a sale-day problem when it's actually unrelated timing.

My honest first guess in a real incident like this would be a client-side crash or freeze on low-end devices under the sale's traffic and rendering load, that's the pattern I've seen most often reported for exactly this kind of platform-specific dip, but I'd want the crash-rate dashboard in front of me before committing to that theory out loud.

The honest framework is comparing incremental customer lifetime value against the cost of building genuinely new infrastructure, quick commerce needs dark stores and 10-to-20-minute delivery logistics that look nothing like Ekart's existing multi-day fulfillment network, not a small tweak to the existing one. A reasonable answer weighs whether the addressable market for near-instant delivery overlaps enough with Flipkart's existing customer base to justify a mostly new operational stack, versus whether that capital is better spent deepening selection or delivery speed in categories the company already dominates.

Name the framework you actually use, customer impact, revenue impact, technical risk of delay, whatever it is, and be specific about how you applied it to a real conflict rather than describing prioritization in the abstract. The stronger answers also mention how you communicated the trade-off back to the stakeholders who didn't get picked first, since silently deprioritizing someone's request without explanation is its own kind of failure even if the prioritization call itself was correct.

The useful version of this story includes what you offered instead of a flat no, a smaller scope that fit the original deadline, a slightly later date backed by a concrete estimate, an extra resource that would close the gap. A flat pushback with no alternative on the table tends to read as inflexibility rather than sound judgment, even when the original deadline really was unrealistic.

This comes up constantly in practice at a company where engineering, logistics, and seller operations all depend on each other but don't report into the same chain. A good answer shows you understood the other person's actual incentive, not just your own priority, and framed the ask in terms that mattered to them specifically, rather than simply repeating your request more insistently until they agreed.

The story should show you noticing a gap, a process failure or a piece of work nobody was clearly on the hook for, and stepping in without waiting to be assigned. What makes this land well is being specific about the actual cost of not acting (what would have broken, and for whom) rather than a vague claim of "going above and beyond."

Interviewers want to hear that you had a direct, specific conversation with the person first, not that you escalated to a manager immediately or quietly redistributed their work without saying anything. A stronger answer also considers whether the missed deadlines point to a scoping problem, unclear requirements or unrealistic estimates handed down from above, rather than assuming the individual is simply the entire cause.

A depth-first search with two visited sets, not one, is the part people get wrong. You need a set for nodes fully processed and a separate set for nodes currently on the recursion stack. A back edge, an edge pointing to a node that's still on the current recursion stack, means a cycle. An edge to a node that's already fully processed but off the stack is fine, that's just a shared descendant, not a cycle.

def has_cycle(graph):
  WHITE, GRAY, BLACK = 0, 1, 2
  color = {node: WHITE for node in graph}

  def dfs(node):
    color[node] = GRAY
    for neighbor in graph[node]:
      if color[neighbor] == GRAY:
        return True
      if color[neighbor] == WHITE and dfs(neighbor):
        return True
    color[node] = BLACK
    return False

  return any(color[n] == WHITE and dfs(n) for n in graph)

This is where I've seen candidates confidently reuse the undirected-graph cycle check (a single visited set) on a directed graph and get it wrong on the first real test case. The two are not the same algorithm, even though they look similar at a glance.

A min-heap holding the current head of each list is the standard answer. Pop the smallest, push it onto the result, and push that node's next element back onto the heap if one exists. With k lists and n total elements, that's O(n log k), since every element goes through the heap exactly once and the heap never holds more than k items.

import heapq

def merge_k_lists(lists):
  heap = []
  for i, node in enumerate(lists):
    if node:
      heapq.heappush(heap, (node.val, i, node))
  dummy = ListNode()
  tail = dummy
  while heap:
    val, i, node = heapq.heappop(heap)
    tail.next = node
    tail = tail.next
    if node.next:
      heapq.heappush(heap, (node.next.val, i, node.next))
  return dummy.next

The tuple has to include the list index alongside the value, otherwise Python's heap comparison falls through to comparing ListNode objects directly when two values tie, which throws. That's a real bug, not a theoretical one, I've watched it happen live in a mock interview.

An atomic decrement at the database level, conditional on stock greater than zero, is the baseline, not a read-then-write from application code, which has an obvious race condition between the read and the write. A single row update like UPDATE inventory SET stock = stock - 1 WHERE product_id = ? AND stock > 0 either succeeds or affects zero rows, and the application checks the affected row count to know which one happened.

At real scale, a single hot row still becomes a bottleneck even with atomic updates, because every request for that product serializes on the same row lock. The pattern that scales further reserves stock in short-lived slices, split the 200 remaining units across, say, 20 shards of 10 each, route requests to a shard, and only fall back to a slower coordinated check across shards once most shards report empty. It adds complexity and you'll sometimes reject a valid buyer slightly earlier than strictly necessary, but it avoids one row becoming a queue for the entire country.

A rigid schema with a fixed column per attribute breaks immediately, since apparel needs size and color while electronics needs RAM and warranty period, and a shared products table with every possible attribute column becomes mostly NULL for any given row. The common relational answer is an entity-attribute-value (EAV) side table: a product_attributes table with product_id, attribute_name, and attribute_value, joined back to the base products table for the shared fields.

EAV isn't free, it makes filtering and sorting by attribute value slower and messier in pure SQL, since you lose native typing and indexing on those attribute values. That's exactly why a lot of real catalog systems at this scale push category-specific attributes into a document store or a search index (Elasticsearch, say) instead of forcing all of it through relational EAV, keeping the relational database for the transactional core, orders, inventory, payments, where strict consistency actually matters.

Separate the read path from the write path aggressively. Product pages, which are read-heavy and mostly static during the sale window, get served from a CDN and an in-memory cache (Redis or similar) with a short TTL, not a live database query per request. The write path, actual checkout and inventory decrement, is the part you have to protect, because that's where correctness actually matters and where a spike can cause real damage, oversold inventory, double-charged customers.

Put a queue in front of the checkout write path so the database sees a bounded, steady rate of writes instead of the raw spike, and pre-scale the compute layer ahead of the sale start time rather than relying purely on autoscaling to react in real time, since autoscaling reacting to a 50x spike that starts in the same second across the whole country is usually too slow.

Read-heavy, so lean into caching and denormalization rather than fighting them. Each product's display data, title, images, price, key specs, gets flattened into a single cacheable document rather than assembled from five normalized tables on every request. Seller-side bulk updates (a seller uploading a CSV of 10,000 SKUs) go through an asynchronous ingestion pipeline that validates, then writes to the source of truth, then invalidates or refreshes the relevant cache entries, rather than blocking on a synchronous write path that a live shopper is also hitting.

The simplest real version is item-based collaborative filtering: precompute, offline, which products co-occur frequently in the same order, and serve that precomputed list at request time as a fast lookup, rather than computing similarity live per request. Offline batch jobs (nightly or a few times a day) recompute the co-occurrence table from recent order history, and the online path is just a key-value read keyed by product ID.

The honest caveat worth saying out loud in the interview: this approach struggles with brand-new products that have no order history yet, the cold-start problem, and a full answer usually mentions falling back to category-level or content-based similarity (same brand, same category, similar price band) for anything without enough co-occurrence data yet.

A token bucket or sliding-window counter per user, backed by Redis for the shared counter state across multiple application servers, is the standard approach. The interesting design decision is what to do with a request that gets rate-limited, silently dropping it is bad, so most real systems return a clear "high demand, please retry" response, sometimes with a randomized backoff hint, rather than a bare 429 with no guidance.

def is_allowed(user_id, redis_client, limit=5, window_seconds=10):
  key = f"rate:{user_id}"
  current = redis_client.incr(key)
  if current == 1:
    redis_client.expire(key, window_seconds)
  return current <= limit

A trie built from a list of popular search queries and product titles gets you prefix matching fast, and it's the classic textbook answer for a reason, it's genuinely the right data structure here. The part that matters more in practice is what populates the trie: a static, rarely-updated list of queries goes stale within days as trending products and seasonal demand shift, so the ranking behind the trie needs to blend historical popularity with recent search volume, refreshed on something like an hourly batch job, not a one-time load.

A Cart holding a list of CartItem objects (each with product reference, quantity, and price at time of add), plus a separate CouponStrategy interface that a concrete coupon type (percentage off, flat discount, buy-one-get-one) implements. Keeping coupon logic out of the Cart class itself, applying it through the strategy interface, is the part that shows design maturity, because it means adding a new coupon type later doesn't touch the Cart class at all.

class CartItem:
  def __init__(self, product, quantity, price):
    self.product = product
    self.quantity = quantity
    self.price = price

class Cart:
  def __init__(self):
    self.items = []
    self.coupon = None

  def add_item(self, item):
    self.items.append(item)

  def total(self):
    subtotal = sum(i.price * i.quantity for i in self.items)
    return self.coupon.apply(subtotal) if self.coupon else subtotal

A layered approach works better than one big filter. Automated signals catch the obvious cases first, price far below the category median for a supposedly branded item, a new seller account with no order history suddenly listing hundreds of units of a premium brand, image matches against known counterfeit listings already flagged elsewhere on the platform. Anything the automated layer flags as borderline, rather than clearly fake or clearly fine, routes to a human review queue, since false positives here directly hurt legitimate sellers' business and false negatives hurt customer trust, and an automated system alone tends to be miscalibrated on one side or the other.

Decouple the event source from delivery with a message queue in the middle, order-status changes get published as events, and separate consumer services handle each channel, push notification, SMS, email, independently. That way a slow or failing SMS provider doesn't back up push notifications, and each channel can retry and scale on its own schedule.

Batching and prioritization matter more than raw throughput here. A "delivered" notification is time-sensitive and should go out close to real time. A "your review has been posted" notification isn't, and can tolerate being batched or delayed a few minutes under load. Treating every notification as equally urgent is the most common mistake candidates make in this answer, it makes the whole system harder to scale for no real benefit to the user.

One source of truth for order status, a single service that owns the state machine (placed, packed, shipped, out for delivery, delivered, or the return/refund branch off any of those), and every other channel, app, SMS, email, subscribes to status-change events from that one service instead of maintaining its own copy of the status. The moment two systems independently decide what the current status is, they will eventually disagree, usually right when a customer is anxiously checking.

The harder part is Ekart's ground-truth data itself often comes from a courier's own system with its own latency and occasional gaps, so the order service needs a policy for what to show when the last known update is, say, six hours old and physically implausible ("out for delivery" for two days straight). I don't have a clean textbook answer for that gap, most real systems fall back to an estimated-delivery-window message rather than pretending the stale status is current.

The core entity isn't just Product, it's a Listing tied to a specific Seller and a specific Warehouse, since the same product can be sold by multiple sellers at different prices with different stock in different locations. A Product holds shared attributes (title, category, images). A Listing holds seller-specific data (price, stock count, warehouse ID). Order fulfillment picks a Listing, not a Product, based on price and which warehouse can ship to the buyer's pin code fastest.

Modeling this as one flat Product table with a single stock count is the mistake I see most often in this round, it works for a single-seller model and falls apart the moment two sellers list the same item, which is exactly Flipkart's actual marketplace structure.

Order of operations changes the final total, so the design has to make that order explicit rather than implicit. A common approach is a chain of discount handlers, each one a small object implementing an apply(cart) method, run in a defined sequence: seller-level discount first, then category-level promotion, then a bank or card-linked offer, then a wallet coupon last, since coupons usually apply to whatever total remains after other discounts, not the original price.

The detail that trips people up: some discounts should apply to the pre-tax subtotal and some to the post-tax total, and mixing that up produces a total that's off by a small, hard-to-notice amount, exactly the kind of bug that survives QA and shows up as a support ticket weeks later.

This is less a pure engineering problem than a policy-plus-engineering one. A pure first-come-first-served allocation across all sellers listing the same product tends to reward whoever has the fastest connection or a bot, not whoever's actually offering the best deal or fastest delivery to that specific buyer. A fairer design ranks eligible listings by a blend of price, delivery estimate to the buyer's pin code, and seller rating, then allocates stock proportionally across sellers who clear some minimum bar, rather than letting a single listing's stock evaporate in the first thirty seconds while five equally good listings sit untouched. I'd flag to the interviewer that this trades off pure speed-to-checkout for fairness, and ask which one the business actually prioritizes before committing to a specific ranking formula.