Paytm backend interview questions and process

"A user pays a merchant ₹500 from their wallet. Draw it." He drew two boxes and an arrow: debit the user, credit the merchant. The interviewer asked what happens if the process dies between those two writes. The arrow, it turned out, was hiding the entire interview.

That question — what happens between the debit and the credit — is the centre of gravity for Paytm backend interview questions. Paytm runs wallets, merchant settlements, refunds and reconciliation against banks, so the design rounds are less interested in how many requests per second you can serve and much more interested in whether the money adds up at the end of the day. Around that sit competent DSA rounds and a Java bar that goes well past annotations. I built Greenroom after freezing in an interview I had prepared hard for, so this guide covers what Paytm asks and how to reason through it out loud.

The Paytm backend engineer interview process

• Recruiter screen — level calibration and org: payments, wallet, lending, commerce, ads, or a platform team. The emphasis genuinely differs.
• DSA rounds — one or two, at LeetCode medium: arrays and hashing, trees, graphs, intervals, sliding window, heaps.
• Java and low-level design round — language depth plus designing classes for a small system.
• System design round — wallet, settlement, refunds, reconciliation, or a transaction history service.
• Hiring manager round — ownership, an incident you handled, and the scale you have actually operated rather than read about.

Our Paytm interview questions guide covers the company-wide process.

The DSA rounds

Medium difficulty and fairly standard: two-sum variants and hashing, sliding window, tree traversals, graph BFS and DFS, intervals, heaps and top-K, and basic dynamic programming.

What Paytm interviewers tend to add is a production follow-up — what if this input is a stream, what if it does not fit in memory, how would you make it concurrent. Finishing each practice problem with those three questions answered aloud is worth more than solving two extra problems. Our DSA coding interview preparation guide covers the list.

Java and low-level design

Most Paytm backend teams are Java and Spring, and the questions go past syntax:

• Collections — HashMap internals including resizing and treeification, ConcurrentHashMap versus a synchronized map, and when ArrayList is the wrong choice.
• Concurrency — the thread pool you would choose and why, CompletableFuture, volatile versus synchronized, and what a race in a balance update actually looks like.
• JVM basics — heap versus stack, garbage collection generations, and what causes a memory leak in a long-running service.
• Spring internals — bean lifecycle and scopes, how dependency injection is wired, transaction propagation, and why @Transactional silently does nothing on a self-invocation. That last one is asked constantly.
• Exception design — checked versus unchecked, and what you would actually surface to a caller.

Our Java interview questions and Spring Boot interview questions guides cover this ground.

The low-level design half asks for classes: a wallet service, a coupon engine, a rate limiter, a notification dispatcher. Define interfaces first, keep rule evaluation separate from storage, and expect a requirement to be added halfway through.

System design: making the money add up

This is the round that decides the loop, and the vocabulary is specific.

• Never two writes without a plan. The debit-then-credit problem is solved with a single transaction where possible, and with an outbox or saga pattern with compensating actions where it is not. Say which you are choosing and why.
• Idempotency everywhere. Every payment API takes a client-supplied key; a retry returns the stored result rather than moving money twice. Describe where the key lives and what happens when two requests with the same key arrive concurrently.
• Double-entry ledger. Append-only entries, every movement recorded twice, balances derived rather than mutated. This is the single most valuable concept to be fluent in for a Paytm design round.
• Reconciliation. At end of day your ledger and the bank's file disagree about some transactions. Describe the job that detects it, the classification of break types, and what is automated versus escalated.
• Refunds and reversals. A refund is a new entry, not a deletion. Partial refunds, refunds of a failed payment, and refunds after settlement all differ.
• Settlement. Money owed to merchants, batched and paid on a cycle, with holds for disputes. Knowing this exists separates candidates who have worked in payments from those who have not.
• Consistency per feature. A displayed wallet balance can lag by a second; a debit cannot double-spend. Say which needs what.
• Failure isolation and back-pressure. Timeouts, circuit breakers, and what the app shows when the ledger service is slow rather than down.

// the two-write problem: claim, then move, then confirm — never a bare pair of updates
@Transactional
public TransferResult transfer(String idempotencyKey, long userId, long merchantId, long paise) {
    Optional<TransferResult> prior = ledger.findByKey(idempotencyKey);
    if (prior.isPresent()) return prior.get();          // replay, do not move money again

    Account from = accounts.lockForUpdate(userId);      // row lock, ordered to avoid deadlock
    Account to   = accounts.lockForUpdate(merchantId);
    if (from.balance() < paise) throw new InsufficientFunds();

    ledger.append(new Entry(idempotencyKey, userId, -paise));   // double entry:
    ledger.append(new Entry(idempotencyKey, merchantId, paise)); // both, or neither
    return ledger.recordResult(idempotencyKey, SUCCESS);
}

Then volunteer the two follow-ups they were going to ask: "locks must always be taken in a consistent order or two concurrent transfers deadlock, and if the merchant account lives in a different service this stops being one transaction and becomes a saga with a compensating entry." Our distributed systems interview questions and caching strategies guides cover the surrounding vocabulary.

The hiring manager round

Expect: an incident you owned end to end, a time you shipped a bug that reached users, how you handle a production issue at 2am, a disagreement with a product manager, and the honest scale of what you have run.

Be precise about scale. Inflated numbers get probed — "what was your p99, and what was the peak QPS you personally saw?" — and the follow-up is where vague claims fall apart. Our behavioral interview questions guide covers the structure.

Where each prep option actually helps

• LeetCode — mediums, each finished with the three production follow-ups spoken aloud.
• Designing Data-Intensive Applications — the best source for the consistency and failure vocabulary this loop rewards.
• Any public writing on double-entry ledgers — a single afternoon on this concept changes the design round completely, and very few candidates do it.
• Baeldung and the Spring documentation — for transaction propagation and bean lifecycle, which get asked precisely.
• ChatGPT — good for generating follow-ups on a design you have written down. It will not ask what happens between the debit and the credit at the moment you have drawn an arrow.
• Greenroom — the spoken layer. Ari, the AI interviewer runs the design round out loud and pushes on the failure path. Honest tradeoff: Ari will not review your Java, so pair it with real practice.

How to prepare for the Paytm backend interview

• Week 1 — LeetCode mediums, each closed out with stream, memory and concurrency follow-ups spoken aloud.
• Week 2 — Java depth: HashMap internals, concurrency primitives, GC, and Spring transaction propagation until you can explain the self-invocation trap in ninety seconds.
• Week 3 — design a wallet, a settlement pipeline and a reconciliation job out loud, with idempotency, double-entry and a compensating action in each.
• Final week — five behavioral stories with real numbers, two full spoken mocks, and a precise account of the scale you have actually operated.

Interviewing across comparable loops? The Razorpay backend engineer guide covers merchant-side payments, the PhonePe backend engineer guide covers UPI-scale systems, and the CRED backend engineer guide covers a harder algorithm bar with a low-level design round.

Frequently asked questions

What is the Paytm backend engineer interview process?

Candidates report a recruiter screen, one or two DSA rounds at LeetCode medium, a Java and low-level design round covering language depth plus a class design exercise, a system design round centred on wallets, settlement, refunds or reconciliation, and a hiring manager round on ownership and the scale you have actually operated. Emphasis differs by org across payments, wallet, lending, commerce and ads.

What system design questions does Paytm ask?

Prompts are money-shaped: design a wallet, a settlement pipeline, a refund flow, a reconciliation job or a transaction history service. Strong answers cover how you avoid a bare pair of writes using a single transaction or an outbox or saga with compensating actions, idempotency keys on every payment API, an append-only double-entry ledger with derived balances, end-of-day reconciliation against a bank file including break classification, refunds as new entries rather than deletions, and per-feature consistency.

What Java questions does Paytm ask backend engineers?

Expect mechanism-level depth: HashMap internals including resizing and treeification, ConcurrentHashMap versus a synchronized map, thread pool selection and CompletableFuture, volatile versus synchronized and what a race in a balance update looks like, heap versus stack and garbage collection generations, and Spring specifics such as bean lifecycle, transaction propagation, and why an @Transactional annotation silently does nothing on a self-invocation.

What is a double-entry ledger and why does it come up in payments interviews?

A double-entry ledger records every movement of money as two append-only entries that must sum to zero, with balances derived by summing entries rather than being mutated in place. It comes up because it makes correctness auditable: you can prove what happened, detect a break during reconciliation, and issue a refund as a new compensating entry rather than by editing history. Spending an afternoon on this concept noticeably changes how a Paytm design round goes.

How hard is the Paytm DSA round?

It sits at LeetCode medium and is fairly standard in coverage — hashing, sliding window, tree traversals, graph BFS and DFS, intervals, heaps and basic dynamic programming. What Paytm interviewers add is a production follow-up on each problem, asking what changes if the input is a stream, if it does not fit in memory, or if it has to run concurrently, so practise closing out every problem with those three answers.

What does the Paytm hiring manager round ask?

Expect an incident you owned end to end, a bug you shipped that reached users, how you handle a production issue in the middle of the night, a disagreement with a product manager, and the honest scale of the systems you have run. Be precise about numbers, because inflated scale claims get probed with follow-ups about your actual p99 and the peak traffic you personally saw.