Groww-Style Machine Coding Round: Format, Tips & Practice Problems
Investment platforms carry a specific engineering burden: user money enters, converts into orders and holdings, and every paisa of that journey must be exact, auditable, and invisible to every other user. Machine coding rounds in the style of Groww draw from this world — order lifecycles, scheduled SIP executions, portfolio ledgers, and the strict account isolation a financial product cannot compromise on.
What gives these rounds their texture is that the domain combines fintech correctness with time. An order moves through placed → executed → settled while cancellation races execution; an SIP must fire on schedule, exactly once, even when the scheduler restarts; a ledger must explain today’s holdings from the full history of transactions. This page covers the commonly reported format, the grading lens, and Gronex repository problems in the same style.
What a Groww-style machine coding round looks like
Expect roughly 90–120 minutes to build one slice of an investing backend: an order service (place, cancel, execute, settle — with cancellation legal only before execution), a portfolio tracker (transactions in, holdings and average price out), an SIP scheduler (recurring orders that fire on due dates, exactly once), or a funds-and-balance service backing all of them. Specs state financial rules exactly and expect them enforced exactly.
The order lifecycle is the classic core. It is a state machine with a race in the middle: the user cancels while execution is in flight, and exactly one of those must win — a cancelled order must never also execute. Rounds in this style probe that transition specifically, along with idempotent execution (the same fill event applied twice must not double the holding) and the arithmetic of average buy price, which candidates get wrong under partial fills more often than any other calculation.
The SIP flavour turns the round into a scheduling problem: due dates computed correctly across months, an execution that must be exactly-once per due date even across restarts and retries, and skipped-versus-failed executions kept distinct. Whichever variant appears, expect an account-isolation requirement stated or implied — one user’s orders, holdings, and balances must be unreachable from another’s session — and expect the review to check it.
How you’re evaluated
Order lifecycle correctness
Legal transitions only, cancellation racing execution resolved to exactly one winner, and terminal states that stay terminal.
Ledger-grade accounting
Holdings, balances, and average prices derived from an append-only transaction history that reconciles after any sequence — including partial fills.
Exactly-once scheduled execution
An SIP or scheduled order fires once per due date, survives restarts and retries without double-buying, and records skips distinctly from failures.
Account isolation
Every query and mutation scoped to the owning account — cross-user visibility of orders or holdings is an automatic red flag in a financial product.
Common mistakes that fail this round
- Letting a cancel and an execution both succeed because the check and the transition are separate steps.
- Recomputing average buy price with float division, then failing the exact-value assertions on partial fills.
- Storing holdings as mutable totals with no transaction history, so the audit question has no answer.
- An SIP scheduler that fires on "date >= due" every run, double-executing after a restart.
- Fetching orders by order-id alone with no ownership check — the isolation leak found in the first review pass.
Quick tips for the room
- Write the order transition table first; mark which transitions race and guard those atomically.
- Derive holdings from transactions — never store what you can replay.
- Key every scheduled execution by (account, instrument, due date) so retries collapse into one.
- Scope every repository method by account id from the first line of code.
How to prepare
Drill the order state machine with its signature race: one transition function, cancel-versus-execute resolved atomically, and idempotent fills. Then drill the portfolio arithmetic — average price under partial fills and multiple buys, in integer paise — because it is the calculation this round style checks to the exact value.
The repositories below cover the round’s spread: the auction problem is the closest match for race-safe order placement against a closing event; the bank-transfer and wallet problems are the funds-movement core; the distributed scheduler is the SIP question in its full exactly-once form; and the authorization-leak drill is account isolation as a failing test. The validation drill (free) warms up the request-hygiene muscle the domain assumes.
Practice problems in the Groww-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.
Auction Bid Placement & Closing
The order-placement race in essence: concurrent submissions against a terminal closing event, exactly one winner.
Open the challenge →Bank Transfer & Deadlock Prevention
Funds movement under concurrency: atomic transfers, deadlock-free lock ordering, and balance invariants.
Open the challenge →Wallet Transaction & Refund System
The user-funds ledger: idempotent credits and debits, refund caps, and balances that always reconcile.
Open the challenge →Distributed Job Scheduler
The SIP question at full strength: scheduled work that executes exactly once even when workers race and crash.
Open the challenge →API Debugging: Authorization Leak
Account isolation as a drill: fix an IDOR so no user can read another’s accounts or transactions.
Open the challenge →API Debugging: Validation & Error Envelope
Request hygiene for a financial API: reject bad input with a consistent error contract. Free to try.
Open the challenge →FAQ
Were these problems actually asked at Groww?
No. Every problem here is a Gronex original in the same style — order lifecycles, ledgers, scheduling, and isolation with working-code grading. We never republish any company’s actual interview questions, and Gronex is not affiliated with Groww.
Do I need to understand stock markets to pass this round style?
No. The financial rules — when cancellation is legal, how average price is defined, when an SIP fires — are stated in the problem. What the domain sets is the standard: exact arithmetic, auditable history, and zero tolerance for cross-account leakage, all of which are testable engineering skills.
What is the most probed edge case in the order-lifecycle variant?
Cancel racing execute. Both operations find the order in an executable state; exactly one may win, and the loser must get a clean, specific rejection. If your design checks state and then transitions in two separate steps, this is where it breaks — and where the follow-up questions go.
How is a Groww-style round different from a generic fintech round?
The wallet-grade invariants carry over, but investing adds time and lifecycle: scheduled executions that must be exactly-once per due date, orders whose legality depends on their current state, and portfolio math derived from history. Expect state machines and clocks, not just ledgers.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Groww. 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 Groww.