Razorpay Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about Razorpay:

• More than most product companies, they weight the machine-coding / low-level-design round.
• You can clear two LeetCode rounds clean and still get rejected if you cannot turn a messy prompt into well-factored, testable classes in 90 to 120 minutes.
• The skill is different from LeetCode: not "find the trick," but "structure a system a teammate could extend without cursing your name."
• Candidates with 500+ problems solved freeze here all the time, because none of those reps taught decomposition.

2Getting the call (the part most guides skip)#

Three doors open at Razorpay, and most people only knock on one.

Referrals are the strongest door.

• A referral routes your resume past the general queue and usually gets a recruiter's eyes in days, not weeks.
• Find Razorpay engineers on LinkedIn who work on your stack (payments, platform, X, RazorpayX, Capital).
• Send a short, specific note: one line on why their team, one line on a relevant thing you built, resume attached.
• Referrals carry weight because the referrer stakes a slice of their own reputation on you, so make it easy to say yes by being concrete.

Off-campus / careers page.

• Apply on the Razorpay careers site, then immediately message a recruiter or engineer.
• A cold application alone often stalls in the pile for weeks. Application plus a warm ping gets opened.

Campus.

• For new grads, Razorpay hires from top engineering campuses with an online coding test first (2-3 DSA problems, 60-90 minutes), then the live rounds.
• The test cutoff is ruthless: clearing it usually means solving the medium and making real progress on the hard one.

Resume rules.

• One page. Lead every bullet with impact and a number.
• Weak: "Worked on backend APIs for the payments team."
• Strong: "Rebuilt the refund reconciliation job in Java/Spring, cutting a 40-minute batch to under 4 minutes and eliminating ~2,000 daily mismatch tickets."
• The difference is not fancier words: the strong version names the stack, the before-and-after number, and the business pain removed.
• A reviewer skims each resume in roughly 20 to 30 seconds, so the number has to hit in the first half of the line.

ATS keywords that help for a backend SDE.

• Java, Spring Boot, microservices, MySQL/PostgreSQL, Redis, Kafka, REST, concurrency, distributed systems, AWS, system design, data structures.
• Mirror the exact words from the job description. The first filter is often keyword-based, and matching the JD's phrasing (not synonyms) is what trips it.

3The loop at a glance#

How the loop actually runs:

• Not every candidate gets every round. Junior loops may skip system design.
• Senior loops may add a second design round or a bar-raiser-style conversation with an engineer from a different team whose job is to protect the hiring bar.
• Rounds are often spread across a few days, sometimes two half-days, so pace your energy.

4The coding / technical rounds, patterns, not problems#

Razorpay's DSA bar is medium to hard, LeetCode-style, but interviewers care as much about how you solve as whether you solve.

• Memorizing 500 problems helps less than deeply owning ~15 patterns.
• The live round is a conversation: they watch how you reason, not just the final green checkmark.

Patterns they reuse:

• Arrays & two pointers / sliding window: subarray sums, longest-substring variants, intervals.
• Hashing: frequency maps, grouping, deduplication, prefix-sum + hashmap.
• Strings: parsing, pattern matching, encoding/decoding.
• Trees & graphs: BFS/DFS, topological sort, shortest path, LCA.
• Heaps / priority queues: top-K, merge-K, scheduling.
• Dynamic programming: knapsack family, grid paths, string edit/match DP.
• Recursion & backtracking: combinations, subsets, generating valid configurations.
• Stacks/queues: monotonic stack, next-greater, expression evaluation.

The fintech wrapper is just a costume.

• Expect at least one problem dressed up in a payments scenario: rate limiting a merchant's API, bucketing transactions in a time window, deduping webhook events by idempotency key.
• The underlying structure is a standard pattern. Strip the wrapper and it is usually a sliding window or a hashmap.
• Do not let the costume intimidate you. Name the data structure underneath first, then solve.

How to practice:

• Do ~120-150 curated medium problems, grouped by pattern, not random.
• For each, write the solution, then re-derive the optimal complexity from scratch a day later.
• If you cannot rebuild it cold, you memorized it, you did not learn it.
• Practice talking out loud: narrate your thinking while a timer runs. The silent-solver habit is the single easiest way to tank a live round.

How to win the round:

1. Clarify first. Restate the problem, confirm input ranges, ask about duplicates, empty inputs, negative numbers, and output format. Thirty seconds here prevents five minutes of wrong direction.
2. State a brute force, then optimize. Say the naive approach and its complexity out loud, then improve. This shows range even if you do not reach optimal, and it gives the interviewer a hook to nudge you.
3. Say your complexity out loud. Time and space, before and after optimizing. "This is O(n squared) now; with a hashmap I can get it to O(n) time, O(n) space."
4. Write clean code. Meaningful names, small functions, no magic numbers. Interviewers read your code as a work sample, and sloppy variables like temp2 cost you.
5. Test it yourself. Dry-run one normal case and one edge case before the interviewer asks. Catching your own bug scores higher than them catching it: it signals the rigor they want in someone touching money code.

5Machine coding / Low-Level Design, the round that decides it#

This is Razorpay's signature round and where strong LeetCoders often fall.

• You get a real-ish spec: "build a parking lot system," "design a splitwise expense manager," "build an in-memory key-value store with TTL," "model a payment-gateway routing engine."
• You get 90-120 minutes to produce running, well-structured code.

They are not grading cleverness. They are grading engineering maturity.

• Can you decompose a problem into clean objects, apply the right abstractions, and leave room to extend?
• The mental test the interviewer runs is simple: "Would I merge this PR, and could a new teammate add a feature to it next sprint without a rewrite?"

A framework that works under time pressure:

1. Clarify scope (5 min). Nail down what is in and out. Better to fully build 3 features than half-build 6. Ask directly: "Should I handle concurrency? Persistence? Or keep it in-memory single-threaded for now?" and let them set the boundary.
2. Identify entities & responsibilities. List the nouns (classes) and what each owns. Keep responsibilities single: one class, one job. For a Splitwise clone that is User, Group, Expense, SplitStrategy, BalanceSheet, not one App class doing all of it.
3. Design interfaces first. Define the key methods and how objects talk before writing bodies. An interface like SplitStrategy.split(amount, participants) lets you add equal, exact, and percentage splits later without touching the Expense class.
4. Apply patterns where they fit naturally. Strategy (pluggable routing rules or split types), Factory (create the right handler by type), Observer (notify on balance change), Singleton for a registry. Never force a pattern: a named pattern used wrong reads worse than clean plain code.
5. Code the core happy path, then extend. Get something running early. Add validation and edge cases once the skeleton works. A demo that runs at minute 60 beats a perfect design that never compiles.
6. Make it testable. Separate logic from I/O; a main that demonstrates the flow is enough if there is no test harness. If you have 10 minutes left, a couple of assert-style checks show you think in tests.

What interviewers reward:

• Separation of concerns, no god-class.
• Encapsulation: private state, clean getters, no public mutable fields.
• Extensibility: "if we added a new payment method, I would only add a class, not edit existing ones" (the Open/Closed principle).
• Readable naming, and the principle said out loud as you apply it. They want to hear the reasoning, not infer it.

What gets you rejected:

• Dumping everything into one class with a giant if/else ladder.
• Exposing mutable public fields.
• Hard-coding values like tax rates or currency.
• Running out of time with nothing that compiles.

For SDE-2 and above, there is also system design. Use a crisp framework:

1. Requirements: functional + non-functional (scale, latency, consistency, availability). For fintech, ask about consistency and idempotency early. This is where money systems differ from a typical CRUD app.
2. Estimates: QPS, storage, read/write ratio. Even rough numbers show you size before you build.
3. API & data model.
4. High-level architecture: services, datastores, queues, caches.
5. Deep-dive: the hard part they poke at.
6. Trade-offs & failure modes: what breaks and how you degrade gracefully.

A payment flow at a high level looks like this, and being able to sketch it fast earns trust:

Classic Razorpay-flavored prompts:

• Design a payment gateway, a URL shortener, a rate limiter, a notification/webhook delivery system, an idempotent payment API, a wallet/ledger service.
• For any money prompt, show you understand idempotency keys, double-entry ledgers, exactly-once vs at-least-once delivery, and reconciliation.

6Behavioral & culture fit#

Razorpay's culture centers on a few values you should be able to speak to with real examples.

• Customer obsession, ownership (act like a founder), humility and openness to feedback, bias for action / shipping, and transparency.
• The behavioral round probes whether you take initiative, handle ambiguity, and collaborate without ego.
• "Act like a founder" is the one they weight most, so have at least two stories where you owned something beyond your assigned scope.

Build 5-6 STAR stories (Situation, Task, Action, Result), and make sure every Result has a number. One worked example:

• Situation: Our checkout service was dropping ~3% of payment callbacks during traffic spikes, causing customer-visible "payment stuck" states.
• Task: I owned reliability for the callback pipeline and had to cut the drop rate without a full rewrite before the festive sale.
• Action: I traced the loss to synchronous DB writes blocking the handler. I introduced a Kafka queue to decouple receipt from processing, added idempotency keys so retries were safe, and built a reconciliation job to catch any stragglers.
• Result: Callback drop rate fell from 3% to under 0.1%, "payment stuck" tickets dropped by about 85%, and the pipeline held through a 4x sale-day spike with no manual intervention.

Why that story lands:

• It shows ownership, bias for action, and fintech instincts (idempotency, reconciliation), exactly what Razorpay looks for.
• It names a constraint ("without a full rewrite before the festive sale"), which proves you ship under real pressure instead of gold-plating.
• Prepare a genuine answer for "why Razorpay," tied to something specific (their payments scale, a product like RazorpayX), not "I love fintech."
• Bring 2-3 real questions about the team's roadmap or on-call reality. Having none reads as low interest.

7Your prep plan#

4-week plan

• Week 1: Patterns review, arrays, hashing, strings, two pointers, stacks. 6-8 problems/day, talk out loud.
• Week 2: Trees, graphs, heaps, DP. Start one machine-coding problem end to end (parking lot).
• Week 3: Two machine-coding builds (Splitwise, in-memory KV store); study LLD principles (SOLID, common patterns). Begin system design basics.
• Week 4: 4-5 mock interviews (DSA + one machine coding + one design). Write and rehearse STAR stories. Rest the day before.

2-week plan

• Days 1-5: Drill the top 8 DSA patterns, ~100 mediums total.
• Days 6-9: Three full machine-coding builds, timed to 90 min each.
• Days 10-12: System design framework + 4 classic prompts (payment gateway, rate limiter, URL shortener, notification system).
• Days 13-14: Two mocks, STAR stories, company research.

2-day crash plan

• Day 1: Re-solve 20 pattern-representative mediums; do one timed machine-coding build; review SOLID.
• Day 2: One design prompt out loud; write 4 STAR stories with numbers; re-read the job description; sleep.

The non-negotiable across all three plans:

• At least one timed machine-coding build, done to completion.
• Reading about LLD teaches you nothing about managing the clock.
• You only learn clock management by failing to finish once in practice, instead of in the real round.

8Why people get rejected at Razorpay#

1. Machine-coding god-class. Everything crammed into one file with nested if/else. Reads as "cannot structure code," and it is the most common rejection reason in this loop.
2. Brute force with no optimization. Solving the problem but never discussing or reaching a better complexity, which signals you stop at "it works" instead of "it scales."
3. Coding before clarifying. Building the wrong thing because they did not confirm the spec, then burning 20 minutes they cannot get back.
4. No fintech instinct in design. A payment flow with no idempotency, no ledger, no reconciliation story. At a payments company this is close to disqualifying for SDE-2+.
5. Silent problem-solving. Interviewers cannot score thinking they cannot hear. Long silences read as being stuck even when you are not.
6. Flat behavioral answers. "We did X" with no personal ownership, no conflict, no measurable result. They listen for "I," not "we."

9The offer, comp & negotiation#

Razorpay pays competitively for the Indian market. Typical total comp (base + RSUs/ESOPs + joining bonus):

• SDE-1: ~₹20-32L total
• SDE-2: ~₹35-55L total
• SDE-3: ~₹55-85L+ total

About the equity.

• A meaningful slice is equity (ESOPs/RSUs), so understand the strike price, the vesting schedule (usually 4 years, often with a 1-year cliff), and the current preferred valuation.
• As a private company, that equity value depends heavily on growth and the next funding round, so treat the paper number as a range, not a guarantee.

Negotiation tips:

1. Use competing offers honestly. A real written offer from a comparable company is the strongest lever. Share the actual number, not a vague "I have other offers." Specificity moves bands.
2. Negotiate the whole package, not just base. If base is capped by band, push on RSU count, joining bonus, and level. Getting bumped a level is often worth more than any base bump, both this year and in every raise and refresh after.
3. Ask how equity is valued and refreshed. Clarify the latest 409A/preferred price and whether there are refresh grants. For a private fintech, refresh policy changes the real multi-year number a lot, and most candidates forget to ask.

Want this turned into a concrete, dated plan around your actual interview date? Build a personalized week-by-week schedule and walk in prepared.