← Interview experiences
Rejected

Software Development Engineer II at Flipkart

Difficulty
Process took
2-3 Weeks
Rounds
4
Format
Remote
Applied via
LinkedIn

How it went

  • If they ask for re-evaluation, take it seriously, it means you’re close. But don’t expect different questions. Prepare the same use case thoroughly.
  • Flipkart’s system design round is critical, even if your DSA and coding rounds go well, one poor HLD round can lead to rejection.

What they would tell you

  • If they ask for re-evaluation, take it seriously, it means you’re close. But don’t expect different questions. Prepare the same use case thoroughly.
  • Flipkart’s system design round is critical, even if your DSA and coding rounds go well, one poor HLD round can lead to rejection.

How to prepare

  • Flipkart often uses binary search, greedy, and search-based problems. Prepare 5-7 medium questions per topic and get comfortable dry running them.
  • Practice object-oriented design patterns like Strategy, Singleton, and proper interface use. Clean LLD and modular class structures matter.

Round by round

  1. 1

    Machine Coding90 min

    I was asked to design and implement a Buy Now Pay Later (BNPL) system using object-oriented design principles and relevant design patterns. In my approach, I used the Strategy Pattern, Singleton, and followed the Interface Segregation Principle. I wrote a clean LLD in Java, covering key components like credit evaluation, transaction handling, and user state management. I submitted the zipped code through a Google Form, and later that day, had a 30-minute discussion to walk through my design decisions and implementation.

  2. 2

    DSA86 min

    This round typically includes two DSA questions, but since I completed both ahead of time, the interviewer gave me a third question as a bar raiser. I wrote my solution on a Google Doc, treating it like a whiteboard, and walked through test cases to explain my logic.

  3. 3

    System Design60 min

    Design the BookMyShow system focusing on search, seat availability, and third-party APIs (e.g., PVR). I began by listing out the functional and non-functional requirements to set the scope. Then I worked on designing the database schema, API endpoints, and a rough system flow. My main focus was on covering the core features like ticket search and booking. Where I Struggled:

    • Couldn’t properly design interaction with external vendors
    • Missed edge cases in seat availability updates, locking mechanisms, and caching
    • Went straight to ElasticSearch instead of a SQL-first approach
    • Was unsure how to reduce frequent hits to PVR’s API, or sync bookings across multiple platforms
    • Schema for events/movies wasn’t scalable, opted for parallel design without clear justification
  4. 4

    System Design Re-evaluation75 min

    Same BookMyShow design with a focus on refining previous mistakes.

    • What’s the first API call when user lands on the page? What does the response look like?
    • How would you design schema for events vs. movies vs. shows?
    • Can existing schema support all use cases, or do we need parallel schemas?
    • How to minimize API calls to external ticket partners like PVR?
    • How to sync real-time bookings from other platforms into your system?
    • What to do with a SeatAvailability table that grows huge for every show? Approach: Improved over previous round, but still failed to answer key parts like real-time sync and optimal schema Design was somewhat improved, but still lacked scalability in schema and clarity on third-party integrations

What came up

MediumRemote2 3 years

A candidate-reported account, lightly edited. Interview processes change by team and date.

Sources