Nykaa-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Beauty and personal-care retail carries a constraint most e-commerce does not: products expire. Inventory is held in batches with manufacture and expiry dates, allocation should consume the oldest usable batch first, and anything past a shelf-life threshold cannot be shipped at all. Machine coding rounds in the style of Nykaa frequently build on that batch-aware inventory, which is a meaningfully harder allocation problem than a single stock counter.
The second distinctive layer is offer complexity: free gifts above a cart threshold, sachets and samples added automatically, buy-two-get-one within a brand, and loyalty tiers that change eligibility. This page covers the format, the evaluation lens, and Gronex repositories that train the same allocation and offer mechanics.
What a Nykaa-style machine coding round looks like
A typical statement is an inventory-and-offer slice: receive stock as batches with expiry dates, allocate to orders using a stated policy (usually first-expiry-first-out), block allocation from batches within N days of expiry, and apply cart-level offers including automatic free gifts. Every rule is checkable, and most candidates lose points on the allocation policy rather than the offers.
Batch allocation is an interval-free but ordering-heavy problem. An order for six units may need to span two batches, the split must be recorded so a return knows which batch to restock, and the near-expiry block must be applied before ordering rather than after. A single quantity-per-product counter makes every one of those impossible, so the modelling decision is the round’s first real fork.
Offers then test rule composition. A free gift is not a discount — it is a line item with zero price that must respect its own stock, and it must be removed if the cart falls below the threshold after an item is deleted. That recalculation-on-change behaviour is the standard probe: a design that applies offers once at checkout gives the wrong answer, and a design that recomputes from the cart state gives the right one for free.
How you’re evaluated
Batch-aware allocation
First-expiry-first-out across batches, multi-batch splits recorded, and near-expiry stock excluded before ordering.
Offers as recomputation
Cart offers derived from current cart state on every change, so removing an item removes the gift it qualified for.
Gift and sample stock
Free items treated as real inventory with their own availability, not as unlimited zero-priced lines.
Return-to-batch integrity
A returned unit restocked to the batch it came from, preserving expiry truth rather than inflating a generic count.
Common mistakes that fail this round
- Holding one quantity per product, which makes expiry rules and multi-batch splits unrepresentable.
- Filtering near-expiry batches after sorting and allocating, so blocked stock still gets consumed.
- Applying offers once at checkout instead of recomputing when the cart changes.
- Adding free gifts without checking gift stock, producing orders that cannot be fulfilled.
- Restocking returns into a generic pool, silently resurrecting expired inventory.
Quick tips for the room
- Make the batch, not the product, the unit of stock.
- Return the batch split from allocation so returns can reverse it.
- Recompute offers on every cart change, never once at checkout.
- Treat free gifts as stock-checked line items priced at zero.
How to prepare
Implement batches as the unit of stock from the first data structure, with an allocate(productId, quantity) that returns the batch split it used. Then build offers as a pure function from cart contents to applicable offers, and call it on every cart mutation. Those two shapes handle almost everything the round asks.
The repositories below are the same mechanics with failing tests: the PO receiving problem is batch intake with tolerance rules, the stock reservation problem is the reserve-release-commit core, the coupon engine is offer eligibility and stacking, the loyalty problem is tiers and expiring points, and the free overselling problem is the concurrency failure under all of it.
Practice problems in the Nykaa-style round format
Each is a real backend repository with a failing test suite — the same working-code standard the round applies. Open the brief and read the full problem, no signup required.
PO Receiving & Three-Way Match
The intake side: cumulative receipts against a purchase order, over-receipt tolerance, and invoice matching.
Open the challenge →Inventory Stock Reservation System
Reserve, release, and commit with on-hand, reserved, and available kept consistent through every operation.
Open the challenge →Coupon Application Engine
Offer eligibility, thresholds, stacking, and caps — recomputed against the cart, redeemed exactly once.
Open the challenge →Loyalty Points & Tier Management
Tiers and expiring points: FIFO expiry, oldest-first redemption, idempotent earn events.
Open the challenge →Inventory Overselling Under Concurrency
Two orders, one last unit: diagnose the race at the database layer and fix it properly. Free to try.
Open the challenge →FAQ
Are these actual Nykaa interview questions?
No. They are Gronex originals in the style of beauty and personal-care retail rounds — the kind of problem asked in rounds like Nykaa’s. Gronex is not affiliated with Nykaa.
Is batch and expiry handling really asked?
It is the natural differentiator for the domain, and rounds built around it are common enough that arriving with the model ready is worth the preparation. Even where the statement omits expiry, batch-shaped stock costs nothing and answers the follow-up.
What is first-expiry-first-out?
Allocating from the batch that expires soonest among those still eligible to ship. It is a sort plus a filter, but the ordering of the two matters — filter the ineligible batches first, then sort by expiry.
How do free gifts change the cart design?
They force offers to be recomputed rather than applied. Because a gift can appear and disappear as the cart changes, the only clean design is a function from cart state to offer lines, called on every mutation.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Nykaa. All company names and trademarks belong to their respective owners. The problems on this page are Gronex originals written in the style of such interview rounds — not actual interview questions from Nykaa.