Razorpay Software Engineer Interview: Every Round, Decoded

Most fintech interviews look like watered-down FAANG loops. Same two LeetCode problems. Same system design whiteboard. Same polite "we'll be in touch" on the way out. Razorpay's doesn't. The machine coding round alone filters out candidates who would have sailed through a standard DSA gauntlet. This guide covers the full Razorpay software engineer interview for SDE1 through SSE, with an honest breakdown of what each stage actually tests.

The Full Loop at a Glance

Round	Format	Duration	What It Tests
Recruiter screen	Phone call	30 min	Role fit, basics, compensation
Online assessment	HackerRank/similar	90 min	MCQs (OS, DBMS, OOP) + 2-3 coding problems
DSA technical round	Video, shared editor	60 min	1-2 LeetCode-style problems
Machine coding / LLD	Video, your IDE	90 min	Design and build a working in-memory system
System design / HLD	Video, whiteboard	60 min	Large-scale distributed system design
Hiring manager	Video	45-60 min	Leadership, culture, project depth
HR	Video	30 min	Compensation, logistics

SDE1 roles sometimes skip the system design round or merge it lightly into the HM round. SSE and above typically get all seven.

The Online Assessment: Easier Than It Looks

The OA runs 90 minutes: fifteen MCQs, then two or three coding problems.

The MCQs feel like a quiz from a class you vaguely remember taking. Cache coherence, ACID properties, virtual memory, basic complexity analysis. The kind of material that felt irrelevant to every job you've had since graduation, until today. These are questions that feel embarrassing to miss, so spend a few hours reviewing OS and DBMS fundamentals before you sit down.

The coding problems are LeetCode easy-to-medium. Grid DP, two-sum variants, interval problems. Correct code with reasonable complexity is enough. Don't overcomplicate it.

The DSA Technical Round: Standard but Important

One or two problems, about 60 minutes. The difficulty is solidly LeetCode medium, with occasional hard problems at senior levels.

Common topics from recent candidate reports:

Hash maps and frequency counting
Dynamic programming (partition DP, path problems)
Graph traversal with DP layered on top
Interval merging
Two pointers and sliding window

One pattern that shows up more than average: problems with a domain twist. The prompt sounds like a payment scenario, complete with EMI schedules and transaction IDs, but the underlying algorithm is standard graph traversal or DP. Don't let the costume confuse you. Read past the story to find the structure.

For what these patterns look like and how to train recognition, DSA for Backend Engineers covers the set that matters most if you're coming from a systems background.

The Machine Coding Round: Razorpay's Signature Filter

This is the round that makes Razorpay distinct. Ninety minutes. Your own IDE. A product-like problem you design and implement from scratch, with running test cases by the end.

This is not a whiteboard round. You write real code, run it, and the interviewer watches the whole process. For 90 minutes. They see what you Google. They see when you delete the class you just wrote and start over. They see everything. Treat it accordingly.

Recent problems from candidates:

In-memory search engine: ingest documents, support keyword search, rank results
In-memory database: create and delete tables, insert and query records
Pub-sub model: publish messages to topics, subscribe consumers, handle offsets
Rate limiter: sliding window, support multiple limits per client
Loan EMI calculator: model loan products, compute schedules, support updates

The problem sounds manageable for the first ten minutes. Then requirements expand. An interviewer might add: "Now support soft deletes. Now add pagination. Now let multiple subscribers consume independently." If you built toward the first spec without asking about extensions, you are now rewriting instead of extending, and the clock is still running.

The real test is extensibility. Can you design for change without rewriting from scratch?

My code vs what I tell the interviewer it does - sad kitten vs buff anime cat

When the machine coding round is live and your code is... visible.

What interviewers score:

SOLID principles, especially Single Responsibility and Open/Closed
Clean separation between data models, business logic, and I/O
Sensible data structure choices (why a HashMap here, why a TreeMap there)
Code that's readable by a stranger, not just correct
Handling edge cases before being asked

What kills candidates: jumping to implementation before clarifying requirements, writing a giant procedural function instead of split classes, producing code that works for the happy path but breaks on extension.

Read the requirements twice. Sketch the class structure before writing a line. Name things clearly. These aren't soft suggestions. They're what gets written in your evaluation.

The System Design Round: Think Payments, Not Just Infrastructure

Senior and above. About 60 minutes. The scope is a distributed system, often with a payments or platform flavor.

Reported problems: job scheduler at scale, subscription billing platform, payment gateway with retry logic, notification delivery system.

Payment systems have different correctness requirements than typical web apps. Idempotency is not optional. Exactly-once semantics matter. Consistency beats availability on the critical path. A generic "throw Kafka at it" answer without discussing retry semantics and idempotency keys signals that you haven't thought about what makes distributed payment systems different from standard CRUD apps.

Things to be ready to discuss:

Idempotency keys and how they prevent double charges
Distributed transaction patterns (saga, two-phase commit, outbox pattern)
Exactly-once delivery with Kafka
Rate limiting and circuit breakers for downstream payment networks
PCI-DSS compliance considerations (data residency, encryption at rest)

The tech stack is heavily Go and Java, with Kafka and Redis as primary infrastructure. You don't need to code in Go, but knowing the tooling signals domain fluency.

Compare this to Stripe's interview, which is also fintech-heavy but leans harder into distributed systems theory. Razorpay's HLD round is more product-oriented. You're designing something that could be a Razorpay feature, not a textbook problem.

What the Hiring Manager Actually Cares About

Behavioral and project depth. Expect questions about your most complex project, decisions made under uncertainty, and how you handle disagreement with a technical peer.

Razorpay cares about builders. Candidates who have shipped things and can talk through the tradeoffs in real systems do well here. Have two or three project stories ready with specific numbers and actual decisions. "We considered X but chose Y because Z" is what you're going for, not a product tour.

What Gets You Rejected

Several patterns show up repeatedly in rejection reports.

Treating the machine coding round like a LeetCode problem. You are not being asked for the optimal algorithm. You are being asked to design software. These are not the same skill. Candidates who write correct but unstructured code and call it done consistently don't advance.

Writing the happy path and stopping. Every machine coding problem has edge cases baked into the requirements. Reviewers note whether you handled them before being prompted or only after. "Oh, I was going to add that" is not a useful phrase at the 85-minute mark.

Narrating nothing during the machine coding round. The interviewer is watching you type for 90 minutes. Silence gives them nothing to write down. Talk through your class design before you write it. Say why you're choosing a particular data structure. Coding interview communication matters here more than in any other round because the gap between candidates who narrate and those who don't is enormous.

Generic HLD answers without payment context. Designing a job scheduler without mentioning idempotency or retry semantics signals that you haven't thought about what makes payment systems different from standard apps.

Not clarifying requirements at the start. Machine coding problems expand. If you build toward the first spec without asking about likely extensions, you will be rewriting code instead of extending it. This is avoidable.

How to Prepare

DSA (3-4 weeks): 40-60 LeetCode mediums across hash maps, DP, graphs, intervals, and sliding window. Add 10-15 hards if you're targeting SSE. Grid DP and graph+DP hybrids appear repeatedly in the technical round. Don't skip the MCQ material. A few hours on OS fundamentals (process scheduling, virtual memory, mutex vs semaphore) and DBMS (indexing, ACID, normal forms) is cheap insurance.

Machine coding (2-3 weeks, high priority): Practice building in-memory systems in your preferred language with a 90-minute timer. Start with: rate limiter, LRU/LFU cache, key-value store with TTL. Move to harder problems: pub-sub model, in-memory SQL-like database. After each one, review your class structure against SOLID principles. Ask yourself: if I needed to add one more requirement, would I extend or rewrite?

Good resources: Gaurav Sen's YouTube LLD playlist, refactoring.guru for design patterns, and reviewing open-source implementations of the systems above.

System design (1-2 weeks): Cover the standard distributed systems canon, then layer in payment-specific reading. The Stripe Engineering Blog and Razorpay's own engineering blog publish real case studies on the problems you'll be asked to design. Read idempotency key patterns, the outbox pattern for reliable messaging, and saga choreography for distributed transactions.

Voice practice: The machine coding round is a live coding interview with continuous narration. You need reps doing this out loud, not just writing code solo. SpaceComplexity runs voice-based mock interviews with rubric feedback, which is closer to the actual machine coding round dynamic than silent LeetCode grinding.

How Long Will This Take?

Your situation	Recommended prep time
Actively coding, recent LLD exposure	3-4 weeks
Coding daily, no recent LLD practice	5-6 weeks
After a gap or career switch	8-10 weeks

The machine coding round is the swing factor. Most candidates who don't make it past that round report the problem itself wasn't hard. The design under time pressure was. That's the part you actually need to practice.