razorpay Frontend Engineer Interview: Questions & Prep (2026)

Razorpay is one of India's leading payments infrastructure companies. Their frontend team builds checkout SDKs, merchant dashboards, and real-time analytics tools that businesses across India rely on daily. A bug in a payment form can cost a merchant a sale, so the team takes reliability, performance, and accessibility seriously.

As of July 2026, knok jobradar tracks 42 open Frontend Engineer roles at Razorpay. Candidates typically report a process of 3 to 5 rounds: an online coding screen, one or two technical interviews, a system design round (more common for mid-level and above), and a culture or hiring-manager conversation. Round names and order vary by team, so confirm the current structure with your recruiter.

The salary bands for Frontend Engineers in this market (knok jobradar data, July 2026) are 5-11 LPA for 0-2 years of experience, 12-22 LPA for 3-5 years, 24-40 LPA for 6-9 years, and 38-58+ LPA for Lead and Staff roles. Razorpay is a well-funded fintech, and publicly reported figures on Glassdoor and levels.fyi suggest offers tend toward the upper end of these bands for strong candidates.

These questions appear repeatedly in Razorpay Frontend Engineer interviews, based on candidate reports and the nature of their product.

1. Explain the JavaScript event loop and how asynchronous code actually runs. Razorpay builds SDKs that run in third-party environments, so the team needs engineers who understand the language at a deep level.
2. How do you protect a payment form against XSS and clickjacking? Security is a core requirement when handling merchant and customer financial data.
3. Walk me through how you would fix a React component that re-renders too often. Performance in checkout flows directly affects conversion.
4. Explain the browser's critical rendering path and where you can intervene to speed it up.
5. Design the frontend of a payment dashboard that shows real-time transaction data for a merchant. This is typically asked at mid-level and above.
6. How would you implement a retry mechanism for a failed payment API call without confusing the user or causing a duplicate charge?
7. Explain JavaScript closures with an example from something you actually built.
8. How do you manage state in a large React application? Walk me through your trade-offs between Context, Redux, Zustand, or another tool.
9. What accessibility checks do you run before shipping a form? Why does this matter in a payments product?
10. How do you approach testing UI components? What do you actually verify, and what do you leave out?
11. Describe a time you improved page load time or Core Web Vitals in a production application.
12. How would you architect a micro-frontend so two separate teams can ship the checkout and the merchant dashboard independently?

Use the STAR method for all behavioural questions: Situation, Task, Action, Result. When spoken aloud, aim for roughly 2 minutes per answer.

---

Q: Describe a time you improved performance in a React application.

*Situation:* At my previous company, the merchant invoice listing page was taking several seconds to become interactive on mid-range Android phones. Users were abandoning the page before it finished loading.

*Task:* I was asked to improve it without a full rewrite, as the release window was close.

*Action:* I profiled the app with Chrome DevTools and found three issues. The search box was triggering a re-render on every keystroke because there was no debouncing. The invoice list was unvirtualised, so every row was mounted even when off-screen. And a large charting library was loaded eagerly on page mount. I added debouncing to the search input, replaced the plain list with react-window, and moved the chart to a dynamic import. I also wrapped two heavy child components with React.memo to stop unnecessary re-renders.

*Result:* Time to interactive dropped meaningfully, which our internal performance tooling confirmed. The change shipped cleanly, and the team adopted the same patterns on two other data-heavy pages in the following sprint.

---

Q: Tell me about a security issue you caught or fixed in a frontend codebase.

*Situation:* During a routine code review, I noticed a component was rendering user-supplied content using dangerouslySetInnerHTML without sanitising the input first.

*Task:* I needed to fix that instance and also check whether the same pattern existed elsewhere in the codebase.

*Action:* I replaced the dangerous render with a plain text node for that component, then ran a search across the repo for all uses of dangerouslySetInnerHTML. I found two additional instances. For those, I introduced DOMPurify as a shared sanitiser utility and added a lint rule to flag raw usage going forward. I also wrote a short internal doc explaining why this is especially risky in a payments context, where merchants sometimes paste HTML snippets into custom fields.

*Result:* All three instances were patched before the next release. The lint rule has since caught one more case introduced by a newer team member.

---

Q: Give an example of a time you worked closely with a backend engineer to solve a hard integration problem.

*Situation:* We were building a real-time payment status notification system. The backend team chose WebSockets, but the existing frontend was a legacy app with no WebSocket infrastructure and several network proxies of unknown behaviour.

*Task:* I had to integrate WebSockets into the React app, handle reconnections gracefully, and make sure users always saw an accurate payment status even after keeping the tab open for a long time.

*Action:* I worked with the backend engineer to define the message contract first before writing a single line of frontend code. Then I built a custom hook that managed the socket lifecycle, including exponential back-off on disconnects and a silent fallback to polling if the socket could not connect after a few retries. I also added a visible connection-state indicator so users would never be silently out of sync with the server.

*Result:* The feature shipped on schedule. Internal tooling showed a drop in support tickets related to payment status confusion, though I am not able to share the exact figure.

For JavaScript and algorithm questions: State the brute-force approach first and name its time and space complexity, then optimise. Razorpay interviewers want to follow your thinking, not just see a finished answer. Say your assumptions aloud before you start coding.

For React and component architecture questions: Use a 'requirements first' approach. Ask about scale, team structure, and constraints before proposing a solution. This signals senior-level thinking. When discussing state management, name the trade-offs explicitly (simplicity vs. boilerplate vs. performance) before picking a tool.

For security questions: Start with the threat model. What is the attacker trying to do, and what is at stake? In a payments company, every security answer should acknowledge that user and merchant financial data is involved. Interviewers notice when candidates treat security as a checkbox rather than a genuine design concern.

For system design questions: Use a three-part structure. First, clarify requirements (functional and non-functional). Second, sketch the high-level component breakdown. Third, go deep on the areas the interviewer probes. For frontend system design, always cover data flow, loading states, error states, and accessibility before you are done.

For behavioural questions: Use STAR and keep the result concrete. If you cannot share numbers due to confidentiality, say so and describe the qualitative outcome instead. Razorpay interviewers value ownership, so pick stories where you drove the solution rather than just contributed to it.

Razorpay's frontend interviews look for engineers who think like product owners, not just implementers.

Deep JavaScript fundamentals. The team builds SDKs and embedded checkout flows that run in environments they do not control. Interviewers want to see that you understand the language itself, not just React or a specific library on top of it.

Performance instinct. Checkout conversion is a core business metric for Razorpay's merchant customers. Candidates who have actually profiled and fixed performance problems in production, rather than just read about best practices, stand out clearly.

Security by default. Because the product handles real money, interviewers pay close attention to whether security thinking is part of your natural design process. Raising XSS defences, input validation, or duplicate-submission prevention before being asked is a strong positive signal.

Comfort with ambiguity. Razorpay moves quickly. Interviewers use open-ended system design questions partly to see whether you ask good clarifying questions before diving in. Jumping straight to a solution without understanding the constraints reads as a junior pattern.

Clear communication. Candidates report that interviewers will interrupt to ask 'why did you choose that?' during both coding and design questions. Practice explaining your reasoning in plain language while you work, not just at the end.

Week 1: JavaScript and React foundations
Revise closures, the event loop, promises, async/await, and prototypal inheritance. For React, focus on reconciliation, useEffect dependency arrays, and performance hooks (useMemo, useCallback, React.memo). Build one small project that uses all of these so you have concrete personal examples to draw on in the interview.

Week 2: Performance and security
Study Core Web Vitals (LCP, CLS, INP) and how to measure them with Lighthouse and Chrome DevTools. Practice explaining the critical rendering path in plain language. For security, read about XSS, CSRF, clickjacking, and insecure browser storage. Write down one real or practice example for each so you are not describing theory without context.

Week 3: System design and state management
Practice designing frontend systems: a real-time transaction dashboard, a multi-step checkout form, a shared component library. Focus on data flow, error handling, and accessibility. Compare state management approaches (Context API, Redux Toolkit, Zustand) and be ready to justify your choice for a given scenario.

Week 4: Interview practice and company research
Do at least two mock interviews with a peer, including one system design session. Prepare 5 STAR stories covering: a performance win, a security catch or fix, a disagreement with a teammate, a time you failed and recovered, and a time you took ownership beyond your immediate role. Spend time with Razorpay's actual products (Payment Gateway, Razorpay X, RazorpayOS) so you can speak to what draws you to their specific engineering challenges.

If you are still actively hunting while preparing, knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR for you, so you can keep your focus on deep interview prep rather than manual applications.

Coding in silence. Razorpay interviewers want to follow your reasoning. Going quiet while you solve a problem makes it hard for them to assess your thinking. Narrate as you work, even if it feels unnatural at first.

Only handling the happy path. When asked to design a checkout form, retry logic, or payment status display, candidates who skip network failures, timeouts, and duplicate submissions signal that they have not shipped real payments code. Always ask about and address failure modes.

Treating security as an afterthought. Mentioning XSS defences only when the interviewer specifically asks is far weaker than raising security proactively as part of your design. In a fintech context, security is a first-class concern, not a finishing touch.

Vague behavioural answers. Saying 'I improved performance on a project' without specifics is weak. Even if you cannot share exact numbers, describe what you measured, what you changed, and what the outcome looked like for users or the business.

Jumping straight to a solution in system design. Skipping the requirements-gathering step signals junior thinking. Take a minute to ask about scale, team size, and constraints before proposing anything.

Ignoring accessibility. Candidates report being asked about ARIA roles, keyboard navigation, and focus management. In a payments form, accessibility is both a legal requirement and a business one, since it affects who can complete a transaction.