Upstox-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Discount broking platforms take their heaviest load in short, violent bursts: the market opens and every client places, modifies, and cancels at once while a tick feed fans out to hundreds of thousands of subscribers. Machine coding rounds in the style of Upstox draw on that pressure, which shifts the emphasis from business rules toward throughput, ordering, and shedding load honestly.
The scenarios still look like ordinary services — an order API, a subscription fan-out, a quota enforcer — but the qualifiers are about behaviour at the limit: what your code does when the queue grows faster than it drains, when a client sends the same order twice in 50ms, or when one slow subscriber holds up a broadcast. This page covers the format, the grading lens, and Gronex repositories in the same style.
What a Upstox-style machine coding round looks like
A representative statement is an order-intake service with a per-client rate limit and idempotent placement, or a market-data distribution component where subscribers receive ticks for their watchlists. Requirements read operationally: no client may exceed N requests per second, a duplicate client order id must not create a second order, and a slow consumer must not degrade the others.
Rate limiting is graded on correctness rather than cleverness. A fixed window that lets double the limit through at the boundary is the classic trap; a sliding window or token bucket with a declared refill rule, and per-key state that stays correct when several threads check it simultaneously, is the expected answer. Interviewers ask what happens at the window edge because that is where the naive version fails.
The fan-out half brings backpressure. Bounded per-subscriber queues with a stated drop policy — drop oldest for ticks, since a stale price is worthless — is a strong answer; an unbounded queue is the memory-exhaustion failure the question exists to find. Expect a follow-up on ordering: ticks for a single symbol must stay in sequence even when workers process in parallel, which is where per-key partitioning gets discussed.
How you’re evaluated
Correct limiting at the boundary
Sliding-window or token-bucket semantics that do not admit a double burst at the window edge, with per-key state safe under concurrent checks.
Idempotent order intake
A client-supplied order id that makes a rapid double-submit produce exactly one order and one response.
Backpressure with a policy
Bounded queues and an explicit, defended drop or block policy — never unbounded buffering.
Per-key ordering
Updates for one symbol or account stay in order under parallel processing, via partitioning rather than hope.
Common mistakes that fail this round
- A fixed-window counter that allows twice the limit across the boundary, then defending it as "close enough".
- Deduplicating orders by comparing fields instead of the client order id the API already provides.
- Unbounded subscriber queues, which convert a slow consumer into an out-of-memory failure.
- Round-robin dispatch across workers, which reorders updates for the same symbol.
- Holding one global lock over the whole limiter, turning the hot path into a convoy.
Quick tips for the room
- Name your limiter algorithm and its boundary behaviour before coding it.
- Keep limiter state per key and lock per key, not globally.
- Bound every queue and state the drop policy in the README.
- Partition by symbol or account id to keep ordering without global locks.
How to prepare
Implement a token bucket and a sliding window from scratch, then write the boundary test that distinguishes them from a fixed window. Next build a bounded fan-out with a drop-oldest policy and a per-key worker assignment, and be ready to say in one sentence why partitioning by symbol preserves order. Those two artefacts answer most of what this round style probes.
The repositories below are the same material with failing tests: the rate-limiter problem is the quota core, its sliding-window extension is the boundary fix, the queue-consumer problem is retry and dead-lettering, the slow-subscriber problem is head-of-line blocking in a broadcast, and the parallel-consumer problem is the per-key ordering failure made concrete.
Practice problems in the Upstox-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.
Rate Limiter & Quota Enforcement
Per-client limits that hold under concurrent checks, with quota accounting and correct window behaviour.
Open the challenge →Rate Limiter: Sliding Window & Tiers
The boundary-burst fix as a focused extension: sliding-window counting and per-tier limits.
Open the challenge →One Slow Consumer Stalls Every Other
Market-data fan-out failure: head-of-line blocking, and the bounded-queue policy that fixes it.
Open the challenge →Updates Land Out of Order Under Load
Why parallel workers reorder per-key updates, and how partitioning restores sequence.
Open the challenge →Duplicate Effects After a Restart
The double-submit problem in its cleanest form: one effect from at-least-once delivery. Free to try.
Open the challenge →FAQ
Were these problems asked at Upstox?
No. They are Gronex originals in the style of high-throughput broking rounds — the kind of problem asked in rounds like Upstox’s. Gronex is not affiliated with Upstox.
Do I need to build multithreaded code in the round?
More often than in a typical machine coding round, yes — at least a limiter that is correct under concurrent checks. Even where the build stays single-threaded, the contention question is asked directly.
What is the most common rate-limiter mistake?
The fixed-window boundary burst: with a limit of 100 per minute, a client sends 100 at 00:59 and 100 at 01:00. Naming that failure before the interviewer does is a strong signal.
How is this different from a general broking round?
A broking round centred on risk and margin grades accounting discipline. A throughput-centred round grades what happens at the limit — limiter correctness, backpressure, and ordering — so bring an answer for each.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Upstox. 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 Upstox.