Udaan-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
B2B commerce looks like retail commerce until you read the pricing rules. Quantities come in lots, prices fall in slabs as volume rises, a buyer has negotiated rates that override the list, and payment is on credit terms against a limit rather than a card. Machine coding rounds in the style of Udaan use that pricing-and-credit machinery, which makes them a genuinely different exercise from consumer checkout rounds.
The other axis is sourcing: one line item can be filled from several sellers with different prices and lead times, so the order becomes a set of seller-scoped sub-orders. This page covers the reported format, the evaluation lens, and Gronex repositories that drill the same pricing, credit, and allocation mechanics.
What a Udaan-style machine coding round looks like
The usual build is an order-and-pricing slice: price a line item given lot size, slab pricing, and any buyer-specific override; enforce minimum order quantity and lot multiples; check the buyer’s available credit; and split the order across sellers by a stated policy. Statements are dense with rules, and the round is largely a test of whether you implemented the stated precedence exactly.
Pricing precedence is the first fork. Buyer-specific rate, then promotional price, then slab price, then list price is a typical order, and it must be evaluated as an ordered chain with the winning source recorded on the line. Candidates who compute a price without recording which rule produced it cannot answer "why is this ₹412 a unit?" — a question this round asks in almost exactly those words.
Credit turns the order into a money-safety problem. Available credit is the limit minus outstanding invoices minus orders in flight, so placing an order must reserve credit atomically and release it on cancellation or rejection. Two orders racing the same remaining credit is the guaranteed probe, and the expected answer is the same atomic check-and-reserve that inventory problems require.
How you’re evaluated
Ordered pricing resolution
A precedence chain evaluated in the stated order, with the winning rule recorded per line so any price is explainable.
Lot and MOQ enforcement
Quantities validated as lot multiples above the minimum, with rejection messages that state the required value.
Atomic credit reservation
Available credit derived from limit, outstanding, and in-flight orders, reserved and released in one operation each.
Multi-seller splitting
Line items allocated across sellers by a stated policy, with per-sub-order status so partial fulfilment is expressible.
Common mistakes that fail this round
- Computing the price without recording which rule won, leaving every pricing question unanswerable.
- Applying slab pricing per line instead of per aggregated quantity when the statement says otherwise.
- Checking credit then reserving it in two steps, which lets two orders exceed the limit together.
- Rounding a per-unit price and multiplying, instead of computing the line total under the stated rule.
- Splitting across sellers but keeping one order status, so a partially shipped order has no representation.
Quick tips for the room
- Return price plus source from your resolver; record both on the line.
- Derive available credit; never store it as its own field.
- Validate lot multiples before pricing anything.
- Give each seller sub-order its own status from the first model.
How to prepare
Implement the pricing resolver as an ordered list of rule objects returning a price and its source, and test the precedence explicitly. Then derive available credit and make reserve-credit atomic. Finally split an order across two sellers with per-sub-order status. Building in that order means the highest-weight rubric items are demoed first.
The repositories below map the mechanics: the coupon engine is rule precedence and caps, the escrow problem is reserved money released exactly once, the PO receiving problem is B2B intake with tolerance, the stock reservation problem is per-seller availability, and the free overselling problem is the race that credit and inventory share.
Practice problems in the Udaan-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.
Pricing Rule Engine
Rule precedence made concrete: eligibility, stacking order, caps, and a total that reconciles line by line.
Open the challenge →Escrow Hold & Release
The credit-reservation pattern in money form: held amounts released exactly once, guarded at terminal states.
Open the challenge →PO Receiving & Three-Way Match
B2B intake mechanics: cumulative receipts, over-receipt tolerance, and PO-receipt-invoice matching.
Open the challenge →Inventory Stock Reservation System
Per-seller availability with reserve, release, and commit kept consistent under every operation.
Open the challenge →Overselling Under Concurrency
The check-then-reserve race at the database layer — the same bug credit limits have. Free to try.
Open the challenge →FAQ
Are these real Udaan interview questions?
No. They are Gronex originals in the style of B2B commerce rounds — the kind of problem asked in rounds like Udaan’s. Gronex is not affiliated with Udaan.
Why is pricing harder in B2B?
Because several rules can apply at once and the order between them is contractual. That makes pricing a resolution problem with an audit requirement, rather than a lookup — and the audit requirement is what most candidates omit.
How much credit logic should I build?
Enough to derive available credit and reserve it atomically. Invoice ageing and collections are discussion material; the reservation race is what gets tested in code.
Is multi-seller splitting always part of it?
Not always, but it is the most common extension, and the cost of preparing for it is one design decision: per-sub-order status instead of a single order status. Make that choice early and the extension is nearly free.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Udaan. 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 Udaan.