Does Razorpay SDE-1 have a system design round?

No, Razorpay SDE-1 does not include a system design round. The focus is on DSA and coding.

Razorpay

Q: How many rounds are there in Razorpay SDE-1 interviews?

Razorpay SDE-1 typically has 4 rounds. Razorpay SDE-1 interviews are heavier on machine coding than most Indian startups at this level — the LLD round sets the bar for the entire loop. Expect fintech-framed DSA, a SQL round that tests ACID isolation not just query syntax, and interviewers who want to see you handle payment edge cases (duplicate transactions, negative balances) explicitly. Four rounds, no system design, but the machine coding bar is closer to SDE-2 at other companies.

Q: What topics are tested in Razorpay SDE-1 interviews?

Razorpay SDE-1 interviews test: OOP, Concurrency Concepts, Data Validation, Domain Modeling, Arrays, Sliding Window, Union-Find, HashMaps.

Fintech · Bengaluru, India

Razorpay is India's leading payments infrastructure company, powering payment acceptance for 8M+ businesses.

Related Companies

Rounds: 4 rounds
Focus: Machine Coding + DSA + SQL
System Design: No
Timeline: 2–3 weeks to offer

Role:

Rounds 1–2 are fully visible · Round 3+ unlocked with a free account

Machine Coding

Round 1 of 4LLD / OOD

90 min

OOPConcurrency ConceptsData ValidationDomain Modeling

The round that decides the loop. Razorpay gives you a deliberately vague problem — deriving functional and non-functional requirements yourself is part of the evaluation. Recent SDE-1 problems include in-memory relational databases, rate limiters, and expense-sharing systems. Jumping straight to code without clarifying requirements is the fastest way to get rejected here, even if the final implementation works.

Medium

What to expect

e.g., 'Implement an in-memory relational DB' — support CREATE TABLE with fixed schema, multiple databases, INSERT/UPDATE/DELETE, and field-level indexing with auto-incremented IDs
e.g., 'Build a Rate Limiter' — sliding window or token bucket, configurable per-user limits, concurrent request handling
e.g., 'Design a Transaction Ledger' — debit/credit entries, balance computation, idempotent entry insertion, rollback support
Interviewer adds requirements mid-round: 'Now support multi-database transactions' — your design must extend without a rewrite
Compilable, runnable code is required — pseudocode is a rejection at Razorpay regardless of whether the design is correct
Tests are mandatory; the happy path alone is not enough — concurrent inserts, duplicate transaction IDs, and negative balance scenarios are explicitly graded

Practice on KnowEase.AI

LLD Practice →

Tip: Spend the first 10 minutes asking clarifying questions out loud — Razorpay interviewers score this explicitly. The problem statement is vague on purpose. Candidates who jump to code immediately signal they can't gather requirements, which is fatal in a payments domain where missing a constraint means moving money incorrectly.

Coding Round

Round 2 of 4DSA / Coding

60 min

ArraysSliding WindowUnion-FindHashMaps

1–2 medium DSA problems, almost always framed in a payment or transaction context. The framing is not cosmetic — Razorpay expects you to model the domain correctly (e.g., recognizing that 'duplicate transaction within 60 seconds' is a sliding window problem, not a brute-force scan). Name the pattern out loud before writing code; silent problem-solving is a red flag here.

Medium

What to expect

e.g., 'Given a stream of payment events, find all pairs of duplicate transactions within a 60-second window' — sliding window with HashMap deduplication
e.g., 'Reconstruct account history from a list of debit/credit events; detect if any cycle exists' — DFS with visited coloring on a directed graph
e.g., 'Find the top K merchants by transaction volume in the last N minutes from a live stream' — sliding window + min-heap
Follow-up: 'What happens when two transactions share the exact same timestamp? How does your solution behave?' — most candidates don't handle this
Complexity discussion: 'Why does O(n log n) matter here at Razorpay's transaction volume of 50M/day?'

Practice on KnowEase.AI

DSA Practice — Sliding Window →DSA Practice — Arrays →

Technical + SQL Round

Round 3 of 4SQL Round

60 min

Window FunctionsCTEsTransaction IsolationIndexingGraph Cycle Detection

Razorpay's most distinctive round — SQL is a genuine first-class skill here. The SQL portion tests window functions and CTEs on payment-domain tables (merchants, transactions, settlements). The theory portion goes straight to ACID isolation levels and when to use each in a real payment flow. Candidates who know only basic SELECT/JOIN syntax get found out quickly; candidates who've never explained READ COMMITTED vs SERIALIZABLE in a payment context almost always stumble.

What to expect

SQL: 'Find merchants with more than 3 failed payments in the last 24 hours, ranked by total failed amount' — window functions, CTEs, timestamp arithmetic
SQL: 'Write a query to show the running balance for each account from a transactions table ordered by created_at' — SUM() OVER (PARTITION BY account_id ORDER BY created_at)
SQL: 'Find merchants where failed_amount/total_amount exceeded 5% in any rolling 7-day window' — window frame clauses with date arithmetic
Theory: 'What is the difference between READ COMMITTED and SERIALIZABLE isolation? Which do you use for a payment debit and why?'
Indexing: 'This payments table has 100M rows and your fraud query is slow — which index do you add and what's your reasoning?'
DSA portion: e.g., 'Detect a cycle in a payment dependency graph' — DFS with visited coloring, or Union-Find

Full details unlocked with a free account

Hiring Manager

Round 4 of 4Behavioral / HM

45 min

BehavioralFintech DomainIncident Ownership

More technical than candidates expect. The manager picks one project from your resume and drills into it — database choices, failure modes, what you'd redesign now, and how you handled incidents. The fintech motivation question is genuine: Razorpay engineers work in a domain where a bug moves real money, and the HM is assessing whether you've internalized that gravity.

What to expect

Deep project drill: 'Why did you choose MySQL over Postgres here? What failure mode did you hit at scale and how did you fix it?'
Incident ownership: 'Tell me about a production bug you caused — specifically, how did you ensure no data was corrupted or money lost during recovery?'
Domain fit: 'What draws you to payments infrastructure over a product company? What's your mental model of how a UPI transaction actually flows?'
Trade-off question: 'How do you balance shipping a feature fast against ensuring it handles edge cases that only matter 0.01% of the time — but in payments, that 0.01% is thousands of transactions per day?'

Full details unlocked with a free account

Questions — coming soon.

Company Guide — coming soon.

About Razorpay SDE-1 Interviews

Razorpay SDE-1 interviews are heavier on machine coding than most Indian startups at this level — the LLD round sets the bar for the entire loop. Expect fintech-framed DSA, a SQL round that tests ACID isolation not just query syntax, and interviewers who want to see you handle payment edge cases (duplicate transactions, negative balances) explicitly. Four rounds, no system design, but the machine coding bar is closer to SDE-2 at other companies.

See interview loops for other companies:

Microsoft Amazon Uber Flipkart Walmart Coupang Rippling Rubrik Target

Start your Razorpay SDE-1 prep plan

Practice the exact topics tested in each round — DSA, system design, SQL, and LLD.

Start free →