Razorpay data engineer interview questions and process

A data engineer I'll call Priya nailed the SQL round. Clean joins, correct window function, no syntax fumbles. Then the interviewer said: "Finance says yesterday's settled amount was ₹4,12,880. Your query says ₹4,12,910. It's a thirty-rupee gap. Find it." Priya said the difference was negligible. The interviewer, quite pleasantly, replied: "It's thirty rupees of somebody's money. Which somebody?"

That moment is the whole difference between Razorpay data engineer interview questions and a generic data engineering loop. At most companies a metric that's 0.001% off is noise. At a payments company it's a defect, and the interview is largely about whether you treat it like one. I built Greenroom after freezing in an interview I'd genuinely prepared for, so this guide covers what Razorpay asks and how to reason through it out loud.

The Razorpay data engineer interview process in 2026

Razorpay hires data engineers into a few different areas — the core data platform, risk and fraud, and business/merchant analytics — and the loop is broadly consistent. What candidates report as the Razorpay data engineer interview process:

• Recruiter screen — background, notice period, and which team. Ask which one: risk skews real-time, business analytics skews modeling.
• SQL round — payment funnels, settlement windows, and at least one reconciliation-flavoured question.
• Python / coding round — practical data wrangling on webhook payloads and nested JSON. Not an algorithms contest, though basic DSA can appear in an online assessment.
• Pipeline and data modeling round — late webhooks, idempotent loads, ledger grain, slowly changing merchant dimensions.
• Hiring manager + culture — a number you got wrong, how you found out, and what you changed afterwards.

The consistent thread: money data has a right answer, and someone in finance will check it. Every round is really asking whether your pipeline produces a number you'd be willing to defend in a meeting.

Razorpay data engineer SQL interview questions

The Razorpay SQL interview questions are framed on payments data: attempts, captures, refunds, settlements, merchants. Two shapes dominate.

Build the payment funnel by merchant and method.

Conditional aggregation over payment attempts is the workhorse question, and the trap is the denominator:

SELECT m.merchant_id, p.method,
       COUNT(*) AS attempts,
       COUNT(*) FILTER (WHERE p.status IN ('authorized','captured')) AS succeeded,
       ROUND(100.0 * COUNT(*) FILTER (WHERE p.status IN ('authorized','captured'))
             / NULLIF(COUNT(*), 0), 2) AS success_rate_pct
FROM payments p
JOIN merchants m ON m.merchant_id = p.merchant_id
WHERE p.created_at >= DATE_TRUNC('day', NOW() - INTERVAL '30 days')
GROUP BY m.merchant_id, p.method
ORDER BY attempts DESC;

Then the follow-ups that decide the round. Does a retried payment count as one attempt or two — and does the answer change if the retry carried the same idempotency key? Does a customer abandoning the checkout page count as a failure? Is created_at in UTC or IST, and does the merchant's dashboard agree? Saying "success rate depends entirely on how we define an attempt, so let me state my definition" before writing anything is the strongest possible opening. Our SQL interview questions guide drills the aggregation and window-function family.

Reconcile the ledger against the bank's settlement file.

This is the signature Razorpay question, and it's a FULL OUTER JOIN in disguise:

SELECT COALESCE(l.txn_ref, b.txn_ref) AS txn_ref,
       l.amount_paise AS ledger_paise,
       b.amount_paise AS bank_paise,
       CASE WHEN l.txn_ref IS NULL           THEN 'missing_in_ledger'
            WHEN b.txn_ref IS NULL           THEN 'missing_in_bank_file'
            WHEN l.amount_paise <> b.amount_paise THEN 'amount_mismatch'
            ELSE 'matched' END AS status
FROM ledger_entries l
FULL OUTER JOIN bank_settlement_file b ON l.txn_ref = b.txn_ref
WHERE l.txn_ref IS NULL
   OR b.txn_ref IS NULL
   OR l.amount_paise <> b.amount_paise;

Say the important part out loud: mismatches are expected, not exceptional. A payment captured at 23:59 IST may land in tomorrow's bank file, so a naive same-day join manufactures false breaks. The right answer includes a matching window and a category for "timing difference, will resolve tomorrow" — that distinction is exactly what separates candidates here.

Python and webhook payload wrangling

The coding round is practical: you'll get semi-structured webhook events and be asked to flatten, dedupe or aggregate them. Payment webhooks arrive at-least-once and out of order, so the correct answer almost always involves keeping the latest state per entity rather than the last row you saw.

STATUS_RANK = {"created": 0, "authorized": 1, "captured": 2, "refunded": 3, "failed": 3}

def latest_state(events):
    """Collapse webhook events to one row per payment, ignoring stale replays."""
    latest = {}
    for e in events:
        pid = e["payload"]["payment"]["entity"]["id"]
        cur = latest.get(pid)
        if cur is None or (e["created_at"], STATUS_RANK[e["event_status"]]) > \
                          (cur["created_at"], STATUS_RANK[cur["event_status"]]):
            latest[pid] = e
    return list(latest.values())

Two things to narrate. First, the tie-break on status rank exists because two events can share a timestamp, and without it a captured can be overwritten by a replayed authorized. Second, this is in-memory: at real volume it becomes a keyed merge in Spark or a MERGE into a Delta/Iceberg table. Volunteering that scaling limit unprompted is a strong signal. The Python interview questions guide covers the language layer.

Pipeline design and data modeling for payments

The design round is where payments-specific modeling shows up, and it differs from a generic warehouse conversation in a few concrete ways:

• Grain, stated first — one row per payment attempt, per ledger entry, or per settlement? These produce different numbers, and picking without saying so is how the thirty-rupee gap happens.
• Late-arriving webhooks — an event for yesterday's payment can arrive today. That means idempotent, restatable loads (MERGE on payment ID), not append-only inserts, and a partition-rewrite strategy for the affected day.
• Slowly changing merchant dimensions — a merchant's MDR, category or risk tier changes over time, and last month's report must use last month's values. Type 2 SCD, and be ready to say why Type 1 would silently rewrite history.
• Money as integers — store paise as BIGINT. Floats in a currency column is an instant flag.
• Immutable ledger, restatable marts — never mutate a ledger entry; recompute the derived tables.
• PII and card data — the warehouse should hold tokens, not card numbers, and you should say so unprompted. Compliance is a first-class design constraint here, not an afterthought.
• Freshness — risk scoring needs streaming; the finance settlement report is a batch job with a hard correctness bar. Name the requirement before choosing the architecture.

The data engineer interview questions guide covers the ETL and warehousing fundamentals, and the Razorpay data engineer prep page has a compact round-by-round checklist.

Behavioral rounds: the number you got wrong

Razorpay's hiring-manager round has a favourite question for data engineers: tell me about a time you shipped a wrong number. Not a wrong pipeline — a wrong number, one that someone made a decision on.

They're not testing whether you've been perfect. They're testing whether you noticed, escalated fast, fixed the cause rather than patching the dashboard, and added a check afterwards. Two-minute stories, first person, real figures. "The data was off" is invisible; "a timezone bug put 40 minutes of transactions in the wrong day, finance caught it before I did, I backfilled six days and added a freshness-plus-row-count check that would have caught it in an hour" is a hire signal. Our tell me about a time you failed guide has the structure, and expect "why payments" — the answer that lands is about liking work where correctness is checkable.

StrataScratch, DataLemur, the Razorpay docs — where each fits

An honest map of the prep stack for this specific loop:

• StrataScratch and DataLemur — the best written SQL practice for funnels, window functions and conditional aggregation. Their limit: they mark a query right or wrong, and Razorpay's round is decided by the spoken follow-up about what "attempt" means.
• LeetCode — light duty. Keep a small daily habit for Python fluency and the occasional online assessment; the DE loop is not an algorithms contest.
• The Razorpay API and webhook docs — genuinely the best free preparation available. Read the payment lifecycle and webhook event list; you'll speak the interviewers' vocabulary honestly instead of guessing what authorized means.
• Designing Data-Intensive Applications — the chapters on delivery guarantees explain why late and duplicate events are a certainty, which is the assumption under half the design round.
• ChatGPT — fine for generating modeling prompts and critiquing a written design. It won't say "it's thirty rupees of somebody's money" and then wait.
• Greenroom — the spoken layer. Ari, the AI interviewer, runs the round out loud, pushes the follow-up when your funnel answer skips its own definitions, and scores structure and clarity. Fair tradeoff: Ari won't teach you Spark internals; pair it with DDIA.

How to prepare for the Razorpay data engineer interview

• Week 1: SQL on payments shapes — funnels with conditional aggregation, FULL OUTER JOIN reconciliation, settlement windows, dedup. Write each, then re-explain aloud in ninety seconds, always stating definitions first.
• Week 2: practical Python daily on nested JSON and webhook payloads — flatten, dedupe, collapse to latest state — ending each with "and here's where this breaks at scale."
• Week 3: modeling and pipelines — read the Razorpay webhook docs, then design aloud: a settlement mart, a late-webhook-tolerant load, and a Type 2 merchant dimension.
• Final week: five behavioral stories in first person including one wrong number, two full spoken mocks with correctness pushback, and the role-specific prep page the night before — not new material.

Interviewing across Razorpay's other tracks, or comparing data loops elsewhere? The Razorpay backend engineer guide covers idempotency and ledger design, the Razorpay frontend engineer guide covers the machine coding round, the general Razorpay interview questions guide covers the company-wide loop, and the Flipkart and Swiggy data engineer guides cover the nearest Indian product-company equivalents.

Frequently asked questions

What is the Razorpay data engineer interview process?

Candidates consistently report a recruiter screen, a SQL round covering payment funnels and reconciliation, a Python round focused on practical data wrangling over webhook payloads, a pipeline and data modeling round, and a hiring-manager plus culture round. Some loops add a short online assessment. Reconciliation-flavoured questions appear in almost every reported experience.

What SQL questions does Razorpay ask data engineers?

Reported questions cover payment success-rate funnels by merchant and method using conditional aggregation, reconciliation between the internal ledger and a bank settlement file using a FULL OUTER JOIN, settlement-window and timezone problems, refund and chargeback joins, and deduplication of webhook-derived tables. Follow-ups probe your definitions — what counts as an attempt, and which timezone the day boundary uses.

How do you answer reconciliation questions in a data engineering interview?

Use a FULL OUTER JOIN between the two sources on a transaction reference, and classify each row as missing on one side, missing on the other, an amount mismatch, or matched. The part that scores is acknowledging that timing differences are normal — a late-evening payment can appear in the next day's bank file — so the pipeline needs a matching window and a "will resolve tomorrow" category rather than flagging it as a break.

How does Razorpay handle late and duplicate webhook events in data pipelines?

Payment webhooks are delivered at-least-once and can arrive out of order, so loads must be idempotent and restatable. The expected design is a MERGE keyed on payment ID that keeps the latest state, a tie-break on status when timestamps collide, and a partition-rewrite strategy so a day can be recomputed when a late event lands. Append-only inserts produce duplicate revenue and fail the round.

Do I need payments domain knowledge for a Razorpay data engineer interview?

You do not need prior fintech experience, but you need the vocabulary. Know the payment lifecycle — created, authorized, captured, refunded, failed — plus settlement, chargeback, MDR and reconciliation, and know that amounts are stored in paise as integers. Razorpay's public API and webhook documentation covers all of this for free and is the single best preparation source.

Is the Razorpay data engineer interview hard?

It is a high bar, but a narrow and predictable one. The SQL sits at standard analytics difficulty and the coding round is practical rather than algorithmic. The difficulty is domain rigor — interviewers push on definitions, timezones, late events and small discrepancies, and an answer that dismisses a tiny mismatch as noise reads as a serious red flag at a payments company.