--- title: Razorpay Interview Questions & Process (2026) description: Real Razorpay interview questions and rounds — DSA, low-level design and the idempotency, retries and consistency questions that decide the money-handling bar — plus role-specific prep for backend, data, ML, frontend, fullstack and EM. url: https://usegreenroom.app/blog/razorpay-interview-questions last_updated: 2026-07-14 --- ← Back to blog India · Razorpay # Razorpay interview questions and process July 14, 2026 · 8 min read ![Razorpay interview questions — cover from Greenroom, the AI mock interviewer](/assets/blog/razorpay-interview-questions-hero.webp) A candidate I'll call Vikram solved a Razorpay coding round in eighteen minutes — a clean sliding-window solution, no bugs, no hints needed — and figured the hard part was over. Then the interviewer asked one follow-up: "your payment API just got the same request twice because the client retried on a timeout. What actually happens?" Vikram's code had no concept of a duplicate request. He'd built a correct algorithm for a problem that, in a payments company, doesn't end at "correct" — it ends at "correct even when the network lies to you twice." That's the real shape of **Razorpay interview questions**: DSA and low-level design are the entry fee, but the questions that actually separate candidates are about handling money safely — **idempotency, retries, and consistency** — because a single duplicated charge or a lost webhook is a real customer's real money, not a test case. I built Greenroom after freezing in exactly this kind of interview, where a clean first answer is the opening move, not the finish line. This guide covers the real Razorpay interview process, the questions that come up, and where role-specific prep (backend, data, ML, frontend, fullstack, EM) branches off. ## The Razorpay interview process Candidates consistently report the same shape for the **Razorpay interview process**: - **Online assessment** — DSA problems plus a debugging exercise, judged on working code, not just a correct final answer. - **DSA / low-level design round** — a coding problem that pivots into class design mid-round, often under a new constraint added live. - **System design round** — for senior and full-stack-leaning roles, centered on payments-domain reliability. - **Hiring manager round** — project depth, ownership, and how you reason under ambiguity. - **HR round** — compensation, notice period, and culture fit. Most reported loops run **4 rounds total** end to end. The detail that catches people off guard: Razorpay doesn't treat the DSA round as a standalone gate the way a pure product company might — expect the interviewer to take your working solution and immediately probe what happens when the underlying system fails, retries, or receives the same event twice. ## DSA questions paired with low-level design Razorpay's coding rounds pair an algorithm with a design follow-up in the same session, so prepare each as a two-part answer: - **Design a rate limiter that works across a distributed fleet of API servers.** - **Walk me through how you'd shard a write-heavy Postgres table handling transaction writes.** - **Given a stream of events, return the top-K most frequent items in a sliding window.** - **Design the classes for a wallet or ledger system, then extend it live for a new constraint (multi-currency, refunds).**
The core truth: a correct algorithm gets you into the conversation at Razorpay, not through it — interviewers use it as a launchpad into "now design this so it can't silently lose or duplicate money." Candidates who treat DSA as the finish line get caught flat-footed by the follow-up.
## The questions every round circles back to: idempotency, retries, consistency Vikram's mistake wasn't the algorithm — it was assuming payments-specific reliability was a separate topic he'd cover "if it came up." At Razorpay it comes up inside almost every technical round, not as a dedicated CS-fundamentals section: - **How do you make a payment API endpoint idempotent, so a retried request doesn't double-charge the customer?** - **A webhook delivery fails and the provider retries it — how does your system guarantee it processes the event exactly once?** - **Walk me through the trade-off between strong consistency and availability for a transaction ledger during a network partition.** - **How would you design a reconciliation job that catches a payment marked "failed" on your side but "success" on the bank's side?** These aren't trick questions — they're the actual daily reality of a payments engineer, and Razorpay's interviewers are checking whether you've internalized that a network call can time out *after* the money has already moved, which is a different failure mode than a request that simply fails. Our [system design interview guide](/blog/system-design-interview-guide-india) covers the general framework; Razorpay's version of it is this reliability lens applied to every design question. ![Razorpay interview process — online assessment, DSA/LLD, system design, hiring manager and HR](/assets/blog/razorpay-interview-questions-diagram.webp) Every Razorpay round circles back to handling money safely, not just solving the algorithm in front of you. ## System design questions For senior and full-stack-leaning roles, expect system design pulled from real payments-infrastructure constraints: - **Design a payment gateway that routes a transaction across multiple banking partners with automatic failover.** - **How would you design a system to detect and prevent duplicate payment submissions from a flaky client?** - **Design a ledger service that stays auditable and reconcilable even under concurrent writes.** - **Design a notification/webhook delivery system that guarantees at-least-once delivery to a merchant's server.** Work these through the standard skeleton: clarify scale and consistency requirements first, propose a data model, pick a strategy for idempotency keys and retries, and close with how you'd detect and reconcile drift after the fact. ## Behavioral and hiring-manager questions The hiring manager round weighs ownership and reasoning under ambiguity over a scripted values checklist: - **Tell me about a time you debugged a production incident under pressure.** - **Walk me through a technical decision you made that you'd reverse if you could.** - **Describe a project where you had to push back on a requirement — what happened?** Our [behavioral interview questions and answers guide](/blog/behavioral-interview-questions-answers-software-engineer) covers structuring these with STAR without sounding rehearsed. ## Role-specific prep: it's not one interview The DSA-plus-LLD-plus-reliability shape above is the default across roles at Razorpay, but each role weighs it differently: - **Data Engineer** — leads with SQL window functions and complex joins, then batch-vs-streaming and exactly-once delivery for pipelines. See the [Razorpay data engineer interview questions guide](/blog/razorpay-data-engineer-interview-questions) and the full [Razorpay Data Engineer interview prep](/prep/razorpay-data-engineer-interview). - **ML Engineer** — blends coding with end-to-end ML system design: data, features, serving and monitoring, plus defending metric choices like precision/recall. See the [Razorpay ML Engineer interview prep](/prep/razorpay-ml-engineer-interview). - **Engineering Manager** — weighs people leadership and outcome-driven stories as much as staying technical enough to reason about architecture. See the [Razorpay Engineering Manager interview prep](/prep/razorpay-engineering-manager-interview). - **Backend Engineer** — the process described above almost verbatim, with idempotency and consistency as the recurring thread. Full breakdown in the [Razorpay backend interview questions guide](/blog/razorpay-backend-engineer-interview-questions) and the [Razorpay Backend Engineer interview prep](/prep/razorpay-backend-engineer-interview). - **Frontend Engineer** — DSA plus frontend system design plus a JS/framework deep-dive, with the same money-safety questions surfacing in the design round. See the [Razorpay frontend interview questions guide](/blog/razorpay-frontend-engineer-interview-questions) and the [Razorpay Frontend Engineer interview prep](/prep/razorpay-frontend-engineer-interview). - **Fullstack Engineer** — API design and databases on one side, frontend deep-dive on the other, tied together in end-to-end system design. See the [Razorpay Fullstack Engineer interview prep](/prep/razorpay-fullstack-engineer-interview). ## LeetCode, GeeksforGeeks, ChatGPT — where each fits An honest map of the usual prep stack, since each solves a different piece of this loop: - **LeetCode** — right for the DSA half of the round; wrong as the main event, since the reliability-and-design follow-up is what actually separates candidates at a payments company. - **GeeksforGeeks interview experiences** — useful for calibrating what past candidates were asked at Razorpay specifically; treat them as anecdotes, not a syllabus, since accuracy and recency vary post to post. - **A distributed-systems textbook** — necessary but not sufficient; reading about idempotency keys and explaining one out loud under a follow-up question are different skills. - **ChatGPT** — solid for generating practice LLD prompts and sanity-checking a written design; it won't chain a coding question into a "what if this retries twice" question the way a real Razorpay interviewer will. - **Greenroom** — the spoken layer. [Ari, the AI interviewer](/), runs coding-into-design rounds out loud and pushes the same kind of reliability follow-up Vikram hit, scoring clarity and structure — the same things the hiring manager round is quietly grading. It won't teach you distributed systems from zero; pair it with the fundamentals above. ## How to prepare for the Razorpay interview - **Week 1:** core DSA — arrays, trees, hash maps, graphs — practiced with the assumption that every solved problem gets a reliability follow-up. - **Week 2:** low-level design — pick three prompts (rate limiter, wallet/ledger, webhook dispatcher) and design the classes out loud, twice each, then extend one live for a new constraint. - **Week 3:** payments reliability as spoken answers — idempotency keys, retry-safe APIs, exactly-once delivery, reconciliation — each explained in under ninety seconds. - **Final week:** one spoken mock chaining a coding problem into a design question into a "what if this fails twice" follow-up, plus the role-specific prep page above the night before. If Razorpay is one of several fintech companies you're targeting, the shape rhymes but the emphasis shifts — our [PhonePe interview questions guide](/blog/phonepe-interview-questions) covers a similar loop at UPI scale, our [Paytm interview questions guide](/blog/paytm-interview-questions) covers a lighter DSA bar with the same payments-reliability lens, our [Chargebee interview questions guide](/blog/chargebee-interview-questions) covers the same idempotency lens applied narrowly to recurring, subscription-based billing, our [Juspay interview questions guide](/blog/juspay-interview-questions) covers the functional-programming loop that’s unlike anywhere else in Indian fintech, and the general [system design interview guide](/blog/system-design-interview-guide-india) covers the framework both loops assume. ## Frequently asked questions ### What questions does Razorpay ask in a technical interview? Expect DSA problems paired with a low-level design follow-up in the same round (a rate limiter, a ledger), questions specifically about idempotency, retries and consistency for money-moving APIs, system design at payments scale (gateway routing, webhook delivery, reconciliation), and behavioral questions from a hiring manager about ownership and production incidents. ### How many rounds are in the Razorpay interview process? Typically an online assessment (DSA problems plus a debugging exercise), a DSA/low-level design round, a system design round for senior and full-stack-leaning roles, a hiring manager round, and an HR round — 4 rounds total in most reported cases. ### Does Razorpay ask about idempotency and payment reliability specifically? Yes, and it comes up almost everywhere rather than in one isolated round. Expect a follow-up inside a coding or design round asking how you'd make an API endpoint idempotent, guarantee exactly-once webhook processing, or reconcile a payment that shows "failed" on your side but "success" on the bank's side. ### Is the Razorpay interview process the same for every role? The DSA-plus-low-level-design-plus-reliability shape is the default across roles, but Data Engineer interviews lead with SQL and pipeline design, ML Engineer interviews blend coding with ML-system design, and Engineering Manager interviews weigh people leadership as heavily as technical depth. ### How hard is the Razorpay interview? It's a consistently high bar rather than a trick-question gauntlet. The hardest part for most candidates isn't any single round — it's realizing that "handling money safely" isn't a topic to study once, it's the lens every round is judged through. ### How is Razorpay's interview different from PhonePe's or Paytm's? All three weigh payments-reliability design heavily, but Razorpay leans hardest on pairing DSA directly with low-level design in the same round, while PhonePe's loop includes a more standalone machine-coding round and Paytm's DSA bar runs lighter relative to its system design expectations. Razorpay's loop is won by treating "it works" as the start of the real question, not the end of it. Greenroom runs mock coding-into-design interviews with Ari, chaining reliability follow-ups the way a real Razorpay panel would. Free to start.