Razorpay Onsite Interview: Every Round, What It Tests, and How to Prepare

The Razorpay onsite interview is one of the more technically demanding fintech loops in India. Four or five rounds spread across two to three days, probing DSA fluency, low-level design instincts, system-scale thinking, and whether you actually understand that project on your resume or just watched someone else build it. Treat it like a generic FAANG prep loop and you'll walk out confused about why you didn't clear the machine coding round. You'll have cleared the DSA round. The machine coding round will humble you.

Five Rounds, One Real Gate

For experienced candidates (2 to 6 years), the standard onsite is:

Round	Duration	What it tests
DSA Coding	45 min	Pattern recognition, complexity analysis
Machine Coding (LLD)	60-90 min	Object-oriented design, working code
System Design (HLD)	45-60 min	Distributed systems, scalability
Hiring Manager	45 min	Technical depth, ownership, judgment
HR	30 min	Compensation, interpersonal fit

SDE-1 candidates or campus hires sometimes skip the HLD round and get a second DSA round instead. Senior engineers and tech leads get both LLD and HLD, and the bar on each is higher.

The loop runs over two to three days, not a single marathon session. Total time from first contact to offer is around two to three weeks.

Pattern Recognition Under Pressure

The DSA round tests whether you can identify the right algorithmic pattern under time pressure and explain your reasoning out loud. Razorpay interviewers probe complexity at every step and will push you to optimize if your first solution isn't efficient enough.

Typical format: two problems in 45 minutes, skewing medium-to-hard. The second problem usually builds on the first or requires a non-obvious reduction to a known pattern.

Common topics recently:

Subarray problems (sliding window, prefix sum)
Dynamic programming (knapsack variants, 2D DP on strings)
Graph traversal with conditions (BFS with state, DFS on weighted paths)
Tree problems (max path sum, LCA, N-ary trees with dynamic children)

One candidate was asked to find all subarrays of size k with sum above a threshold. Another had to traverse an N-ary tree and find the max path from root to leaf. Both require naming the pattern, implementing it cleanly, and stating complexity before moving on.

Name the approach before writing code. Walk through one example. Run edge cases. Razorpay interviewers write down what you say, not just what compiles.

Machine Coding Is the Round That Eats People

This is the round candidates underestimate. The round Razorpay treats as the most important signal. The round that eats candidates who sailed through DSA sections elsewhere, sometimes at companies with much harder reputations.

Machine coding tests whether you can produce production-quality, extensible code on a blank canvas in real time, without referencing documentation. Not just "does this pass test cases." Does this have clean class boundaries? Is the data model sensible? Could someone extend this without touching half the codebase?

You get 60 to 90 minutes to design and implement an in-memory system from scratch. The problem statement is intentionally open-ended. You are expected to clarify requirements, model the domain with classes or interfaces, implement the core functionality, and discuss how you'd extend it.

Problems asked in recent rounds:

In-memory expense-sharing app (Splitwise-style): add users, create expenses, split equally or by custom shares, view balances
In-memory pub-sub queue: producers, consumers, subscriptions, offset management
Version control system (Git-lite): add files, commit, branch, rollback to previous commits
In-memory RDBMS: tables, rows, columns, primary key enforcement, basic query support
Document search engine: index blog content, search by keyword

None of these are LeetCode problems. There is no pattern to recognize. You are making real design decisions: how to model an Expense, whether subscriptions live in a map or a list, what an Offset looks like in your pub-sub. The interviewer watches your design instincts, not just your ability to type.

What gets you rejected here: treating it like a coding puzzle and jumping straight into helper functions; ignoring extensibility; missing a functional requirement because you didn't clarify upfront; writing code that works for the happy path but breaks on edge conditions.

Start with a 5-minute requirement walkthrough. Define your core classes first, then fill in behavior. Ask yourself the uncomfortable questions early: who owns the balance when an expense is deleted? What happens on a duplicate commit? Clean separation between data and logic is table stakes, not a bonus.

If you haven't practiced LLD problems before your Razorpay onsite, this round will be a rude surprise. Budget at least two to three weeks of LLD-specific prep. LLD is a skill that feels distant and theoretical until you're 20 minutes into building a Git-lite and realize your branching model makes rollback structurally impossible.

System Design: Fintech Context Is Half the Test

For SDE-2 and above, the HLD round is a 45 to 60 minute conversation about a distributed system at scale. Razorpay often frames the problem with fintech context, but the underlying concepts are standard distributed systems.

Recent problems:

Design a URL shortener (functional requirements, then scale to millions of redirects per second)
Design a subscription billing platform on top of Razorpay (recurring charges, plan management, failure handling)
Design a notification service (multi-channel, delivery guarantees, fan-out at scale)
Design a high-traffic e-commerce system (inventory, ordering, search, browse)

What Razorpay specifically probes: idempotency, exactly-once delivery, reconciliation, and what happens when things fail at a bad moment. For a billing platform, the interviewer will ask how you handle a failed charge at 11:59 PM on a billing cycle. Fintech cannot afford eventual consistency on financial state. The interviewer expects you to know that, and to have a concrete answer.

A structure that works: 5 minutes on requirements and constraints, 10 minutes on the API and data model, 15 minutes on core architecture, 10 minutes on failure handling and bottlenecks, 5 minutes on tradeoffs you made.

You don't need to know Razorpay's internal stack. You need to know the distributed systems primitives and be able to defend why you chose them.

The HM Round Is Technical, Not a Vibe Check

The hiring manager round is not "tell me about yourself." The HM will pick a project from your resume and probe it until they find the edge of what you actually understand. This is a deliberate method.

Expect questions like: why did you choose that database? What would break first at 10x load? How did you handle the failure you didn't mention? What would you do differently now? Candidates have also been asked about TDD philosophy as a proxy for how they think about quality and iteration speed.

The HM wants to know whether you own the technical decisions in your past projects or just implemented someone else's design. And whether you're intellectually honest when you hit the limits of what you know.

Pick one project you made real decisions on. Know the schema, the traffic patterns, the failure modes, and at least one thing you'd change. If you can talk about it for 30 minutes without drying up, you're ready. If you're reaching for a system your tech lead designed while you watched, pick a different project.

HR Round and What the Bar Actually Looks Like

The HR round is lightweight: compensation discussion, role clarification, interpersonal screen. Come with a number in mind and know your walk-away floor.

The overall bar is harder than most mid-stage Indian startups, roughly on par with Flipkart and Stripe India for backend roles. The machine coding round rejects candidates who clear DSA rounds easily elsewhere. If your entire prep is LeetCode, you've covered the table stakes. Machine coding is the actual filter.

Six Weeks to Clear the Razorpay Onsite

For backend engineers with 2 to 3 years of experience and a solid DSA foundation, six weeks is realistic. Add two more if LLD is genuinely new territory.

Six weeks out: Two weeks on LLD. Work through at least five machine coding problems: parking lot, library management, expense sharing, pub-sub, ride-sharing. Build each from scratch in 90 minutes without references. Focus on clean interfaces and extensibility. Then two weeks on distributed systems. Design payment systems, notification pipelines, rate limiters, URL shorteners. Practice out loud with a consistent framework: requirements, API, data model, architecture, failure modes, tradeoffs.

Two weeks out: Shift to DSA consolidation. Do 20 to 30 medium and hard problems across the patterns Razorpay emphasizes: sliding window, DP on sequences, graph BFS/DFS, tree traversal. Time yourself. Practice explaining your approach before touching the keyboard.

One week out: Run two to three full mock interviews covering both LLD and HLD. SpaceComplexity runs voice-based mock interviews with rubric feedback, which is a good way to stress-test how clearly you communicate before the real thing. Also prepare one strong project walkthrough. You should be able to answer 20 minutes of drill-down questions without rehearsed lines.

Why Otherwise Strong Candidates Don't Clear It

Skipping LLD prep. The number one reason candidates clear the phone screen but not the onsite. Machine coding requires weeks of practice, not a weekend of optimism.

Treating HLD as template recitation. "Because Kafka is good for streaming" is not an answer. "Because our subscriber fan-out is write-heavy and we need durable offsets for at-least-once delivery" is an answer.

Going silent in the DSA round when stuck. Think out loud. Razorpay interviewers write down how you reason through uncertainty, not just your final answer. Silence is not mysterious. It looks like freezing.

Not knowing your past projects deeply enough. The HM round will expose any gap between what you put on your resume and what you actually understand. This is not a comfortable gap to discover in real time, with someone taking notes.

Ignoring the fintech context. Payment systems have specific constraints: idempotency, reconciliation, double-spend prevention. Knowing these signals genuine domain interest and makes your system design answers more precise. It also prevents you from proposing solutions that would let Razorpay process the same payment twice.

For more on what the full Razorpay process looks like from application to offer, see the Razorpay software engineer interview guide. If you're weighing Razorpay against another fintech, the Razorpay vs CRED interview comparison breaks down how the bars differ. For DSA fundamentals that will carry you through the coding round, DSA for backend engineers covers the patterns that matter most.