Got the offerSoftware Engineer at Razorpay
- Difficulty
- Process took
- 2-3 Weeks
- Rounds
- 3
- Format
- Remote
- Applied via
- Job Portal
How it went
- Be open and clear about your thought process, the interviewers want to understand how you approach problems, not just the final answer. It’s okay to ask questions or clarify assumptions.
- Remember, this is a conversation more than a test. If you enjoy solving problems that matter in real-world fintech systems, you’ll find this interview rewarding.
What they would tell you
- Be open and clear about your thought process, the interviewers want to understand how you approach problems, not just the final answer. It’s okay to ask questions or clarify assumptions.
- Remember, this is a conversation more than a test. If you enjoy solving problems that matter in real-world fintech systems, you’ll find this interview rewarding.
How to prepare
- Don’t just do LeetCode problems blindly. Focus on understanding system design fundamentals, especially around messaging queues like Kafka and caching with Redis.
- Getting familiar with concurrency and Java collections helped a lot. Also, reading Razorpay’s tech blogs gave me real insights into their challenges and tech choices.
Round by round
- 1
Technical Assessment(Online Coding Test)90 min
This round tested problem-solving skills but with a practical twist, not just pure algorithms but problems you could see in a payments backend. The questions required thinking about real-world constraints and designing efficient solutions. Questions & Approach: Detect Fraudulent Transactions
-
Approach: I suggested a sliding window approach that tracks the number of transactions per user within a time frame. Using Redis for caching transaction data seemed natural for speed. The idea was to flag any sudden spike beyond a threshold as suspicious. Design a Concurrent LRU Cache
-
Approach: I combined a HashMap and Doubly Linked List to maintain order and constant-time access. To make it thread-safe, I talked about using Java’s ConcurrentHashMap and synchronizing operations to handle concurrent access without locking the whole cache.
-
- 2
System Design120 min
The system design round was challenging but engaging. I was asked to design a payment reconciliation system, basically matching payment logs with merchant orders reliably. The interviewer really wanted to hear my thought process on data flow, consistency models, and handling failures. Design a Payment Reconciliation System
- Approach: I proposed using Kafka for log ingestion and Apache Flink for stream processing to handle real-time reconciliation. I preferred eventual consistency to keep the system responsive and suggested exponential backoff retries for failed log processing. We also discussed how to handle out-of-order events.
- 3
Low-Level Design90 min
This round felt very close to real work, I had to design a notification service that supports SMS, email, and push notifications. The focus was on clean design and testability. I also explained how I’d monitor the service in production. Question & Approach: Build a Multi-Channel Notification Service
- Approach: I used the Strategy Pattern to separate each notification channel’s logic cleanly. For testing, I discussed mocking external APIs so that unit tests don’t depend on actual network calls. I also planned for Prometheus integration to track delivery stats and failures.
What came up
A candidate-reported account, lightly edited. Interview processes change by team and date.