Razorpay Software Engineer Interview Guide

We’ve seen Razorpay lean hard toward engineers who can turn real product constraints into concrete design choices. Across candidate reports, the strongest signal is not polished theory but how well you defend tradeoffs: scalability, availability, consistency, failure handling, and the edges where a system breaks. One candidate who received an offer noted that the panel kept pushing on failure points in HLD, while others described LLD prompts like notification systems, photo-sharing apps, and even code-versioning-style designs. That pattern suggests they care less about naming patterns and more about whether you can reason through how software behaves under pressure.

A recurring theme is the emphasis on past work as evidence of engineering judgment. Multiple candidates said the conversation kept returning to projects, architecture decisions, and how things were built on previous teams, with one person specifically calling out resume deep-dives and another being asked to walk through a project’s high-level design. We also see a practical bent in the coding rounds: machine coding around load balancers, pub-sub workflows, and end-to-end project flows, plus DSA that still demanded clear explanation under time pressure. Even frontend candidates were pressed on CSRF, CORS, SSR, and web vitals in the context of their resume, which tells us Razorpay wants applied understanding, not memorized definitions.

The non-obvious make-or-break factor here is consistency of communication. Several candidates described abrupt or uneven interviewer behavior, and one experience felt confusing because the interviewer wasn’t fully aligned on the design concepts. That means candidates who do best are the ones who can stay crisp when the discussion gets messy and keep anchoring answers in concrete implementation details. In our view, Razorpay rewards engineers who sound like they’ve actually shipped systems, not just studied them.