Interview
Razorpay Machine Coding Round: The Bar-Setting Interview (2026)
Razorpay's machine coding round sets the bar for the whole loop. Learn the format, the 120-minute structure, the payments design ideas, and how to practise.
Razorpay's machine coding round is, by repeated account, the round that sets the bar for the entire loop. It runs long — 90 to 120 minutes — and it is where the hiring decision effectively gets made. Everything after it tends to confirm or adjust a judgement that this round already formed.
It is also a round with a distinctive flavour. Razorpay builds payments infrastructure, and its design interviews reflect that: the problems reward candidates who think in terms of correctness under retry, idempotency, and state that must never be wrong. This guide covers the format, the rubric, the payments-specific ideas worth internalising, and how to practise.
To work through the design problems evidenced at Razorpay, Razorpay's interview kit holds four low-level design problems attributed to the company, each with a worked editorial and AI-evaluated practice.
Where the round sits in Razorpay's loop
| Stage | Format | What it screens |
|---|---|---|
| Data structures & algorithms | Live coding with an engineer | Baseline problem solving, complexity reasoning |
| Machine coding / LLD | 90–120 min, build a working system | The bar-setting round: design, correctness, code quality |
| High-level design (SDE-2 and above) | Architecture discussion | Distributed systems, consistency, scale |
| Hiring manager | Behavioural + project depth | Ownership, judgement, level fit |
Note the shape: this is a genuine three-way split across algorithms, class-level design and architecture. Preparing for one and hoping the others go well is the most common way candidates come unstuck. For senior roles the high-level design round is a real, separate evaluation with a payments-infrastructure character — distributed transactions, idempotency and consistency come up directly.
💡 Pro Tip: If you are interviewing at SDE-2 or above, allocate preparation across all three round types from the start. The machine coding round is the heaviest, but the HLD round is where senior candidates are most often surprised.
What the machine coding round looks like
You are given a compact, under-specified problem and 90 to 120 minutes to produce running code. Typical shapes include ledgers and expense splitters, rate limiters, inventory or wallet services, notification dispatchers, and order or payment state machines.
The ground rules:
- Working code, not pseudocode. It compiles and it runs.
- Your choice of language. Pick fluency over impressiveness.
- In-memory state. No database, no web framework, no network calls.
- A driver or test harness demonstrating the flows end to end.
- A deliberately incomplete spec. The gaps are the test.
The longer time budget relative to other companies is not generosity — it raises the expectation. In 120 minutes, a working core flow is the floor, not the achievement. What distinguishes a strong submission is structure, correct handling of the awkward cases, and a design that visibly anticipates the next requirement.
⚠️ Important: Open by clarifying scope and stating your assumptions explicitly. On a two-hour round there is no excuse for building the wrong thing, and interviewers mark the clarification itself.
The payments instinct that separates candidates
This is where Razorpay's round differs from a generic machine coding exercise. Whatever the surface problem, the design ideas that earn credit tend to be the ones payments systems are built on. Internalising a handful of them changes how your solution reads.
Idempotency. If an operation is retried — and in payments it will be — does it produce the same result? An idempotency key on a request, and a store of already-processed keys, is a small amount of code that signals real domain understanding.
Exactness over convenience. Money is not a float. Represent amounts in minor units as integers, or use a decimal type. Getting this right unprompted is a strong signal; getting it wrong is a visible one.
State machines with explicit, legal transitions. Payments move through defined states — created, authorised, captured, failed, refunded. Modelling transitions explicitly, and rejecting illegal ones, is far stronger than scattering boolean flags across a class.
Auditability. An append-only record of what happened, rather than only current state, reflects how financial systems are actually built.
Consistency under concurrency. What happens when two requests touch the same balance simultaneously? Even naming the problem and showing where you would lock is worth marks.
Reconciliation. Two systems disagree about what happened. How does the design detect and resolve that?
None of this requires payments experience to demonstrate. An idempotency key checked against a set of processed identifiers is perhaps fifteen lines of code. Representing amounts as integer minor units is a type choice you make once at the start. Modelling status as an enumeration with an explicit transition table, rather than a scattering of booleans, is a structural decision that costs nothing and reads as domain maturity. What these choices communicate is that you have thought about what happens when the world misbehaves — which is most of what building payments infrastructure consists of.
✅ Do: Name these concerns aloud as you design, even where you do not implement them fully. ❌ Don't: Model money as a floating-point number. It is the fastest way to signal unfamiliarity with the domain.
How to structure 120 minutes
| Time | Focus |
|---|---|
| 0–10 min | Clarify the spec. State assumptions, scope and the cases you are explicitly excluding. |
| 10–25 min | Sketch the domain model: entities, states, and the interfaces where behaviour varies. |
| 25–80 min | Implement the core flow end to end. Keep it running throughout. |
| 80–100 min | Edge cases, concurrency, idempotency. Extract abstractions the design is asking for. |
| 100–115 min | Driver or tests demonstrating the flows, including a retry and a failure path. |
| 115–120 min | Walk through the design; name the trade-offs and what you would do next. |
The retry path in the demonstration is worth calling out. Showing the same operation applied twice with one net effect, in a system where that matters, is a compact way to prove the point.
The rubric
Roughly in order of weight:
- It works — the core flow runs end to end.
- Class design — clear responsibilities, a real domain model, sensible separation.
- Extensibility — "how would you add X?" should be answerable with a new implementation, not a rewrite.
- Correctness in the awkward cases — retries, concurrent access, invalid transitions, boundary amounts.
- Readability — naming, method size, consistency.
- Demonstration — a driver that exercises the interesting paths, not just the happy one.
Our guide to what interviewers actually look for in live coding rounds covers how this marking works in practice across companies.
The failure modes
- Nothing runs at the end. Still the most common way to fail a two-hour round.
- Over-engineering early. Abstract factories before a working core flow.
- Floating-point money. Small detail, loud signal.
- Only the happy path. No retry, no failure, no invalid input.
- A single god class. No domain model, all logic in one procedural block.
- Silence. Reasoning the interviewer never heard cannot be marked.
- Ignoring the extension question. Answering with a rewrite rather than a plug-in point.
The fix is rehearsal under real constraints. The four low-level design problems evidenced at Razorpay come with editorials and an AI-evaluated practice mode, and an LLD mock interview will interrogate your design the way an interviewer does.
Preparing for the rest of the loop
The algorithmic round rewards pattern recognition over problem volume. The DSA Patterns Sheet is free to browse and organises problems by the pattern each one tests, which is a considerably faster route than working through unstructured lists. Short sessions of in-browser code practice with AI feedback keep this sharp alongside design preparation.
The high-level design round, for SDE-2 and above, leans into Razorpay's own domain: distributed transactions, idempotency at service boundaries, consistency and scale. The System Design Sheet is free to browse, and how to design a rate limiter is a good worked example of the level of detail these rounds expect. Low-level design vs high-level design is worth reading first if the boundary between the two rounds is unclear.
The hiring manager round is a real evaluation. Have two or three projects you can go deep on — what you owned, what broke, what you would change.
A two-week preparation plan
Week 1 — domain vocabulary and design fundamentals. Work through object-oriented design patterns and class-design idioms. Implement two design problems without a clock, prioritising structure. Layer in the payments concepts deliberately: build one of them with idempotency keys and integer minor units even if the prompt does not ask.
Week 2 — speed under constraints. Switch to a 120-minute clock, one problem per session, running code by the end. Force yourself to demonstrate a retry and a failure path every time. Close each session by writing down what another thirty minutes would have bought — the same muscle the final five minutes of the real round uses.
💡 Pro Tip: Practise without an AI assistant. The round is unassisted and timed; practice that ignores either constraint builds confidence that will not survive the real thing.
Frequently asked questions
How long is Razorpay's machine coding round? Reported durations run 90 to 120 minutes. Confirm with your recruiter, as it varies by level and team.
Is the machine coding round the most important one? It is repeatedly described as the bar-setting round for the loop. Later rounds tend to confirm or adjust the judgement it produces.
Do I need to know payments to pass? No, but the instinct helps. Idempotency, exact monetary representation and explicit state transitions are the ideas most worth internalising, and they are learnable in an evening.
Can I use my own IDE and language? Usually yes. Use what you are fastest in, and confirm with your recruiter.
Does Razorpay ask DSA questions? Yes — a dedicated data structures and algorithms round comes before the design rounds. Pattern-based preparation is the efficient route through it.
Is there a system design round? For SDE-2 and above, yes, and it is a separate evaluation with a distinctly payments-infrastructure character — distributed transactions, idempotency and consistency.
Should I write tests? Write enough to demonstrate the flows, including at least one retry and one failure path. Exhaustive unit tests are a bonus, not a requirement.
How should I handle an under-specified problem? Ask. Then state your assumptions explicitly and move. The incompleteness is deliberate, and how you handle it is marked.
Start practising
Razorpay's machine coding round asks for something specific: clean, working, extensible code produced from a blank file in two hours, with the correctness instincts that payments systems demand. Both halves are trainable, and both need practice under the real constraints.
Open Razorpay's interview kit to work through the four low-level design problems evidenced at Razorpay, each with an editorial and AI-evaluated practice. Add an LLD mock interview for the discussion format, and browse the free Low Level Design Sheet as you find gaps.
Interview formats change. Confirm round structure and timings with your recruiter, and check Razorpay's careers site for current openings.