razorpay Data Engineer Interview: Questions, Experience & Prep (2026)

Razorpay is India's leading payments infrastructure company, processing transactions for millions of merchants and businesses. Their data engineering teams work on high-stakes problems: real-time payment event streams, fraud detection pipelines, merchant settlement reconciliation, and business intelligence at scale. As of July 2026, Razorpay has 42 open Data Engineer roles, making it one of the more active fintech hirers in the market right now.

The interview process typically runs a few rounds. Candidates report an initial recruiter screening, followed by SQL or coding assessments, a system design round focused on data pipelines, and a final conversation with a hiring manager or senior engineer. Exact structure varies by team and level.

Salary bands for Data Engineers across India:

Razorpay is reported on Glassdoor and in publicly reported offer discussions to pay competitively within or above these bands, particularly for senior engineers with strong streaming experience.

These questions come up repeatedly in Razorpay Data Engineer interviews, based on what candidates report:

1. Walk me through a data pipeline you built from scratch, end to end.
2. How would you design a real-time fraud detection pipeline for payment transactions?
3. How do you handle late-arriving or out-of-order events in a streaming system?
4. What is the difference between Kafka and a traditional message queue? When would you pick each?
5. How would you design a data warehouse to support merchant analytics at scale?
6. Describe a time a data pipeline failed in production. What happened and what did you do?
7. How do you handle schema evolution and data quality in a high-velocity ingestion pipeline?
8. What is your approach to partitioning and indexing large transactional datasets?
9. How would you build a reconciliation system to track payment settlements across UPI, cards, and wallets?
10. Explain the CAP theorem. How does it affect design decisions at a fintech company?
11. How do you handle PII and sensitive payment data inside your pipelines to stay compliant?
12. What monitoring and alerting would you put in place for a critical payment data pipeline?

Q: Walk me through a data pipeline you built from scratch.

*Situation:* My team needed near-real-time reporting on user transactions for a lending product. Reports were running as overnight batch jobs, causing an unacceptable lag that the business team flagged repeatedly.

*Task:* I was responsible for redesigning the ingestion and transformation layer to bring latency down to minutes.

*Action:* I replaced the nightly ETL with a Kafka-based streaming pipeline. Events were produced by the application layer and consumed by a Spark Streaming job that wrote to a partitioned Parquet layer on cloud storage. I introduced schema validation at the consumer level using Avro and built a dead-letter queue for malformed records. I also added row-count and null-rate checks in the transformation step to catch data quality issues early.

*Result:* End-to-end latency dropped to under five minutes. The business team could see transaction reports refresh in near-real-time, and data quality incidents dropped significantly because bad records were caught at ingestion rather than discovered downstream.

---

Q: Describe a time a data pipeline failed in production.

*Situation:* A downstream analytics dashboard went blank for a merchant-facing report. The pipeline had silently stopped writing data several hours earlier and no alert had fired.

*Task:* I was on-call and needed to identify the root cause and restore data with no duplicates.

*Action:* I checked Kafka consumer group lag first and saw it had spiked sharply. Tracing back, I found a schema change had been deployed without a corresponding update to the Avro schema registry, causing deserialization errors that were being silently swallowed. I fixed the schema, replayed the affected offset range from Kafka, and verified idempotency in the write step to avoid double-counting. I then added an alert on consumer lag above a threshold so we would catch this class of failure earlier next time.

*Result:* Data was restored cleanly within a couple of hours. The monitoring gap was closed, and we introduced a schema compatibility check in our CI pipeline so the same issue could not reach production again.

---

Q: How do you ensure data quality in a high-velocity pipeline?

*Situation:* I was working on a pipeline ingesting payment events from multiple source systems, each with different data formats and reliability characteristics.

*Task:* I needed to implement data quality checks without adding significant latency to the pipeline.

*Action:* I built a lightweight validation layer at the entry point. It checked schema conformance, null rates on key fields, value range checks for amounts, and referential integrity against a merchant ID lookup. Failed records went to a dead-letter queue with a reason code attached. I also added downstream reconciliation checks that compared record counts between the raw and transformed layers on a rolling window basis.

*Result:* We caught a meaningful share of incoming records with quality issues before they polluted downstream tables. Business users stopped raising data quality tickets, and the team had clear visibility into which source systems were sending bad data so they could be fixed at the root.

For system design questions: Start by clarifying scale and constraints before you draw anything. Ask about ingestion volume, acceptable latency, retention requirements, and consistency needs. Then walk through storage choice, processing layer, and how you would handle failures and retries. Razorpay interviewers want to see that you think about idempotency and exactly-once semantics, not just happy-path throughput.

For behavioral questions: Use the STAR structure (Situation, Task, Action, Result) and keep answers concrete. Candidates report that Razorpay interviewers push back on vague responses, so have specific outcomes ready even if they are approximate.

For technical concept questions: State the concept clearly in one sentence, give a concrete example from your own work, and then discuss trade-offs. If asked about the CAP theorem, do not just define it. Explain which trade-off you made in a real system and why you made that call.

For SQL rounds: Think out loud. Razorpay SQL questions typically involve window functions, aggregations, and joins on transactional data. Practice writing queries that handle duplicates and NULLs gracefully, since payment data tends to be messy in practice.

Razorpay data engineering interviews assess a specific combination of skills that matches the problems their teams actually face.

Strong SQL and data modeling: Candidates report multi-part SQL questions involving window functions, self-joins, and aggregation on payment-like datasets. Comfort with columnar storage and partitioning strategies matters at mid and senior levels.

Streaming systems experience: Kafka, Spark Streaming, or Flink come up frequently. Interviewers want you to discuss consumer groups, offset management, late data handling, and watermarking, not just say 'I used Kafka.'

Data reliability and idempotency: At a payments company, duplicate transactions or missing records have real business consequences. Interviewers look for candidates who design pipelines with at-least-once vs exactly-once trade-offs in mind from the start.

Fintech-specific awareness: Questions around PII masking, audit trails, reconciliation logic, and data retention come up. You do not need to be a compliance expert, but showing awareness of these constraints signals maturity.

Ownership mindset: Candidates who talk about what happened after a pipeline went live, covering monitoring, incidents handled, and improvements shipped, consistently score better than those who only describe the build.

Week 1: SQL and Python fundamentals
Practice window functions, CTEs, and aggregations on large transactional datasets. Focus on duplicate detection, running totals, and time-series aggregations. Brush up on Python for data processing, particularly pandas and PySpark basics.

Week 2: Streaming and pipeline design
Review how Kafka works end to end: producers, consumers, consumer groups, topic partitioning, and offset management. Practice designing a streaming pipeline on paper, covering ingestion, transformation, storage, and failure handling. Understand watermarking and late-data strategies in Spark Streaming or Flink.

Week 3: System design practice
Practice designing a few complete data systems from scratch: a real-time fraud detection system, a merchant analytics platform, and a payment reconciliation pipeline. For each, work through CAP theorem trade-offs, data modeling decisions, and monitoring strategy.

Week 4: Behavioral prep and mock interviews
Write out several STAR stories covering pipeline failures, data quality incidents, cross-team collaboration, and a time you improved a system's reliability. Do at least a couple of full mock interviews with someone who can push back on vague answers.

If you are actively applying, knok checks 150+ job sites nightly, applies to Data Engineer roles that match your resume, and messages HR contacts on your behalf, so you can focus your prep time on interviews rather than hunting for openings.

Skipping clarification on system design: Jumping straight into architecture without asking about scale, latency, or consistency needs is the most commonly reported mistake. Razorpay interviewers want to see structured thinking before you draw anything.

Treating Kafka as a magic box: Saying 'I used Kafka' without explaining how you handled consumer lag, rebalancing, or exactly-once semantics tells the interviewer you used a tool without truly understanding it.

Ignoring data quality in pipeline designs: Candidates who design only the happy path (data arrives clean, processing succeeds, write completes) consistently get follow-up questions about failure modes. Address bad data, retries, and idempotency upfront.

Vague behavioral answers: 'We improved pipeline performance' without describing the before and after state does not land well. Have concrete outcomes ready even if approximate.

Not knowing why Razorpay specifically: Interviewers typically ask why you want to join. Candidates who have no answer beyond 'it is a good company' stand out for the wrong reasons. Know what problems the data team solves and why those interest you.

Underestimating the SQL round: Mid and senior candidates sometimes assume SQL will be straightforward and walk in underprepared. Questions can involve multiple joins, window functions, and edge cases around NULL handling on payment-like datasets.