Flipkart Software Engineer Interview: Questions & Prep (2026)

Flipkart software engineer interviews are DSA-heavy at the screen and scale-obsessed at the design stage. The loop typically runs online assessment → two DSA rounds → a system design round (for SDE2 and above) → a hiring manager round covering projects and behavioural fit. Candidates report the DSA rounds sit at LeetCode medium-to-hard difficulty, with interviewers pushing past the first working solution toward optimal time and space complexity. The system design round is where Flipkart differentiates: expect e-commerce problems at Big Billion Days scale — flash-sale traffic spikes, inventory services that must never oversell, and cart state that has to stay consistent across devices and sessions. Freshers and SDE1 candidates can expect the design round to be replaced or lightened, with more weight on problem-solving fundamentals and CS basics (OS, DBMS, networks). If you're still building your overall candidacy, start with the broader guide on [how to get hired at Flipkart](/company_guide/how-to-get-hired-at-flipkart.html).

1. Given a stream of orders, return the top K most-ordered products at any point. Optimise for repeated queries.
2. Implement an LRU cache with O(1) get and put — then extend it to be thread-safe.
3. Merge overlapping delivery time slots, and find the minimum number of delivery agents needed for a day's schedule (interval scheduling).
4. Given a grid of warehouses and blocked routes, find the shortest path for a shipment (BFS/Dijkstra variants).
5. Detect a cycle in a directed graph — framed as detecting circular dependencies in an order-fulfilment pipeline.
6. Design a flash-sale system for a product with 1,000 units and 10 lakh interested buyers hitting at the same second.
7. Design Flipkart's inventory service: how do you prevent overselling when concurrent orders race for the last unit?
8. Design the shopping cart: a user adds items on mobile, opens the site on desktop — how does the cart stay consistent, and what happens when a price changes mid-session?
9. Design a rate limiter for Flipkart's public APIs. Compare token bucket vs. sliding window.
10. Implement search autocomplete for product queries (trie + top-K suggestions with ranking).
11. Generate globally unique, roughly sortable order IDs across multiple data centres without a single point of failure.
12. Tell me about a production incident you owned end to end — what broke, what you did, and what changed afterwards.

Q: Return the top K most-ordered products from an order stream, optimised for repeated queries.

Start by clarifying: is the stream bounded, and how often is top-K queried vs. updated? For frequent updates and occasional queries, maintain a hash map of product → count plus a min-heap of size K keyed on count; each order updates the map in O(1) and adjusts the heap in O(log K), so queries return in O(K). If K is queried constantly and counts are bounded, mention bucket-sort-by-frequency as an O(1)-amortised alternative. State complexities unprompted: O(N log K) time overall, O(N + K) space. Then volunteer the scale follow-up before the interviewer asks: at Flipkart order volumes a single map won't fit one machine, so shard by product ID, keep per-shard top-K, and merge — the same pattern as a distributed count-min sketch. Interviewers report the differentiator is exactly this unprompted jump from single-machine correctness to sharded scale.

Q: Design a flash-sale system: 1,000 units, 10 lakh buyers, one second.

Frame the problem as admission control, not raw throughput. Outline: (1) Requirements — no overselling, fairness within reason, graceful degradation for the 99.9% who won't get stock. (2) Front door — pre-warm a CDN-served sale page; on click, issue queue tokens from a lightweight gateway so only a controlled trickle reaches core services. (3) Inventory — hold the 1,000-unit counter in Redis and decrement atomically (DECR or a Lua script); a non-negative result reserves a unit with a TTL, and payment confirmation converts the reservation while expiry returns it to stock. (4) Everything downstream — order creation, notifications — goes async via a message queue. (5) Degradation — the moment the counter hits zero, flip a "sold out" flag at the edge so the remaining lakhs of requests never touch the database. Close with the key trade-off: you're choosing availability and strict inventory correctness over per-user fairness, and say so explicitly.

Q: Tell me about a production incident you owned end to end.

*Situation:* During a payment-gateway migration at my previous company, checkout error rates spiked to 8% within an hour of a Friday-evening deploy.

*Task:* As the on-call engineer who had shipped the change, I owned diagnosis, mitigation, and the follow-up fix.

*Action:* I checked dashboards first and isolated the errors to one gateway's timeout path — our new retry logic was retrying non-idempotent charge calls. I rolled back within 20 minutes, reproduced the bug in staging, and re-shipped with an idempotency key on every charge request plus a regression test.

*Result:* Error rates returned to baseline the same evening, and the incident review added idempotency checks to our payments code-review checklist. No duplicate charges reached customers.

For DSA rounds: restate the problem, walk a small example, state the brute force with its complexity, then improve — never jump silently to the optimal answer, because Flipkart interviewers grade the reasoning path. Dry-run your code on an edge case before declaring done. For system design: requirements (functional, then scale numbers) → API sketch → data model → high-level architecture → deep-dive on the hardest component → failure modes and trade-offs. In e-commerce designs, always name the consistency choice: inventory wants strong consistency (never oversell), carts tolerate eventual consistency with conflict resolution (last-write-wins or merge-on-read), and you should say which you're picking and why. For behavioural questions, use STAR with one number in every result.

Candidates report three consistent bars. First, optimal-and-clean in DSA: reaching the right complexity class matters, but so does readable code, sensible naming, and self-driven edge-case testing. Second, scale instinct in design: interviewers typically push a working design to 10x — Big Billion Days load — and want to hear what you'd degrade gracefully (recommendations, reviews) versus what must never break (payments, inventory decrement). Third, ownership: hiring manager rounds probe whether you've carried something through ambiguity — incidents handled, migrations led, decisions defended. Concurrency fluency stands out at every level; being comfortable reasoning about race conditions on the last unit of stock is close to a Flipkart-specific signal.

Weeks 1–2: DSA volume with intent — 40–50 problems weighted toward arrays, strings, heaps, graphs, and dynamic programming, timed at 35–40 minutes each, always stating complexity aloud. Week 3: system design — work through flash sale, inventory service, cart, rate limiter, and notification fan-out; for each, write the one-page design and rehearse the strong-vs-eventual consistency justification. Week 4: mocks and stories — two full mock interviews (one DSA, one design), plus four STAR stories covering an incident, a conflict, a technical decision, and a failure, each with a quantified result. Revise OS/DBMS/networking basics if you're interviewing at SDE1. While you prep, don't let your pipeline go cold: [knok](https://knok.work/) searches 150+ job boards overnight, surfaces only high-fit engineering roles, and drafts hiring-manager outreach, so practice hours don't come at the cost of applications.

Jumping straight to code without clarifying constraints — Flipkart interviewers typically leave inputs deliberately underspecified to test this. Stopping at the brute force, or reaching the optimal solution but being unable to explain why it's optimal. In design rounds, hand-waving inventory consistency ("we'll use a lock") without addressing what happens across replicas and failures. Designing for average load and going blank when asked about Big Billion Days traffic. Ignoring the hiring manager round — candidates report weak project ownership stories sink otherwise-strong loops. And claiming certainty about Flipkart's internal stack; hedge with "I'd validate against your architecture."