Interview experience
Paytm Interview Questions and Answers (2026)
Overview
Section titled “Overview”Paytm’s fresher loop is a tight 4-stage process where the technical rounds consistently pull DSA problems (LRU cache, rate limiters) into a payments-domain conversation - wallet transactions, UPI flows, idempotent APIs - rather than testing DSA and domain knowledge separately.
Paytm interview process at a glance
Section titled “Paytm 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 | 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. Clean, fully-passing solutions beat partially-clever ones - the shortlist bar rewards correctness and completion over elegance.
Common questions
- Merge overlapping time intervals (sort + sweep)
- Array/string manipulation problems at medium difficulty
- 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 wallet transactions or UPI flows 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 wallet transactions or UPI 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”System-design focused, usually scoped around payment or ledger-style systems rather than a generic prompt - idempotency, failure modes, and data consistency come up even at fresher depth.
Common questions
- Design an idempotent payment API - how do you prevent double-charging on retry?
- Discuss idempotent-payments failure modes and how you’d detect/recover from them
- Simple bottleneck and scaling questions on a wallet or transaction-ledger system
Round-by-round narratives are on the Paytm interview experience page.
HR / Culture round
Section titled “HR / Culture round”A closing 20-30 minute conversation on motivation, integrity, and logistics. Concrete answers with a clear result outperform generic slogans here.
Common questions
- Why fintech / why Paytm 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 Paytm HR interview questions page.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: How do you implement an LRU cache in O(1)?
Pair a hash map from key to node with a doubly linked list kept in recency order, most-recently-used at the head. get() looks the node up through the map in O(1) and moves it to the head; put() inserts at the head and, when size exceeds capacity, unlinks the tail node and deletes its key from the map. The list must be doubly linked because removing an arbitrary node in constant time needs a prev pointer - with a singly linked list you would scan O(n) to find the predecessor. Space is O(capacity). A common follow-up is thread safety: guard the structure with a lock, or use a concurrent design with per-segment locking.
Q: Implement a rate limiter. Which algorithm would you choose and why?
Token bucket keeps a token count and last-refill timestamp per key, refilling at a fixed rate up to a burst capacity - it permits controlled bursts, which suits real API traffic, and stores only two numbers per client. A fixed-window counter is simplest but allows up to twice the intended rate across a window boundary. A sliding-window log is exact but stores every timestamp, so memory grows with traffic; a sliding-window counter blends the previous and current window and is usually the right compromise. In a distributed setup, state lives in Redis and the check-and-decrement must run as an atomic Lua script or INCR-with-expiry, otherwise two application nodes can both approve the same last token.
Q: How do you merge overlapping intervals, and what is the complexity?
Sort intervals by start time, then sweep left to right keeping a current merged interval. If the next interval starts at or before the current end, extend the current end to the max of the two ends; otherwise emit the current interval and begin a new one. Time is O(n log n), dominated by the sort, with O(n) output space. Clarify up front whether touching intervals such as [1,3] and [3,5] should merge - interviewers deliberately leave that ambiguous to see whether you ask.
Q: What is an idempotent payment API, and how do you build one?
Idempotent means repeating the same request produces the same result and only one charge - necessary because a client that times out cannot tell whether the payment went through. The client sends a unique Idempotency-Key (a UUID) per logical payment; the server inserts that key into a uniquely indexed table inside the same database transaction that debits the wallet and writes the ledger entries. If the insert succeeds, process and store the response against the key; if it violates the unique constraint, return the previously stored response rather than charging again. Splitting the existence check and the charge into two separate statements reopens the race window, so the atomicity of the single transaction is what actually provides the guarantee.
Q: Walk through what happens in a UPI payment, end to end.
The payer opens a UPI app, which resolves the payee’s VPA (the name-at-bank handle) to an account through the NPCI switch, then authenticates the payer with their UPI PIN, which is validated by the payer’s issuing bank rather than the app. NPCI routes a debit request to the payer’s bank (the remitter) and a credit request to the payee’s bank (the beneficiary), acting as the central switch and settlement layer between them. The user sees near-instant confirmation while interbank settlement happens in batch cycles behind the scenes. The failure mode that matters in interviews is the deemed-approved or pending case, where the debit succeeded but the credit response is unknown - resolved by reconciliation against NPCI files and an automatic reversal if the credit never lands, which is exactly why the whole flow is built around unique transaction references.
Q: Explain ACID and why isolation level matters for a wallet debit.
Atomicity means the transaction commits fully or not at all, so a debit cannot persist without its matching credit. Consistency means constraints such as a non-negative wallet balance hold before and after. Isolation means concurrent transactions do not see each other’s uncommitted state, tunable from READ COMMITTED through SERIALIZABLE. Durability means a committed transaction survives a crash via the write-ahead log. For wallet debits, isolation is the subtle trap: under READ COMMITTED two concurrent withdrawals can each read the same balance of 100, each judge a withdrawal of 80 valid, and both commit - so you need SELECT ... FOR UPDATE to lock the row, or an optimistic check with a version column and a retry.
Q: What are the four pillars of OOPS, with examples?
Encapsulation bundles state with the methods that act on it and hides internals - a Wallet class exposes debit() and credit() but never a public balance setter, so no caller can corrupt the balance. Abstraction exposes only the essential contract: a PaymentGateway interface declares charge() without revealing which acquirer is behind it. Inheritance lets a subtype extend a base type, as when UpiTransaction extends Transaction. Polymorphism lets one reference type invoke many implementations, so iterating a list of Transaction objects dispatches to the right settle() at runtime. Answer with the example attached to each pillar - reciting the four words alone reads as memorised.
Q: Write a SQL query to find users whose total transaction amount exceeds a threshold this month.
Aggregate with GROUP BY and filter the aggregate with HAVING, not WHERE: SELECT user_id, SUM(amount) AS total FROM transactions WHERE status = 'SUCCESS' AND created_at >= date_trunc('month', CURRENT_DATE) GROUP BY user_id HAVING SUM(amount) > 10000 ORDER BY total DESC; The key points interviewers look for are filtering on status so failed and pending attempts are not counted, using HAVING for the post-aggregation condition since WHERE is evaluated before grouping, and writing the date filter as a range against created_at so an index on (user_id, created_at) can be used - wrapping created_at in a function such as MONTH(created_at) would prevent the index from being used.
Frequently asked questions about Paytm interviews
Section titled “Frequently asked questions about Paytm interviews”What is the Paytm interview process for freshers?
Paytm’s SDE/Backend Engineer process for freshers typically runs 4 stages: 1. Online Assessment (90 min) - DSA coding, sometimes with MCQs. 2. Technical Round 1 (45-60 min) - DSA plus backend/payments-domain concepts. 3. Technical Round 2 (45-60 min) - system design, often framed around payments or ledger systems. 4. HR/Culture (20-30 min) - motivation, integrity, relocation. Timeline is usually 2-4 weeks from application to offer for campus drives.
What questions are asked in Paytm interviews?
Common coding questions include designing an LRU cache (HashMap + doubly linked list), implementing a rate limiter (sliding window or token bucket), and merging overlapping time intervals (sort + sweep). Technical rounds also probe domain concepts specific to Paytm’s business - wallet transactions, UPI flows, and idempotent payment APIs - in plain-language terms rather than buzzwords. HR rounds ask why fintech/payments, and about a production bug or outage you helped with.
How many rounds are there in the Paytm interview?
Paytm typically runs 4 stages: an Online Assessment, two Technical Rounds (DSA+domain, then system design), and an HR/Culture round. Some drives merge HR into the second technical round instead of running it separately - confirm the exact structure from your placement cell.
What is the Paytm technical interview like?
Technical Round 1 (45-60 min) mixes a DSA coding problem with backend/payments-domain discussion - candidates report being asked to design an LRU cache or a rate limiter, followed by a plain-language discussion of wallet transactions or UPI flows. Technical Round 2 shifts to system design, often centered on payment/ledger-style systems (idempotency, failure modes, data consistency). Both rounds also include a detailed project discussion covering stack choices and the hardest bug you’ve debugged.
How should I prepare for Paytm interviews?
Clear the OA with clean, fully-passing solutions rather than partial cleverness - timed practice beats last-minute topic-hopping. Revise OOPs and SQL, since fundamentals questions open a lot of Paytm panels. For domain questions, be ready to explain wallet transactions or UPI flows in plain language (inputs, outputs, what breaks at scale) rather than reciting buzzwords. Prepare one detailed project story (architecture, hardest bug, what you’d rebuild) and concrete HR answers - one story with a clear result beats several vague claims.
What mistakes do candidates commonly make in Paytm interviews?
Coding before clarifying constraints, treating the HR 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 wallet-transaction trade-offs beats a high CGPA paired with weak communication.