Interview experience
Razorpay Interview Questions and Answers (2026)
Overview
Section titled “Overview”Razorpay’s fresher loop is a 4-stage process where the technical rounds pull DSA problems into a payments-domain conversation, then test machine coding and system design on practical building blocks (load balancers, pub-sub systems, ledgers) rather than abstract whiteboard prompts.
Razorpay interview process at a glance
Section titled “Razorpay interview process at a glance”| Round | Duration | What they test |
|---|---|---|
| Online Assessment | 90 min | Coding (DSA) + sometimes MCQs |
| Technical Round 1 | 45-60 min | DSA + backend / payments concepts |
| Technical Round 2 | 45-60 min | Machine coding / system design (payments / ledger) |
| HR / Culture | 20-30 min | Motivation, integrity, relocation |
Online Assessment
Section titled “Online Assessment”A 90-minute timed coding test, usually on HackerRank or a similar platform, with 2-3 problems on arrays, strings, dynamic programming, and graphs. Clean, fully-passing solutions beat partially-clever ones - the shortlist bar rewards correctness and completion over elegance.
Common questions
- Array/string manipulation and dynamic-programming problems at medium difficulty
- Graph traversal problems (BFS/DFS-based)
- Merge overlapping time intervals (sort + sweep)
- Occasional CS-fundamentals MCQs alongside the coding problems
Technical Round 1
Section titled “Technical Round 1”Opens with a DSA coding problem, then moves into backend and payments-domain concepts - candidates consistently report being asked to explain payment gateway flows or webhooks in plain terms, plus a detailed walkthrough of a resume project.
Common questions
- Design an LRU cache (expected: HashMap + doubly linked list, with follow-up on complexity/edge cases)
- Implement a rate limiter (sliding window or token bucket)
- Walk through payment gateway or webhook flows - inputs, outputs, what breaks at scale
- Your project’s architecture, hardest bug, and what you’d rebuild
Technical Round 2
Section titled “Technical Round 2”Machine coding or system design, usually scoped around payment or ledger-style systems rather than a generic prompt. Candidate reports describe building a working component from scratch (load balancer, pub-sub model, job scheduler) with proper design patterns, or designing an HLD around idempotency, failure modes, and data consistency.
Common questions
- Design and build a working in-memory pub-sub model - producer, consumer, subscription, offset handling
- Design an idempotent payment API - how do you prevent double-charging on retry?
- High-level design for a job scheduler or a notification system
- Simple bottleneck and scaling questions on a wallet or transaction-ledger system
Round-by-round narratives are on the Razorpay interview experience page.
HR / Culture round
Section titled “HR / Culture round”A closing 20-30 minute conversation on motivation, integrity, and logistics. Some loops run a separate Managerial round before this focused on behavioral fit and impact. Concrete answers with a clear result outperform generic slogans here.
Common questions
- Why fintech / why Razorpay specifically?
- Tell me about a production bug or outage you helped with
- Describe an integrity or pressure scenario you’ve faced
- What’s your joining timeline?
Sample answer frameworks for each of these are on the Razorpay HR interview questions page.
Machine coding and system design at Razorpay
Section titled “Machine coding and system design at Razorpay”Razorpay’s second technical round leans harder on practical machine coding than a typical fintech loop - candidates are asked to actually build a small working system (a load balancer, a pub-sub model, a job scheduler) rather than just describe one, and are judged on class design, use of design patterns, and whether the code runs. The system-design half of the conversation is almost always framed around payments infrastructure - idempotency on retries, ledger consistency, notification delivery - so generic system-design templates land less well than a grounded, payments-specific answer.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: How would you implement a rate limiter, and which algorithm would you choose?
Token bucket is the usual production answer: each key holds a bucket of capacity N refilled at R tokens per second; a request consumes one token and is rejected when the bucket is empty. It allows short bursts up to N while enforcing an average rate of R, and it needs only two stored values per key - token count and last refill timestamp - which you can update lazily on each request. Fixed-window counters are simpler but allow up to double the limit across a window boundary. Sliding-window log is exact but stores every timestamp; sliding-window counter interpolates between two fixed windows and is the usual compromise. In a distributed setup, store counters in Redis and apply the check-and-decrement in a Lua script so it is atomic.
Q: How do you make a payment API idempotent so retries never double-charge?
The client sends a unique idempotency key with each create-payment request, typically a UUID generated once per user intent and reused across retries. The server inserts that key into a table with a unique constraint inside the same transaction that creates the payment, so a duplicate request loses the insert race and instead returns the stored response of the original. The record must also store a fingerprint of the request body so a reused key with different parameters is rejected rather than silently returning the wrong result. Keys are usually retained for at least 24 hours, and in-flight duplicates return a conflict status so the client retries with backoff rather than creating a second charge.
Q: How does a payment gateway flow work end to end?
The merchant server creates an order with the gateway and receives an order ID, which the checkout page uses to open the gateway’s UI. The customer enters card or UPI details directly with the gateway or the issuer, so the merchant never touches raw card data - that is what keeps them outside PCI-DSS scope. The gateway routes an authorisation request through the acquirer and card network to the issuing bank, adding 3-D Secure or a UPI PIN step for authentication. On success the funds are held, not moved; capture and later settlement transfer them, minus fees, on the settlement cycle. The gateway then returns a signed response to the browser and, independently, fires a server-to-server webhook.
Q: Why can you not trust the browser redirect for payment status, and how are webhooks secured?
The client-side redirect can be dropped if the user closes the tab, loses network, or tampers with the response, so it is a UX signal, not a source of truth. The authoritative status comes from the gateway’s server-to-server webhook, backed by an explicit status-fetch API call as a fallback. Webhooks are secured by verifying an HMAC-SHA256 signature computed over the raw request body with a shared secret, compared using a constant-time function - never by trusting the payload alone or the source IP. Because gateways retry until they see a success response, the handler must be idempotent, keyed on the event ID, and should acknowledge quickly while doing heavy work asynchronously.
Q: Why do payment systems use a double-entry ledger instead of updating a balance column?
A double-entry ledger records every movement as at least two entries - a debit and a credit - that sum to zero across accounts, so the books are self-checking: if the sum of all entries in a currency is not zero, something is wrong. Entries are append-only and immutable, which gives a full audit trail and lets you reconstruct any balance at any point in time by replaying entries, something a mutable balance column destroys. A balance column also invites lost updates under concurrency and leaves no evidence of what changed. In practice you keep a materialised balance for fast reads, but derive it from the ledger and reconcile it continuously against the entry sum.
Q: How would you design an in-memory pub-sub system?
Model topics as an append-only list of messages with a monotonically increasing offset, plus a map from topic to its subscribers. Publishers append and get back the assigned offset; each subscriber tracks its own committed offset, so consumers read independently and a slow consumer never blocks a fast one. Deliver by having each consumer poll from its offset, or by pushing to a bounded per-consumer queue with a defined overflow policy. For thread safety, guard each topic separately rather than with one global lock, and use a condition variable to wake blocked consumers on publish. Retention needs an explicit policy - drop by size or age - or the topic grows without bound. Delivery here is at-least-once, since a consumer can process a message and crash before committing its offset.
Q: How would you design a distributed job scheduler?
Store jobs in a table with a next_run_at timestamp indexed for range scans, and have worker nodes poll for rows where next_run_at is due. To stop two workers picking the same job, claim it atomically - SELECT ... FOR UPDATE SKIP LOCKED, or a conditional UPDATE that flips status from pending to running and sets a lease expiry, checking the affected row count. A lease with a heartbeat lets you reclaim jobs from a worker that dies mid-execution. Retries use exponential backoff with jitter and a maximum attempt count, after which the job moves to a dead-letter queue. Because a job can run twice if a worker stalls past its lease, the job body itself must be idempotent.
Q: What is the difference between optimistic and pessimistic locking, and which fits a payments write path?
Pessimistic locking takes a row lock up front with SELECT ... FOR UPDATE, so other transactions block until the first commits. It is correct under heavy contention but serialises access and risks deadlocks if transactions lock rows in inconsistent orders. Optimistic locking reads a version column, then writes with WHERE version = <value read>, incrementing it - if zero rows are affected, someone else won and the caller retries. Optimistic is better where conflicts are rare because it holds no locks; pessimistic is better for hot rows such as a single merchant wallet balance during a sale, where retry storms would otherwise dominate. Either way, always acquire multiple locks in a consistent global order.
Frequently asked questions about Razorpay interviews
Section titled “Frequently asked questions about Razorpay interviews”What is the Razorpay interview process for freshers?
Razorpay’s process typically runs 4 stages: 1. Online Assessment (90 min) - 2-3 coding problems on arrays, strings, dynamic programming, and graphs, sometimes with MCQs. 2. Technical Round 1 (45-60 min) - DSA coding (LRU cache, rate limiter, interval-merge style problems) plus backend/payments-domain discussion. 3. Technical Round 2 (45-60 min) - machine coding or system design, usually scoped to payment/ledger-style systems. 4. HR/Culture (20-30 min) - motivation, integrity, relocation. Some drives add a separate Managerial round between Technical Round 2 and HR. Total timeline is roughly 2-4 weeks.
What questions are asked in Razorpay interviews?
Coding questions commonly include designing an LRU cache (HashMap + doubly linked list), implementing a rate limiter (sliding window or token bucket), and merging overlapping intervals (sort + sweep). Machine-coding and system-design rounds lean on practical building blocks - load balancers, pub-sub/notification systems, job schedulers - built with clean OOP and design patterns rather than a whiteboard-only discussion. Technical rounds also probe payments-domain concepts like payment gateway flows, webhooks, and idempotency in plain language. HR rounds ask why fintech/Razorpay and about a production bug or outage you helped with.
How many rounds are there in the Razorpay interview?
Razorpay typically runs 4 stages: an Online Assessment, two Technical Rounds (DSA + domain, then machine coding/system design), and an HR/Culture round. Some drives insert a separate Managerial round focused on behavioral fit and impact discussion between the technical rounds and HR - confirm the exact structure from your placement cell or recruiter.
What is the Razorpay technical interview like?
Technical Round 1 (45-60 min) opens with a DSA coding problem - candidates report being asked to design an LRU cache or a rate limiter - then moves into a plain-language discussion of payment gateway flows or webhooks. Technical Round 2 shifts to machine coding or system design: candidates describe being asked to build a working component (load balancer, pub-sub model, job scheduler) with proper design patterns, or to design a payment/ledger-style system covering idempotency, failure modes, and data consistency. Both rounds include a resume deep-dive - architecture decisions, trade-offs, and how things were actually built on your past projects.
How should I prepare for Razorpay interviews?
Clear the OA with clean, fully-passing solutions rather than partial cleverness. Revise OOPs and SQL, since fundamentals questions open a lot of Razorpay panels. Practice machine coding - build a small working system (rate limiter, booking system) end-to-end with clean class design, not just a working main(). For domain questions, be ready to explain payment gateway flows or webhooks in plain language (inputs, outputs, what breaks at scale). Prepare one detailed project story (architecture, hardest bug, what you’d rebuild) and concrete HR answers using STAR.
What mistakes do candidates commonly make in Razorpay interviews?
Coding before clarifying constraints, treating the HR/managerial round as a formality, and reaching for system-design jargon without a simple, concrete bottleneck story. Candidate reports consistently note that a coherent explanation of a payments concept - and a machine-coding solution that actually compiles and runs - beats a high CGPA paired with weak communication.