Zerodha-Style Machine Coding Round: Format, Tips & Practice Problems
Zerodha occupies an unusual place in Indian engineering lore: a bootstrapped broker famous for running enormous trading volumes on a deliberately small team that builds and operates almost everything itself. Interview rounds in this style select for that culture — engineers who write correct concurrent code, respect hard limits, and can debug a misbehaving system without a platform team to call.
That translates into a distinctive machine coding round. The domains are trading-shaped — order placement under contention, rate-limited APIs, market-hours state — but the grading leans operational: does your code behave under load, does it fail loudly and specifically, could the person who wrote it also run it at 9:15 a.m. when the market opens? This page covers the format as commonly reported for rounds in this style, the evaluation lens, and Gronex problems that train the same muscles.
What a Zerodha-style machine coding round looks like
Expect a focused build, typically 90–120 minutes, with a spec that is small and sharp: an order-placement service where concurrent submissions race a cutoff (market close, circuit limit, or auction end); a rate limiter enforcing per-client quotas the way a broker API enforces its per-second limits; or a queue-and-worker slice processing order events exactly once. The problems are narrower than e-commerce rounds and drilled deeper.
Concurrency is graded as a first-class requirement, not a discussion topic. The signature scenario is a burst of simultaneous operations against a shared resource with a hard boundary — the last acceptable order before close, the last request inside a rate window — where the correct answer is an atomic check-and-act and the wrong answer is any interleaving that lets one through after the boundary. Expect the reviewer to reason through your interleavings line by line, and expect a deadlock question if your design ever holds two locks.
The operational flavour shows up as a debugging component: given logs or a failing behaviour — a worker wedged on a poison message, a service that hangs because a timeout is missing — find the cause and fix it. Rounds in this style are also reported to care about frugality: standard library over frameworks, an in-memory build that could be explained to the person operating it, and honest, specific error handling throughout.
How you’re evaluated
Correctness under contention
Racing operations against a shared limit or cutoff resolve exactly — no request slips past a boundary, no deadlock when locks compose.
Hard limits enforced exactly
Rate windows, quotas, and cutoffs behave at their edges: request N passes, request N+1 is rejected with a specific error, and the boundary is atomic.
Operational debuggability
You can read logs, localise a fault, and fix it surgically — and the code you write is diagnosable in the same way: specific errors, no swallowed failures.
Self-sufficient simplicity
A small, dependency-light solution you fully understand beats a framework-assembled one you half do. Explaining every moving part is part of the grade.
Common mistakes that fail this round
- Checking a limit and then acting on it in two steps, so a racing request slips through the boundary.
- One global lock over all clients and instruments — correct, and an instant conversation about why everything serialises.
- Acquiring locks in inconsistent order across code paths, then hanging the reviewer’s deadlock test.
- Swallowing exceptions into generic failures, making the debugging half of the round impossible on your own code.
- Reaching for a heavy framework when the spec fits in a few hundred lines of standard library.
Quick tips for the room
- Name the shared resource and its boundary first; that sentence is your design.
- Make check-and-act one atomic step everywhere a limit exists.
- Pick one global lock order and write it down before coding.
- Prefer the standard library; be ready to justify every dependency you add.
How to prepare
Train concurrency at the boundary: the rate limiter and the racing-cutoff problem are the two katas that match this round style, and both punish check-then-act designs precisely the way a reviewer will. Practise stating your critical sections out loud — what is atomic, what is protected by which lock, and in what order locks are ever taken.
Then train the operational half deliberately, because most candidates never do: the incident-debugging repositories below hand you logs and a broken service, exactly like the fix-it component of an ops-minded round. Start with the crash-loop drill (free), then the deadlock incident — reading a thread dump and fixing lock ordering is the single most Zerodha-shaped exercise on this list.
Practice problems in the Zerodha-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
Racing submissions against a hard cutoff: per-auction critical sections and a close that wins every interleaving.
Open the challenge →API Rate Limiter & Quota Enforcement
Broker-API discipline: per-client budgets enforced atomically at the window edges under concurrent requests.
Open the challenge →Bank Transfer & Deadlock Prevention
The two-lock classic: atomic transfers with stable lock ordering so opposing operations never deadlock.
Open the challenge →Incident Debugging: Lock-Ordering Deadlock
The ops half of the round: read the evidence of a wedged service and fix the inconsistent lock order that caused it.
Open the challenge →Incident Debugging: Crash Loop
Logs-first debugging: trace a crash-looping service to its config fault and fix it surgically. Free to try.
Open the challenge →FAQ
Were these problems actually asked at Zerodha?
No. Every problem here is a Gronex original built in the same style — trading-grade concurrency, hard limits, and operational debugging. We never republish any company’s actual interview questions, and Gronex is not affiliated with Zerodha.
What makes a Zerodha-style round different from other fintech rounds?
The operational lens. Wallet-style rounds grade ledger correctness; this style also grades whether you could run what you build — debugging from logs, exact behaviour at rate and time boundaries, and small, dependency-light designs you can fully explain. The incident-debugging drills exist for exactly this half.
How deep does the concurrency questioning go?
Deeper than most rounds: expect your interleavings traced line by line, a deadlock question the moment two locks exist, and boundary tests at N and N+1 of any limit. Practising problems whose test suites actually race threads — rather than discussing concurrency abstractly — is the honest preparation.
Does language choice matter for this style?
Use what you are sharpest in — the concurrency reasoning transfers. Gronex repositories run the same racing test suites in Java, Python, and C++, so you can practise the atomicity and lock-ordering patterns in the language you will interview with.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Zerodha. 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 Zerodha.