Interview experience
Razorpay interview experiences covering Online Assessment, Technical Round 1, Technical Round 2, HR / Culture. Round-wise notes, common questions, and what candidates report clears each stage.
Razorpay Interview Questions and Answers (2026)
Razorpay is India's leading fintech company for business payments, founded in 2014 by Harshil Mathur and Shashank Kumar. It offers payment gateway services, business banking, and related financial products used by millions of merchants. Engineering culture leans developer-friendly APIs and high-scale transaction systems.
Explore: Interview experience · HR interview questions · Overview · Placement papers · Preparation guide
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.
HR interview questions
Razorpay HR interview questions with sample answer frameworks - motivation, relocation, STAR stories, and culture-fit prompts.
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 |
Razorpay online assessment: quick answers
These answers are compiled from public candidate reports and prep guides, not from an official notice, and drives differ. The instruction screen of your own test is the final word.
| Question | Answer |
|---|---|
| How many questions and how long? | SDE campus tests usually run 90 minutes with MCQs on OS, DBMS, OOP and DSA plus 2-3 coding questions. A 2020 SDE-1 campus test had 3 coding questions and 15 MCQs in 1 hour 30 minutes, and a November 2024 summer intern review describes 3 LeetCode-medium problems and 10 MCQs. One on-campus intern report describes 8 MCQs (the author also mentions 15) and 3 coding questions in 1.5 hours; another intern drive set 20 MCQs on SQL, aptitude and reasoning plus 1 coding question. |
| Does it have negative marking? | Sometimes, on the MCQs. One on-campus intern test scored MCQs at +4 for a correct answer and -1 for a wrong one, with 50 marks per coding question. Other reports do not mention a penalty, so read the instructions. |
| Is there a sectional cutoff? | Not published. Coding carries far more marks than the MCQs where marks are reported, so the coding questions decide the shortlist. |
| How much is the cutoff? | Not published, and shortlists are small. In one on-campus intern drive only 8 students reached interviews and 5 were selected. Candidate-reported eligibility is 70% or 7.0+ CGPA in CS, IT or electronics with no active backlogs. |
| Which platform is it on? | Not published. A 2020 on-campus SDE-1 test ran on HackerEarth, and recent reports we found do not name a platform, so check your invite. Product Support Engineer candidates have been shortlisted through eLitmus scores. |
| Is there coding? Which topics? | Yes - 2-3 medium-to-hard problems for SDE roles. Reported examples: find two numbers from their sum and XOR, a “colour the butterflies” graph problem, arrays, strings, DP and graphs. |
| Is there an OA for every role? | No. Some 2025 Product Support Engineer (PSE) intern drives went straight to a technical interview and a hiring manager round. |
Razorpay interview questions by role
These themes come from candidate reports on GfG and Glassdoor. They show the level and style, not a fixed list.
| Role | Reported questions and topics |
|---|---|
| SDE intern (campus) | A problem shared in a document with test cases, then pseudocode; a stock buy/sell variant where you cannot buy and sell on the same day; rotting oranges (BFS). React and MySQL questions on your projects. One drive added two puzzles and a passage to summarise in your own words. |
| SDE-1 / SDE-2 | 2020 campus SDE-1 report: minimise the maximum difference after removing K elements (OA), Word Ladder II with bidirectional BFS, and multithreading vs multiprocessing; LRU cache, rate limiter, idempotent payment APIs, machine coding a pub-sub model or job scheduler, and payment-module LLD with the strategy pattern. |
| Product Support Engineer (PSE) intern | ML basics (supervised vs unsupervised, KNN), MERN project API design and schema, Node.js async and callback hell, one string and one array coding question, processes vs threads, FCFS scheduling, TCP vs UDP, SQL joins and GROUP BY with HAVING (2025 on-campus report). |
| Product Support Engineer (off-campus) | Python lists vs tuples and dictionaries, overloading vs overriding, DELETE vs DROP vs TRUNCATE, call by value vs reference, exceptions vs errors in Java, sorting and binary search complexity. |
Asked across every role: a resume project explained in depth with cross-questions, SQL, and why Razorpay.
Online Assessment
A 90-minute timed coding test on an online platform (HackerEarth in a 2020 campus report), 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. Some 2025-2026 drives also report 15 MCQs on OS, DBMS, OOP, and DSA before or alongside the coding section.
Common questions
- Array/string manipulation and dynamic-programming problems at medium difficulty
- Graph traversal problems (BFS/DFS-based)
- Merge overlapping time intervals (sort + sweep)
- First non-repeating character; maximum subarray sum in a fixed window (sliding window)
- Occasional CS-fundamentals MCQs alongside the coding problems
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
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. SDE-2+ accounts add webhook dispatchers (Kafka, dead-letter queues) and payment retry systems with exponential backoff.
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?
- LLD: payment processing module with strategy pattern for new payment methods (UPI vs card)
- 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
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
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.
Razorpay SDE vs Product Support Engineer (PSE)
Razorpay hires freshers into two different engineering tracks, and the interviews are not the same.
The SDE / product engineer track runs a coding-heavy OA (2-3 medium-to-hard problems), DSA rounds, then machine coding and payments system design. The Product Support Engineer (PSE) track supports merchants and integrations; its interviews lean on breadth - SQL, OS and networking basics, your projects, and one or two easier coding questions - and some drives skip the coding OA entirely. A 2025 on-campus PSE intern report lists a Rs 50,000 monthly stipend and an 8.5 LPA pre-placement offer, well below the SDE band on this page.
This page mainly covers the SDE track. If your offer says PSE, prepare SQL, CS fundamentals and project depth first.
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.
Q: How would you design an LRU cache for a hot merchant-config service?
Combine a HashMap from key to doubly linked list nodes with a dummy head and tail sentinel. On get, if the key exists, splice the node to the front (most recently used) and return the value; on miss, return null. On put, insert or update the node at the front; if capacity is exceeded, evict the node before the tail. All operations are O(1) average. For Razorpay-style panels, state capacity, thread-safety (single lock vs striped locks), and what happens on eviction - flush to DB or drop only. Mention TTL if configs stale quickly.
Q: Longest substring with at most K distinct characters - how do you solve it under time pressure?
Use a sliding window with a frequency map (or array for lowercase letters). Expand the right pointer, increment counts, and while distinct characters exceed K, shrink from the left decrementing counts and removing keys at zero. Track the maximum window length. Time O(n), space O(K). In interviews, narrate how the same pattern applies to streaming fraud signals or rate-abuse detection with bounded memory - a common Razorpay OA follow-up theme.
Q: How would you design a payment retry system with backoff?
Persist each payment attempt with status, attempt count, and next_retry_at. On failure, enqueue an async job rather than blocking the user thread. Retry with exponential backoff and jitter, cap max attempts, then move to dead-letter for manual reconciliation. Every retry reuses the same idempotency key so a success at the bank cannot create a second charge. Workers must handle the crash case: bank succeeded but your DB still shows pending - reconciliation jobs and webhook callbacks close the gap. Strategy pattern helps when card, UPI, and netbanking need different retry rules.
Q: What happens when payment succeeds at the bank but your service crashes before updating status?
Treat the gateway webhook or status-fetch API as the eventual source of truth, not the in-flight HTTP response to the client. Run periodic reconciliation comparing gateway settlement files to internal ledger rows. Mark payments idempotently when the same gateway transaction ID arrives twice. Never rely on the browser redirect alone - users close tabs, networks drop, and tampering is possible. This scenario appears repeatedly in Razorpay LLD and hiring-manager stories.
Frequently asked questions about Razorpay interviews
Does the Razorpay online assessment have negative marking?
Sometimes, on the MCQs. One on-campus intern test marked MCQs at +4 for a correct answer and -1 for a wrong one, with 50 marks for each coding question; other reports do not mention a penalty. Since coding carries most of the marks, solve the coding questions first.
What is the Razorpay OA pattern?
Usually a 90-minute test with CS fundamentals MCQs (OS, DBMS, OOP, DSA) and 2-3 medium-to-hard coding questions for SDE roles. Some intern drives set 20 MCQs on SQL, aptitude and reasoning plus 1 coding question. Cutoffs are not published and shortlists are small.
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?
Usually 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?
The common ones are 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.
What Razorpay interviewers score
Payments-product loops emphasize reliability under money movement. Interviewers typically score:
- Medium DSA with clean edge cases and spoken complexity.
- Fintech design instincts - idempotency, webhooks, reconciliation, failure handling in plain language.
- Ownership and pace in behavioural rounds - shipped outcomes, on-call mindset, Bengaluru preference honesty.
Soft fail modes: float money math, ignoring duplicate callbacks, or “Why Razorpay?” answers that only cite brand heat.
Does Razorpay have a machine-coding or LLD round for SDE-1?
Many candidate reports describe a dedicated machine-coding or LLD stage (often around 60-90 minutes) where you design and implement a working mini-system - notification service, payment-method module, booking inventory, and similar - with extensibility in mind. Treat runnable, modular OOP as the bar, then be ready for payments themes like idempotency and webhooks in later design or HM chats.
How to prepare for Razorpay interviews
- Loop map: Online Assessment; Technical Round 1; Technical Round 2; HR / Culture. Confirm timings from the drive mail.
- Technical depth: Drill the Q&A section until answers are spoken, not read. Know every resume project cold.
- Experiences: Study round-wise notes on the interview experience page - real prompts beat generic lists.
- HR: Three STAR stories + a specific “Why Razorpay?” on the HR page.
Who usually fits and who struggles
Good fit: You enjoy medium-hard LeetCode-style problems, can talk about idempotent payment APIs and failure retries without jargon soup, and have one project you can defend for 20 minutes. Comfort with Bengaluru relocation helps.
Harder path: You only practiced aptitude MCQs; you skip system design because “freshers don’t get design”; you cannot explain your own project’s data model. Razorpay’s OA clear rate is often cited around ~10-15% - guessing through edge cases fails quietly.
A practical Razorpay prep plan
Use this as a default four-week loop before a Razorpay drive. Adjust to your invite timeline.
- Week 1: Timed aptitude + one easy coding problem a day, plus a one-page cs fundamentals sheet. Open the Razorpay previous-year sets on this site and mark which sections ate your time. Write the timing on a sticky note. That number is more useful than a 200-problem LeetCode streak you never timed.
- Week 2: Most Razorpay drives fail people on the first timed paper or OA. Do three timed sits this week. After each one, log every miss in a two-column note: topic and why (slow, wrong formula, bad edge case, panic). The next sit should only add problems from that log.
- Week 3: Technical interviews at Razorpay usually want a clean project story, one or two CS fundamentals, and (if the process has it) a behavioral or values round. Write STAR stories on paper, not in your head. Practise “Why Razorpay?” with one concrete product, lab, or business line - not a slogan.
- Week 4: Two full mocks, then only error-log topics - no new patterns. If you still have energy, redo only the questions you failed in week 2.
10-day crash version: Days 1-4 timed DSA, days 5-7 resume projects + CS fundamentals, days 8-9 mock interviews out loud, day 10 HR STAR stories on the HR page.
Compensation notes
Candidate-reported fresher/early-career packages for Razorpay often cite ₹18-25 LPA for SDE-1 freshers. Treat forum numbers as ranges, not guarantees - confirm the written offer letter for your team and location.
Sources
Interview process details and sample questions on this site are editorially organized from public candidate reports and hiring write-ups, with round structure, prep notes, and company-specific framing added by our team. For round-by-round stories, see the Razorpay interview experience page. For OA papers and coding drills, use Razorpay on placementpapers.app. OA quick answers and role-wise questions draw on GfG’s Razorpay interview experiences (on-campus internship, SDE internship, 2020 on-campus SDE-1, PSE intern 2025 and Product Support Engineer) and a November 2024 Glassdoor summer-intern snippet seen via search.
Also prepare for
Guides often searched alongside this page: PhonePe interview questions · Paytm interview questions · Stripe interview questions · PayPal interview questions · CRED interview questions · Groww interview questions.