Interview
Razorpay Interview Questions and Process: The Complete Guide (2026)
A full breakdown of Razorpay's SDE interview process — every round, the payments concepts that get rewarded, difficulty, timelines, and a 30-day prep plan.
Razorpay's engineering loop is a genuine three-way split. There is an algorithmic round, a long machine coding round, and — from SDE-2 upward — a system design round with a distinctly payments-infrastructure character. Preparing thoroughly for one and hoping the others go well is the most common way strong candidates come unstuck here.
The middle round carries the most weight. Reported experiences describe the machine coding stage as the bar-setting round for the whole loop: it runs 90 to 120 minutes, and later rounds tend to confirm or adjust the judgement it produces rather than overturn it.
This guide covers each stage, the domain instincts Razorpay rewards, and how to prepare. To practise against 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.
The process at a glance
| # | Round | Format | What it screens |
|---|---|---|---|
| 1 | Data structures & algorithms | Live coding with an engineer | Problem solving, complexity reasoning |
| 2 | Machine coding / LLD | 90–120 min, build a working system | The bar-setting round: design, correctness, code quality |
| 3 | High-level design (SDE-2+) | Architecture discussion | Distributed systems, consistency, scale |
| 4 | Hiring manager | Behavioural and project depth | Ownership, judgement, level fit |
Round counts and order vary by level, team and role. An online assessment is not consistently reported, so treat the algorithmic round as the first real gate unless your recruiter tells you otherwise.
Round 1 — data structures and algorithms
A live coding round with an engineer. The material is standard interview algorithms rather than competitive-programming exotica: arrays and strings, hash maps, two pointers, sliding windows, sorting, trees, graphs, and the occasional dynamic programming problem.
What is being marked is as much process as answer. Clarify the problem before coding. State your approach and its complexity before you type. Narrate the trade-off when you choose between two approaches. Notice your own edge cases rather than waiting to be told.
Pattern recognition is what makes this round comfortable, and it is trainable — the DSA Patterns Sheet is free to browse and organises problems by the pattern each tests rather than by topic. Short, regular sessions of in-browser code practice with AI feedback keep it sharp alongside design preparation.
💡 Pro Tip: Calibrate to medium difficulty solved cleanly and explained well, rather than to hard problems solved silently. The second reads worse.
Round 2 — the bar-setting machine coding round
Ninety to a hundred and twenty minutes, one deliberately under-specified problem, and running code expected at the end. In-memory state, your choice of language, no database or web framework, and a driver demonstrating the flows.
The long time budget is not generosity. In two hours, a working core flow is the floor rather than the achievement — what distinguishes a strong submission is structure, correct handling of the awkward cases, and a design that visibly anticipates the next requirement.
The payments instinct
This is where Razorpay's round differs from a generic machine coding exercise. Whatever the surface problem — a ledger, a wallet, a rate limiter, an order state machine — the ideas that earn credit are the ones payments systems are built on:
- Idempotency. If an operation is retried, does it produce the same result? An idempotency key plus a record of processed keys is a handful of lines and signals real domain understanding.
- Exact money. Amounts as integer minor units or a decimal type, never a float. Getting this right unprompted is a strong signal; getting it wrong is a loud one.
- Explicit state transitions. Created, authorised, captured, failed, refunded — modelled as an enumeration with a legal transition table, not a scattering of booleans.
- Auditability. An append-only record of what happened, not only current state.
- Consistency under concurrency. What happens when two requests touch the same balance? Naming the problem and showing where you would lock earns marks even unimplemented.
- Reconciliation. Two systems disagree about what happened. How does the design notice?
None of this requires payments experience. These are single decisions you can make at the start of any design, and they communicate that you have thought about what happens when the world misbehaves — which is most of what payments infrastructure consists of.
Our dedicated walkthrough covers the format, the rubric and the failure modes in detail: Razorpay's machine coding round, the bar-setting interview.
⚠️ Important: Demonstrate a retry and a failure path in your driver, not just the happy path. In a payments context that is the difference between a solution that works and one that is correct.
Round 3 — high-level design, for SDE-2 and above
A real, separate evaluation, and the one senior candidates most often underestimate. The content leans into Razorpay's own problem space: distributed transactions, idempotency at service boundaries, consistency models, and how a system behaves when a downstream dependency is slow or down rather than merely absent.
Expect to reason about throughput and failure rather than to recite a reference architecture. The strongest answers name what they are trading away — availability for consistency, latency for durability — and say why that is the right call for the system in question.
The System Design Sheet is free to browse, and how to design a rate limiter is a good worked example of the depth these rounds expect. If you are unsure how much of this applies at your level, how much system design is enough for SDE-1 vs SDE-2 is a useful calibration. For rehearsal, an HLD mock interview with AI evaluation of the submitted design is closer to the real format than reading alone.
Round 4 — the hiring manager round
Behavioural depth and project specifics. Have two or three projects you can go deep on: what you personally owned, what went wrong, what you would change now.
Razorpay operates in a domain where mistakes are expensive and visible, so judgement under uncertainty tends to come up. Stories about a call you made with incomplete information — and what you did when it turned out badly — land better than stories where everything went to plan.
Is the Razorpay interview hard?
Yes, but specifically rather than uniformly.
The algorithmic round is fair and standard — medium difficulty, familiar patterns. Systematic preparation clears it.
The machine coding round is the hard part, and its difficulty is structural: two hours of unassisted building, from an empty file, with correctness expectations that go beyond "the tests pass". Most candidates have never rehearsed that, which is what makes it decisive.
The system design round at SDE-2 and above is genuinely senior in level, and the payments-domain flavour means generic system design preparation gets you part of the way but not all of it.
How many rounds? Typically three technical stages plus a hiring manager round, varying by level.
How long does it take? Commonly two to four weeks end to end.
A 30-day preparation plan
Week 1 — algorithmic foundations. Core patterns for recognition speed rather than problem volume. Daily short sessions beat weekend marathons.
Week 2 — design vocabulary, with a domain slant. Object-oriented design patterns and class-design idioms. Implement two design problems with no clock, prioritising structure — then deliberately rebuild one of them with idempotency keys and integer minor units even though the prompt did not ask. That exercise is the fastest way to internalise the domain instinct. Design patterns for interviews and the free Low Level Design Sheet cover the ground.
Week 3 — the clock. 120-minute sessions, one problem each, running code by the end, a retry and a failure path demonstrated every time. The four low-level design problems evidenced at Razorpay are the most directly relevant set.
Week 4 — architecture and rehearsal. If you are interviewing at SDE-2 or above, spend this week on distributed systems fundamentals and two full HLD mocks. Otherwise use it for integration: one algorithmic mock, one machine coding mock, one behavioural, and your project stories written out and said aloud.
What a strong submission looks like
It helps to know what "good" looks like concretely, because in a two-hour round the difference between a pass and a strong pass is mostly structural.
A domain model you could describe in three sentences. The entities, what each is responsible for, and where they meet. If describing your own design takes five minutes and several caveats, the design is doing too much in too few places.
One or two interfaces, placed deliberately. Not none, and not eight. The signal is that you identified where the requirements plainly branch — pricing rules, notification channels, payment methods — and put a seam exactly there.
Money handled exactly, without being asked. Integer minor units or a decimal type, chosen at the start. It takes ten seconds and it is one of the clearest domain signals available to you.
A retry that does the right thing. The same operation applied twice with one net effect, demonstrated in the driver. In a payments context this converts a solution that works into one that is correct.
An explicit list of what you left out. Delivered verbally in the last five minutes, or as comments. "I did not implement partial refunds, because the state machine would need a fourth transition and I wanted the core path solid first" is a sentence that reads as seniority.
Code someone else could extend. Short methods, honest names, no cleverness that needs explaining.
None of this requires finishing everything. A well-structured seventy per cent, with the trade-offs named, consistently outperforms a sprawling ninety per cent that nobody could safely change.
Frequently asked questions
How many rounds does Razorpay have? Typically a data structures round, a machine coding round, a system design round for SDE-2 and above, and a hiring manager round. Counts vary by level and team.
Which round matters most? The machine coding round. It is repeatedly described as setting the bar for the loop.
Is there an online assessment? Not consistently reported. Confirm with your recruiter — assume the algorithmic round is the first gate unless told otherwise.
Do I need to know payments to pass? No, but the instincts help a great deal: idempotency, exact monetary representation, and explicit state transitions. All three are learnable in an evening.
Does Razorpay ask system design questions? For SDE-2 and above, yes, as a separate round with a payments-infrastructure character — distributed transactions, idempotency, consistency.
How long is the machine coding round? Reported durations run 90 to 120 minutes. Confirm with your recruiter.
What language should I use? Whichever you are most fluent in. Fluency matters more than the choice.
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.
Where to start
Razorpay's loop rewards two things that are both trainable and both usually untrained: producing clean, working, extensible code under a two-hour clock, and the correctness instincts that payments systems demand.
Open Razorpay's interview kit for the four low-level design problems evidenced at Razorpay, each with an editorial and AI-evaluated practice. Read the machine coding deep dive for the rubric, and browse the free Low Level Design Sheet and System Design Sheet as you find gaps.
Interview processes change. Confirm round structure with your recruiter and check Razorpay's careers site for current openings.