Lenskart-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Eyewear retail is an unusually rich backend domain because the product is configured, not picked. A frame plus a lens type plus a prescription plus coatings becomes a made-to-order item, and the order then has to be routed to whichever store or lab can actually produce it. Machine coding rounds in the style of Lenskart draw on that configuration-and-routing pair.
The omnichannel half adds a second dimension: stock exists in many stores and a warehouse, customers book in-store eye tests, and a home try-on is a loan of physical inventory that must come back. This page covers the reported format, what evaluators weight, and Gronex repositories that train the same configuration, slot, and routing mechanics.
What a Lenskart-style machine coding round looks like
A common statement is a configured-order slice: build an order from a frame and a lens option set where options constrain each other (a lens index is only available for some power ranges, a coating only for some lens types), validate a prescription, price the configuration, and route it for fulfilment. An alternative statement is store appointment booking with optometrist availability, which is an interval problem with capacity per store.
Option compatibility is the part that distinguishes this round. The clean design is a compatibility rule set evaluated against the chosen configuration, so an invalid combination is rejected with the specific incompatible pair named. A chain of conditionals covering the initial options passes the first demo and collapses on the inevitable follow-up — "now this coating is unavailable for high-index lenses" — which is exactly why the rules should be data.
Fulfilment routing is the second half: given stock across stores and a lab capability, choose where the order is made and shipped from, with a stated policy such as nearest store holding all components, otherwise split, otherwise warehouse. The probes are a split shipment, a store that has the frame but not the lens, and cancellation after one leg has shipped — where partial reversal has to be expressible.
How you’re evaluated
Configuration validity as rules
Option compatibility held as an evaluated rule set that names the offending combination, extendable without touching pricing.
Prescription validation
Range and format checks applied before any pricing or routing, with specific errors per invalid field.
Multi-location fulfilment
A stated routing policy over per-location stock, with splits represented explicitly rather than implied.
Partial cancellation
Cancelling an order where one leg has shipped reverses only what can be reversed, and says so.
Common mistakes that fail this round
- Encoding option compatibility as nested conditionals, so the added rule in the follow-up requires a rewrite.
- Pricing the configuration before validating it, producing quotes for combinations that cannot be made.
- Keeping a single global stock number with no location dimension, which makes routing meaningless.
- Treating a split shipment as two unrelated orders, losing the customer-facing single-order view.
- Allowing full cancellation after partial dispatch because the order had one status and no line-level state.
Quick tips for the room
- Hold option compatibility as data; return all violations, not the first.
- Validate the prescription before pricing or routing anything.
- Give stock a location from the first data structure.
- Track status per order line so partial dispatch is expressible.
How to prepare
Model the order line as a configuration object and write the compatibility rules as data with a validator that returns every violation, not the first. Then give stock a location dimension and implement one routing policy with an explicit split representation. Practise the cancel-after-partial-dispatch conversation; it is the standard closing question.
The repositories below map the pieces: the stock reservation problem is per-location inventory discipline, the shared-calendar problem is store appointment booking, the coupon engine is configuration-dependent pricing rules, the RMA problem is returns on a made-to-order item, and the free seat-reservation problem is the claim-and-release baseline for try-on inventory.
Practice problems in the Lenskart-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 stock consistently — the per-location core that routing depends on.
Open the challenge →Shared Calendar Slot Booking
Store appointment booking: overlap rules, per-resource availability, and no double-booking under contention.
Open the challenge →Coupon Application Engine
Rule-driven pricing: eligibility, stacking, and caps computed against a configured cart.
Open the challenge →Return Authorization & Restock
Returns on a made-to-order item: window checks, quality gating, and atomic refund-plus-restock.
Open the challenge →Seat Reservation System
Claim-and-release mechanics for loaned inventory: reserve, cancel, list availability. Free to try.
Open the challenge →FAQ
Were these problems asked at Lenskart?
No. They are Gronex originals in the style of omnichannel retail rounds — the kind of problem asked in rounds like Lenskart’s. Gronex is not affiliated with Lenskart.
Why are configured products harder than normal SKUs?
Because validity is a relation, not a property. Two individually valid options can be jointly invalid, which means you need a rule set and a validator rather than field checks — and that is precisely what the follow-up question tests.
Do I need real store or lab data?
No. Two or three locations with per-location stock and a supplied distance are plenty to demonstrate a routing policy. The policy and the split representation are what get graded.
What is the most common structural mistake?
One status on the order. As soon as an order can be split across locations or partially dispatched, status has to live on the line or shipment, and retrofitting that mid-round is expensive.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Lenskart. 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 Lenskart.