Real, anonymized candidate journeys from recent (2025) Razorpay engineering loops in India — round by round, including what was asked, how the candidate approached it, and the outcome.
One complete journey, start to finish
Round 1 — System Design (45 minutes)
I applied on the careers page on a Friday and a recruiter called the next Monday. The first round was scheduled two days after that — a 45-minute system design call. The interviewer asked me to design a job scheduler service: users submit jobs with a time or a cron expression, and the service runs them on time and reliably. I began by listing the requirements and asked about scale and whether jobs could run for a long time. She said assume millions of scheduled jobs and mostly short tasks. Then I drew the pieces: an API to create and cancel jobs, a database table for job definitions, a scheduler that picks up jobs due in the next minute, a queue, and a pool of workers. She asked what happens if two scheduler instances pick the same job, so I talked about locking the row or leasing jobs with a version check. She then asked about retries and I described a retry count with backoff and a dead-letter queue. We ran out of time right as I was covering monitoring. The recruiter confirmed the next day I had cleared it.
Round 2 — Machine Coding
The machine coding round was the following week. This time it was not a whiteboard discussion — I had to actually build a load balancer and show it running. The interviewer explained the scope at the start: a small REST service where you can add and remove backend servers, set a timeout per backend, check which backends are healthy, and route normal traffic only to healthy ones. I spent the first ten minutes writing down the classes — LoadBalancer, BackendServer, HealthChecker, and a RoutingStrategy interface with a round-robin implementation. Then I coded the config endpoints first because they were straightforward, then the health checker as a background loop that marks backends up or down, and finally the routing itself. I kept the routing strategy behind an interface so I could mention weighted or least-connections later. With about fifteen minutes left, I ran a demo: added three backends, marked one unhealthy, and showed requests only going to the other two. He asked how I would handle a backend timing out mid-request, and I explained marking it unhealthy and retrying on another. Nearly everything was complete when time ran out.
Round 3 — System Design
Round three was another system design session, a couple of days after machine coding. The prompt was a Google Docs-style collaborative document system, and the interviewer said up front that access control was going to be a big part of it. I started with the basics: a document service storing document metadata and content, a real-time layer over WebSockets so multiple people could edit at the same time, and a way to merge edits — I mentioned operational transforms and CRDTs and said I would go with an OT-style approach with a central server ordering the operations. Then we moved to the access control list. I modelled permissions as rows of document, principal (user or group), and role (owner, editor, commenter, viewer), and explained how sharing with a group works by expanding group membership at check time, with caching. She asked how a permission change reaches someone who already has the document open, so I described pushing a revoke event over the same WebSocket and rechecking on every write. We finished with a short discussion about storing document history as a log of operations with periodic snapshots.
Round 4 — HR
The last round was with HR, about thirty minutes on a call the same week. It was relaxed. She walked through my resume from the top and asked about each job — why I moved, what I owned, what team sizes I had worked with. I explained my roughly six years of experience and what I was looking for in a lead role. Then she asked about my notice period and my current compensation, and what I expected. I gave a number with a short reason behind it and she said she would take it to the team. She also explained the next steps and the usual timeline for an offer. I asked about the team I would be joining and how the onboarding worked. The call ended there. The offer came through a few days later, so the whole thing from applying to offer took about two and a half weeks. Having practised designs for schedulers, load balancers and permission systems beforehand meant I was never starting from a blank page in any round.
Key takeaway: With about six years of experience, the candidate moved from application to offer in roughly two and a half weeks, crediting having concrete, ready-to-discuss designs for common systems (schedulers, load balancers, ACL-guarded documents) rather than improvising from scratch in the room.
More real interview journeys
The first round of each journey below is shown in full; the rest of each candidate's journey — every remaining round, verbatim — is part of the Placement-Ready PYQ Kit.
Round 1 — LLD (~1 hour)
A recruiter messaged me in the first week of February and the LLD round was set up for the following Tuesday, online, one hour. The interviewer shared the problem in the chat: build a logger that supports different severity labels and sends each log line to the console, a file, or a web endpoint depending on a config file read at startup. I asked two questions first — which levels were needed, and whether one entry could go to more than one destination. He said keep it to a few levels and yes, fan-out should be possible. Then I wrote the classes in Java: a LogLevel enum, a LogEntry, a LogDestination interface with console, file and HTTP implementations, and a Logger that read a map from level to destinations. I coded the console and file destinations fully and stubbed the HTTP one. Near the end he asked how I would add a new destination and I said one new class plus a config line. It ran on a small demo and the round ended on time.
🔒 2 more rounds — continue this journey in the full kit
Round 1 — Machine Coding (90 minutes)
I applied through a referral in late March and the machine coding round came about ten days later. It was 90 minutes on a video call with the interviewer watching my screen. The problem was an in-memory search engine for a blog platform: add a document, delete a document, search by a pattern, and return results in a sensible order. I started by writing a Document class and a SearchEngine class with the four operations, then built a simple inverted index — a map from each word to the set of document ids containing it. Insertion and deletion were quick. Search took longer because I had to intersect the sets for multi-word queries and then sort results by recency. Around the one-hour mark the interviewer started asking about prefix and suffix matching, and whether a trie or a suffix tree would handle the pattern search better than my word map. I explained how a trie would work for prefix search but did not have time to code it. I demoed the working parts in the last ten minutes and the round closed.
🔒 1 more round — continue this journey in the full kit