Meesho-Style Machine Coding Round: Format, Tips & Practice Problems
Social commerce runs on two engines: millions of independent sellers managing catalogs, and an engagement machine — notifications, deals, referrals — that brings buyers back daily. Machine coding rounds in the style of Meesho and similar marketplaces draw their problems from both, which gives them a different texture from inventory-centric e-commerce rounds.
Expect scenarios about catalog and listing workflows, per-seller isolation, notification preferences and delivery, and referral or reward attribution. The recurring hidden requirement is multi-tenancy: whatever you build must behave as if thousands of sellers or users share it without ever seeing each other’s data. This page covers the format, grading criteria, and Gronex problems in the same style.
What a Meesho-style machine coding round looks like
The round is typically 90–120 minutes to build one slice: a seller catalog service (create listings, update prices, publish/unpublish with versioning), a notification system (user channel preferences, quiet hours, deduplicated delivery), or a referral engine (attribution windows, one reward per referee, self-referral prevention). Statements read simply; the grading lives in the qualifiers — "a seller must never see another seller’s drafts", "a user must not be notified twice for the same event".
Catalog problems are workflow-and-versioning problems in disguise: edits create versions, publishing is a state transition, rollback must preserve history, and two concurrent edits must not silently overwrite each other — optimistic locking with a version check is the expected answer. Engagement problems are idempotency problems in disguise: notification sends and reward grants are retried by infrastructure, and "at most once per event" has to be enforced by your code, not hoped for.
Scale questions arrive in the discussion phase shaped by the domain: what changes when a price update fans out to a million followers, how deals stay consistent when applied per-cohort, how you would shard per-seller state. You are not expected to build any of that in the round — you are expected to have built seams that make the conversation credible.
How you’re evaluated
Tenant isolation
Every query and mutation scoped to the owning seller or user — cross-tenant leakage is an automatic red flag, even in an in-memory build.
Versioned workflows
Catalog edits produce immutable versions with correct publish/rollback transitions and optimistic-concurrency protection against lost updates.
Idempotent engagement
Notifications and rewards fire at most once per event, honour user preferences and quiet hours, and survive redelivery.
Attribution correctness
Referral rules enforced exactly: valid windows, one reward per referee, and the fraud edges (self-referral, recycled accounts) closed.
Common mistakes that fail this round
- Global lookups with the tenant filter applied "later" — the leak is found in the first review pass.
- Updating listings in place, making rollback and concurrent-edit questions unanswerable.
- Sending notifications inline with the triggering action, so one retry produces duplicate sends.
- Encoding preference rules (channels, quiet hours) as nested ifs that the follow-up requirement immediately breaks.
- Ignoring the fraud edge in referral specs — self-referrals and duplicate qualifying events are always tested.
Quick tips for the room
- Put the tenant id in every repository method signature from the first line.
- Version on write; never mutate a published record in place.
- Derive a dedupe key per (user, event) before writing any send logic.
- Keep preference evaluation in one policy object the follow-up can extend.
How to prepare
Practise the three shapes separately: a versioned document workflow (draft → published, immutable snapshots, optimistic locking), an idempotent delivery pipeline (preferences, quiet hours, dedupe keys), and an attribution engine (windows, once-per-referee, self-referral checks). Each is small alone; the round grades whether you keep tenant scoping airtight while building one of them fast.
The repositories below map one-to-one: the notification system (free) is the engagement round; CMS publishing-and-versioning is the catalog workflow; the referral problem is attribution with its fraud edges; the coupon engine covers deal mechanics; and the multi-tenant API-key problem drills isolation itself — the theme every Meesho-style statement smuggles in.
Practice problems in the Meesho-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.
Notification Preference & Delivery
The engagement round: channel preferences, quiet hours, and idempotent delivery. Free to try.
Open the challenge →Publishing & Versioning Workflow
The catalog workflow in essence: immutable versions, scheduled publishing, rollback, and optimistic concurrency.
Open the challenge →Referral & Reward Attribution
Growth-loop correctness: attribution windows, one reward per referee, self-referral prevention, idempotent events.
Open the challenge →E-Commerce Coupon Application Engine
Deal mechanics: eligibility, stacking, and idempotent redemption in a checkout backend.
Open the challenge →Multi-Tenant API Key & Scope Management
Isolation as the whole problem: tenant boundaries, scope inheritance, rotation grace windows, revocation.
Open the challenge →FAQ
Are these actual Meesho interview questions?
No. Every problem is a Gronex original in the style of social-commerce machine coding rounds — the kind of problem asked in rounds like Meesho’s. Gronex is not affiliated with Meesho.
What makes a marketplace-style round different from a Flipkart-style one?
The rubric is the same — working demo, then design — but the domain shifts from inventory and pricing to seller workflows, engagement, and multi-tenant isolation, so the probed edge cases change: cross-tenant leaks, duplicate notifications, and lost updates instead of oversells.
Do I need to build actual multi-tenancy infrastructure?
No — an in-memory build is fine. What is graded is discipline: tenant-scoped lookups everywhere, no global mutable registries, and the ability to explain how the same boundaries map to real storage.
How should I practise for the engagement-style problems?
Start with the free notification problem above: it encodes preferences, quiet hours, and idempotent delivery as failing tests, which is exactly the checklist an interviewer walks in this round style.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Meesho. 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 Meesho.