A candidate I'll call Ankit designed a clean order-book matching engine in his CoinDCX system design round — buy orders, sell orders, a price-time priority queue, a straightforward match-and-settle flow. The interviewer's follow-up: "it's 3am. A major exchange elsewhere just had an outage, and a coin's price on your platform moves 20% in ninety seconds. Ten thousand orders hit your book in that window. Your matching engine has to stay correct — no order matched twice, no balance ever negative, no market halted longer than necessary — with nobody on call awake to fix it by hand. Walk me through what actually happens." Ankit's design worked fine on a stable order book with predictable volume. It hadn't been stress-tested against a market that never closes and can move violently at any hour, with zero tolerance for a ledger mistake.
That's the real shape of CoinDCX interview questions: the DSA and machine-coding rounds are familiar if you've prepped for any fintech-adjacent Indian product company, but the system design round is specifically about a combination most system design prep doesn't cover well — a 24/7 market with no closing bell, extreme price volatility, and a matching engine and wallet ledger that must stay correct under both conditions simultaneously, with real money and no room for reconciliation-by-hand. I built Greenroom after freezing in exactly this kind of interview, where "correct most of the time" isn't an acceptable answer for a ledger. This guide covers the real CoinDCX interview process, the questions that come up, and where 24/7 matching-engine correctness catches people off guard.
The CoinDCX interview process
Candidates report a loop shaped like this:
- Online assessment — DSA problems plus a debugging exercise.
- DSA rounds — arrays, trees, graphs, hash maps, judged on working code.
- Machine coding / low-level design round — a scoped system (order book, wallet) built and extended live under a new constraint.
- System design round — a matching engine and wallet ledger that stay correct through extreme volatility.
- Hiring manager + HR — ownership, project depth, compensation and notice period.
Most reported loops run 4–5 rounds total. The detail that catches candidates off guard: unlike a traditional stock broker with fixed market hours (see our Zerodha guide and Groww guide), a crypto exchange's matching engine and risk systems have to be correct every second of every day, including the exact moments — overnight volatility spikes — when human oversight is thinnest.
DSA and coding questions
Core data structures and algorithms, with a practical, real-time-systems lean:
- Design a data structure for an order book that supports fast insert, cancel, and best-bid/best-ask lookup as orders change continuously.
- Given a stream of trade events, detect wash trading or other manipulation patterns in near real time.
- Implement a price-time priority matching algorithm and explain its complexity under high order volume.
- Design a data structure that supports fast balance lookups and atomic updates across millions of user wallets.
The machine-coding round
A scoped system, built and then extended live when the interviewer adds a new requirement mid-round:
- Design a simplified order-matching engine that matches buy and sell orders by price-time priority.
- Build a wallet-ledger system that debits and credits balances atomically, with no possibility of a negative balance.
- Design a circuit-breaker system that halts trading on a specific coin if its price moves beyond a threshold in a short window.
Interviewers grade correctness and extensibility under a live-changing spec — can your class hierarchy absorb "now also support stop-loss orders" without breaking the core matching invariants.
System design questions — correctness under 24/7 volatility
This is CoinDCX's signature round. Expect design prompts pulled from the real messiness of running a market that never closes, with real money and real volatility:
- Design a matching engine that stays correct and available during a 20% price move in under two minutes, with order volume spiking 10x.
- How would you design a wallet-ledger system that guarantees a user's balance is never double-spent, even under concurrent withdrawal and trade requests?
- Design a circuit-breaker or trading-halt mechanism that protects the platform during extreme volatility without unfairly trapping users mid-trade.
- What happens to your design during a network partition between your matching engine and your ledger service — does the system reject trades safely, or risk a mismatch?
Ankit's mistake wasn't his matching algorithm in isolation — it was assuming steady, predictable volume, when a real crypto exchange has to guarantee the same correctness invariants at 3am during a volatility spike as it does during calm daytime trading, with no market close to catch up during. Our system design interview guide covers the general framework; CoinDCX's version demands you design for correctness under both extreme load and extreme price movement, at any hour, simultaneously.
Behavioral and hiring-manager questions
The hiring manager round leans into ownership and reasoning under high-stakes, always-on pressure:
- Tell me about a time you had to design a system that couldn't have any downtime for maintenance or human intervention.
- Walk me through a project where a ledger or balance mistake would have had serious real-world consequences.
- Describe a time you debugged a production incident that happened outside normal working hours, with no one immediately available to help.
Our behavioral interview questions and answers guide covers structuring these with STAR without sounding rehearsed.
LeetCode, GeeksforGeeks, ChatGPT — where each fits
- LeetCode — right for the DSA gate rounds; wrong as the main event, since matching-engine and ledger correctness under volatility is what actually separates candidates.
- GeeksforGeeks interview experiences — thin for CoinDCX specifically, since crypto exchanges are a newer, more specialized category — treat any single report as one data point.
- A distributed-systems or financial-exchange resource — genuinely necessary here; study order-matching algorithms, ledger atomicity patterns, and circuit-breaker design specifically, since that's the actual syllabus.
- ChatGPT — solid for generating practice matching-engine prompts and sanity-checking a written design; it won't push back on your 24/7-correctness gap the way a real CoinDCX engineer who's operated a live exchange will.
- Greenroom — the spoken layer. Ari, the AI interviewer, runs a mock system-design round out loud and pushes the "it's 3am and the market just moved 20%" follow-up Ankit got caught on, scoring how rigorously you reason about correctness under both load and volatility.
How to prepare for the CoinDCX interview
- Week 1: core DSA — arrays, trees, graphs, hash maps — enough to clear the gate round comfortably.
- Week 2: matching-engine and ledger system design — price-time priority matching, atomic balance updates, circuit breakers — worked through out loud, always asking "what if this happens at 3am during a volatility spike."
- Week 3: failure-mode design — network partitions between matching engine and ledger, trading halts, reconciliation after an incident — each explained in under ninety seconds.
- Final week: one spoken mock where the interviewer pushes an extreme-volatility follow-up on every design choice, plus an always-on-operations-focused behavioral pass.
If CoinDCX is one of several fintech or trading-adjacent companies you're targeting, the underlying skill transfers but the constraints shift — our Groww interview questions guide covers a genuinely DSA-heavy loop for traditional-market investing with fixed trading hours, our Zerodha interview questions guide covers a lighter-DSA, judgment-based loop at the same traditional broker, and the general system design interview guide covers the framework all three assume.
Frequently asked questions
What questions does CoinDCX ask in a technical interview?
Expect DSA and coding fundamentals (order books, priority queues, atomic operations), a machine-coding round building a scoped system like a matching engine or wallet ledger with clean, correct code, system design questions about matching-engine and ledger correctness under 24/7 extreme volatility, and behavioral questions about operating always-on, high-stakes systems.
How many rounds are in the CoinDCX interview process?
Typically an online assessment (DSA plus debugging), DSA rounds, a machine-coding/low-level design round, a system design round, and a hiring manager/HR round — 4–5 rounds total in most reported cases.
What makes CoinDCX's system design round different?
It's specifically about maintaining strict correctness — never double-matching an order, never allowing a negative balance — in a market that never closes and can move violently at any hour, unlike a traditional stock exchange with fixed trading hours. Interviewers want you to reason about correctness under both extreme load and extreme volatility, simultaneously and at any time.
Is the CoinDCX interview process the same for every role?
The DSA-plus-machine-coding-plus-correctness-design shape is the default for backend and fullstack roles; frontend roles keep the same DSA and machine-coding structure with JavaScript, framework and performance depth layered on for the design round instead of matching-engine logic.
How hard is the CoinDCX interview?
It's a consistently high bar rather than a trick-question gauntlet. The part most candidates underprepare for isn't the DSA round — it's realizing that "correct most of the time" is not an acceptable bar for a matching engine and ledger, and designing explicitly for the worst-case moment (extreme volatility, no human on call) rather than the average case.
How is CoinDCX's interview different from Zerodha's or Groww's?
Zerodha and Groww are traditional stock brokers with fixed market hours, giving their systems a predictable close to catch up during; CoinDCX operates a 24/7 market with no closing bell and materially higher volatility, so its system design round specifically probes correctness under conditions those traditional-broker loops don't need to design for as heavily.