Myntra-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Fashion commerce has a structural quirk that changes its backend: the thing customers browse is not the thing you hold stock of. A style has colours, a colour has sizes, and only the size-level SKU has inventory — while pricing, offers, and ratings often live at the style level. Machine coding rounds in the style of Myntra lean on that hierarchy, and it is a genuinely different modelling problem from single-SKU commerce.
The other domain fact is return volume: fashion returns are routine, and exchanges are a return and a new order that must not leave the customer paying twice or the warehouse short. This page covers the commonly reported format, the evaluation lens, and Gronex repositories built on the same variant, sale-event, and returns mechanics.
What a Myntra-style machine coding round looks like
A representative statement asks for a catalog-and-cart slice: products with variant axes, size-level stock, add-to-cart with a variant selection, and a checkout that applies offers. Or a returns slice: initiate a return within a window, choose refund or exchange, and restock only if the item passes quality check. The requirements always include at least one rule that only makes sense at the variant level, which is the hook.
The variant hierarchy is graded on whether stock and price live at the right level. A price at the SKU level with an optional style-level override, stock only at the SKU level, and availability at the style level derived as "any variant in stock" is the shape that survives questions. Flattening everything into one product entity makes the size-out-of-stock case and the style-level listing both awkward, and the reviewer will ask for exactly those.
Sale events add the concurrency pressure. A discount window that opens at a fixed time, a per-customer purchase cap, and stock that must not oversell during the rush are the standard trio. Reservation at cart or at order placement is a design choice you will be asked to defend — including what happens to a reserved item when the cart is abandoned, which is where an expiry and a release path become necessary rather than optional.
How you’re evaluated
Correct variant modelling
Style, colour, and size as a hierarchy with stock at the SKU level and availability derived upward — not one flattened product row.
Reservation with expiry
Stock held at a defined moment, released on abandonment or cancellation, and never oversold during a sale window.
Offer stacking rules
Coupons and sale prices combined in a stated precedence with caps applied, producing a total that reconciles line by line.
Return and exchange integrity
Window checks, quality-gated restock, and exchanges that move money and stock once each — never twice, never zero times.
Common mistakes that fail this round
- Treating the product as a single entity with a size field, then having no place to put size-level stock.
- Reserving stock at cart addition with no expiry, so abandoned carts permanently consume inventory.
- Applying coupon and sale discounts in an undeclared order and producing a total the itemisation cannot explain.
- Restocking a return before the quality check, which the statement almost always forbids.
- Modelling an exchange as a mutation of the original order, losing the audit trail the refund depends on.
Quick tips for the room
- Decide the variant hierarchy in the first five minutes and write it down.
- Keep stock only at the SKU level; derive style availability.
- Give every reservation an expiry and one release path.
- State your discount precedence before implementing the total.
How to prepare
Build the style-colour-size hierarchy and a listing that derives availability from it, then implement reserve-with-expiry and a release path. Afterwards, do one returns flow with a quality gate and an exchange. Ordering matters: the hierarchy decision constrains everything else, so making it badly costs the whole hour.
The repositories below cover the pipeline: the stock reservation problem is the variant-level inventory core, the flash-sale problem is the sale-event race, the coupon engine is offer stacking with caps, the RMA problem is returns with quality-gated restock, and the free overselling problem is the same inventory bug seen from the database side.
Practice problems in the Myntra-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.
Inventory Stock Reservation System
Reserve, release, and commit at the SKU level with the three quantities kept consistent throughout.
Open the challenge →Flash Sale Inventory Purchase
The sale-event race: sell exactly the stock you have when thousands of buyers hit one SKU at once.
Open the challenge →Coupon Application Engine
Eligibility, stacking precedence, caps, and idempotent redemption in a checkout backend.
Open the challenge →Return Authorization & Restock
Returns done right: window checks, non-skippable transitions, and atomic refund-plus-restock.
Open the challenge →Inventory Overselling Under Concurrency
The same oversell bug at the database layer: find it, then fix it with the right locking. Free to try.
Open the challenge →FAQ
Were these problems asked at Myntra?
No. Every problem is a Gronex original in the style of fashion-commerce rounds — the kind of problem asked in rounds like Myntra’s. Gronex is not affiliated with Myntra.
How deep should the variant model go?
Two axes are enough to demonstrate the idea — colour and size — provided stock sits at the leaf and availability is derived upward. Building an arbitrary attribute system is over-engineering that costs you the returns flow.
Cart-level or order-level reservation?
Either is defensible if you can state the trade-off: cart-level protects the customer’s experience but needs expiry and release; order-level is simpler but oversells during a rush. Rounds in this style care about the reasoning and the release path.
How is this different from a general e-commerce round?
The variant hierarchy and the returns volume. A single-SKU commerce round never forces the style-versus-SKU decision, and it rarely spends time on exchanges — both of which are where fashion-domain rounds probe.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Myntra. 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 Myntra.