Frontend interview guide
Razorpay
India's leading payments platform. The Stripe-adjacent culture — correctness, dense dashboard surfaces, developer-first product.
Frontend engineers interviewing at Razorpay — checkout, dashboard, developer-tooling or merchant-facing surfaces.
Last reviewed 2026-10-04
What they emphasise
- Payments correctness — a payments culture treats bugs as a trust problem.
- Checkout UX — the surface that most of Razorpay's revenue depends on.
- Developer-first — SDKs, docs, playgrounds are first-class concerns.
- India-first + global expansion — the loop reflects both.
The loop, round by round
5 rounds. Durations and formats are typical, not guaranteed — confirm the loop shape with your recruiter in the screen.
Round 1
Recruiter screen
~30 minCallWhat it covers
- Resume, level, team orientation.
- CTC alignment.
What they're looking for
- A specific "why Razorpay" referencing an actual product.
Round 2
Technical phone screen
60 minLive codingWhat it covers
- A medium-difficulty JS/UI problem.
- Focus on correctness and edge cases.
What they're looking for
- Correct, testable code.
- A visible stance on edge cases.
Round 3
Onsite: UI coding
60-90 minLive component buildWhat it covers
- A payment-adjacent UI build — a card form, an OTP input, a payment-status flow.
What they're looking for
- Polished build with real failure handling.
- Accessibility baked in.
Round 4
Onsite: system design
60 minShared docWhat it covers
- A frontend-shape prompt in Razorpay's domain — a checkout widget, a dashboard with filters, a webhook debugger.
What they're looking for
- Honest treatment of operational realities.
- Specific trade-offs.
Round 5
Hiring manager / behavioural
45 minConversationWhat it covers
- Team shape, scope, behavioural stories.
What they're looking for
- Specific stories.
- Ownership framing.
What each level expects
The bar you're being measured against — plus the failure modes candidates most often trip on at that level.
SDE 2 / mid
~2-4 yearsSDE 2 — ships features end to end.
What they expect
- Clean React/TS, testing baseline.
- Payments-correctness mindset.
Common failure modes
- No tests on the UI build.
- No stance on failure modes.
Senior
~5-8 yearsOwns a technical area.
What they expect
- A system-design round that treats correctness + operational realities as co-equal.
Common failure modes
- Textbook pattern recall.
Staff
~8+ yearsMulti-team technical direction.
What they expect
- Peer-level discussion.
- Multi-team leverage.
Common failure modes
- Senior+ output rather than Staff leverage.
How to crack it
Day-of advice. The specific moves that separate offers from no-offers when the content is already in your head.
- 1Prep one payments-adjacent UI build — a card form with real validation, an OTP input, a payment-status flow with retries.
- 2In every round, lean into correctness over cleverness.
- 3Study Razorpay's developer docs — they're reference-grade in India.
- 4Pre-write behavioural stories with ownership framing.
- 5Use Razorpay Checkout (as a merchant signup) before the loop.
How to master it (over months, not days)
The longer-horizon work. These are the habits that pay off at Senior+ bars where cramming visibly fails.
- Build a payment-integration side project. The specificity carries weight.
- Read Razorpay engineering blog and the Payments domain generally.
- Learn one testing library deeply (behaviour tests before merge).
- Study PCI DSS at a working level — not for depth, for context.
- Make writing a habit.
Resources
On-site content for the technical prep, plus short-list of external links worth your time.