How to Pass the BigBasket SDE-2 Machine Coding Round

When you walk into a BigBasket SDE-2 interview, expect the bar for low-level design and machine coding to be exceptionally high. This e-commerce giant handles millions of grocery orders daily. Because of that scale, their engineers have to write code that isn't just functionally correct—it needs to be highly extensible, thread-safe, and cleanly abstracted. Designing a rule-driven coupon and cart pricing engine is one of the most notorious, frequently asked problems in their machine coding round. It directly tests your ability to take ambiguous business requirements and translate them into a robust, object-oriented architecture. And you have to do it all within a tight 90 to 120-minute window. You can't just hack together a massive switch statement and hope for the best. Instead, you need to show a deep understanding of domain modeling and design patterns. Let's break down exactly how to architect a production-ready solution that will actually impress your interviewer.

BigBasket SDE-2 Hiring Process

What are the typical interview rounds for an SDE 2 at BigBasket?

Before we get into the machine coding specifics, you need to understand the overall landscape of the BigBasket SDE-2 interview loop. The entire process is designed to rigorously test both your problem-solving speed and your architectural maturity. For most candidates, the machine coding round is the biggest hurdle. It acts as a strict filter you have to pass before you even get to the high-level system design discussion.

Deconstructing the Machine Coding Round

How do I design a highly extensible grocery cart and coupon engine?

The core problem statement usually sounds something like this: build an in-memory shopping cart system where users can add or remove items, and apply various types of discount coupons. The catch is that these coupons can be percentage-based, flat-rate, or item-specific—think 'Buy 1 Get 1 Free' on apples. On top of that, coupons might be stackable, and the business rules for applying them change frequently. The interviewer is closely watching to see if your design violates the Open-Closed Principle. If adding a new 'Diwali Special' discount requires modifying your core Cart class, you've already failed the round.

How should I structure the core entities for a cart and coupon system?

Your domain model forms the foundation of your entire solution. A surprisingly common mistake candidates make is tightly coupling the pricing logic directly inside the Cart entity. Instead, you have to separate your concerns. You'll need a few primary entities just to represent the state, alongside separate service classes to handle the actual behavior.

• Item: Represents the product catalog entry, storing a unique ID, name, and base price.
• CartItem: A wrapper around the Item object that tracks the specific quantity added by the user.
• Cart: Holds a collection of CartItems and exposes basic methods to add, remove, and update quantities.
• PricingEngine: A dedicated service class responsible for calculating the final total by taking a Cart and a list of applied Coupons.

By decoupling the PricingEngine from the Cart, you guarantee that the Cart only cares about state management. This clean separation of concerns makes unit testing significantly easier down the line. It also keeps your classes strictly focused on a single responsibility, which interviewers love to see.

Which design patterns work best for complex discount rules?

This is exactly where you earn your SDE-2 title. Handling different types of discounts without writing a massive, unmaintainable if-else chain requires the Strategy Pattern. You'll define a DiscountStrategy interface with a single method called 'calculateDiscount' that takes the cart's current state and returns the discount amount. From there, you simply implement your concrete strategies.

• PercentageDiscountStrategy: Calculates a flat percentage off the total cart value up to a specific maximum cap.
• FlatAmountDiscountStrategy: Subtracts a fixed amount while ensuring the total never drops below zero.
• ItemSpecificDiscountStrategy: Iterates through the cart items and applies the discount exclusively to eligible product IDs.

But what happens if the interviewer asks you to support stackable coupons? Imagine a user applies a 10 percent storewide discount AND a flat amount discount. This is where the Decorator Pattern truly shines. You can wrap your base pricing calculator with multiple discount decorators. Each decorator takes the result of the previous calculation, applies its specific rule, and passes the new total down the chain. Doing this makes your pricing engine infinitely extensible without ever modifying the existing code.

How do I handle concurrency and thread safety for in-memory carts?

In a live interview, the proctor will often throw out a scenario like, 'What happens if a user tries to add an item from their mobile app and remove an item from their desktop browser at the exact same time?' Since this is an in-memory machine coding round, you can't rely on a database transaction to save you. You have to implement thread safety directly at the application level.

Using a simple HashMap to store carts by UserID is a guaranteed recipe for a ConcurrentModificationException. You should use a ConcurrentHashMap for your primary storage instead. However, simply throwing in a concurrent collection isn't enough when you have compound actions—like checking if an item exists and then updating its quantity based on that initial check. For operations that modify the state of a specific Cart, you should synchronize on the Cart object itself or use a ReentrantReadWriteLock. A ReadWriteLock lets multiple threads read the cart total simultaneously, yet it ensures exclusive access whenever an item is added or a coupon is applied.

What are the common edge cases and interview curveballs?

Passing the happy path is expected of everyone, but handling the edge cases is what actually gets you the offer. Interviewers love throwing curveballs in the last 20 minutes just to test your code's robustness and your ability to think on your feet.

• Negative Cart Totals: A large flat discount applied to a small cart total should result in a zero total, never a negative one. Your strategy must floor the result at zero.
• Fractional Rounding: When applying a 33 percent discount on an odd number, how do you handle the floating-point math? Always mention using BigDecimal instead of double to prevent precision loss.
• Coupon Ordering: If coupons are stackable, applying a flat discount before a percentage discount yields a completely different total than doing it vice versa. Your engine needs a mechanism to sort coupons by priority before applying them.
• Circular Dependencies: Ensure your decorator chain doesn't accidentally apply the same coupon twice if the user submits a duplicate request.

Communicating Your Solution in the Live Round

Writing good code is only half the battle. You absolutely have to communicate your thought process out loud. While you type out the Strategy and Decorator interfaces, explain exactly why you are choosing them. Say things like, 'I am extracting the discount logic into a strategy interface so that when the marketing team invents a new promotion next month, we only have to add a new class, rather than modifying the existing, tested code.' Speaking like this shows real product sense and architectural maturity. Finally, always leave 10 minutes at the end to write a clean driver class (the main method) that creates a cart, adds items, applies a few complex coupons, and prints the expected output. A working, demonstrable solution is the ultimate proof of your competence.