---
title: Razorpay Frontend Interview Questions (2026 Guide)
description: Real Razorpay frontend engineer interview questions — the machine coding round, JavaScript deep-dive, frontend system design and payments UI, with answers.
url: https://usegreenroom.app/blog/razorpay-frontend-engineer-interview-questions
last_updated: 2026-07-27
---

← Back to blog

India · Razorpay

# Razorpay frontend interview questions and process

July 27, 2026 · 10 min read

![Razorpay frontend interview questions guide — cover from Greenroom, the AI mock interviewer](/assets/blog/razorpay-frontend-engineer-interview-questions-hero.webp)

Ninety minutes into her Razorpay machine coding round, a frontend engineer I'll call Sneha had built something genuinely nice: a payment form, clean React, tidy state. The interviewer clicked "Pay" twice in quick succession. Two payments fired. He didn't say anything mean. He just said, "So I've been charged twice," and let the silence do the work. Sneha's component was beautiful. It was also, for about four seconds, a way to lose someone's money.

That is the whole personality of **Razorpay frontend interview questions**. The JavaScript bar is high and the machine coding round is real, but every round quietly circles back to one question: does your UI stay correct when the network is slow, the user is impatient, and rupees are moving? I built Greenroom after freezing in an interview I'd actually prepared for, so this guide covers what Razorpay asks and how to say it out loud while you type.

## The Razorpay frontend engineer interview process in 2026

Razorpay runs a consistent loop across frontend levels, with the system design round typically reserved for senior candidates. The **Razorpay frontend interview process** as candidates report it:

- **Online assessment** — timed DSA problems, sometimes with a short JavaScript output-prediction section (closures, hoisting, `this`).
- **DSA / coding round** — arrays, strings, hash maps, recursion. Medium difficulty, and you're expected to narrate while you code.
- **Machine coding round** — 60 to 90 minutes to build a working component. This is the round that decides most loops.
- **JavaScript / framework deep-dive** — closures, the event loop, promises, the browser rendering path, React internals. Asked as "why," not "what."
- **Frontend system design** — usually senior only: component architecture, state boundaries, caching, performance budgets.
- **Hiring manager + culture** — ownership, a production incident you caused, and why payments.

The thing to internalise early: Razorpay is a payments company, so "correct" beats "clever" in every single round. A working, well-structured component with handled edge cases outscores an elegant half-finished one, every time.

![Razorpay frontend engineer interview process diagram — online assessment, DSA round, machine coding round, JavaScript deep-dive, hiring manager and culture round](/assets/blog/razorpay-frontend-engineer-interview-questions-diagram.webp)

The Razorpay frontend loop: five rounds, and the machine coding round is where most decisions are actually made.

## The Razorpay machine coding round: what "done" looks like

You'll get a prompt like *build an autocomplete with debounced search*, *build a multi-step checkout form*, *build a cart with quantity controls*, or *build an infinite-scroll feed*. You get 60 to 90 minutes, an editor, and an interviewer watching.

What actually gets scored, in rough order of weight: does it run; are the edge cases handled; is the state modelled sensibly; is the code readable; and only then, is it pretty. Candidates lose this round by spending twenty-five minutes on CSS and shipping a component that breaks on an empty response.

Here is the shape interviewers are looking for on a debounced search — note that the abort and the loading state matter more than the debounce itself:

```javascript
function useSearch(query, delay = 300) {
  const [state, setState] = useState({ status: "idle", results: [] });

  useEffect(() => {
    if (!query.trim()) {
      setState({ status: "idle", results: [] });
      return;
    }
    const controller = new AbortController();
    const timer = setTimeout(async () => {
      setState((s) => ({ ...s, status: "loading" }));
      try {
        const res = await fetch(`/api/search?q=${encodeURIComponent(query)}`, {
          signal: controller.signal,
        });
        if (!res.ok) throw new Error(res.status);
        setState({ status: "done", results: await res.json() });
      } catch (err) {
        if (err.name !== "AbortError") setState({ status: "error", results: [] });
      }
    }, delay);

    return () => {
      clearTimeout(timer);
      controller.abort();
    };
  }, [query, delay]);

  return state;
}
```

Three things here are worth saying out loud as you write them: the cleanup cancels both the timer and the in-flight request, so a slow response for "raz" can never overwrite the results for "razorpay"; `status` is one field rather than three booleans, so there's no state where loading and error are both true; and `AbortError` is swallowed deliberately because a cancelled request is not a failure. Our [JavaScript interview questions guide](/blog/javascript-interview-questions) drills the async layer underneath.

The payments version of the same instinct is the double-click problem Sneha hit. Disable on submit, track an in-flight ref, and generate the idempotency key *before* the first attempt so a retry reuses it:

```javascript
async function pay(order, submittingRef) {
  if (submittingRef.current) return;
  submittingRef.current = true;
  const idempotencyKey = order.clientRequestId; // stable across retries
  try {
    return await api.post("/payments", { ...order, idempotencyKey });
  } finally {
    submittingRef.current = false;
  }
}
```

Volunteering that reasoning unprompted — "the button being disabled is a UX nicety, the idempotency key is the actual guarantee" — is the single strongest signal you can send in a Razorpay frontend round.

## JavaScript deep-dive questions Razorpay asks

The **Razorpay JavaScript interview questions** are conceptual and asked as follow-ups rather than trivia. The recurring set:

- **Closures and scope** — write a `once()` wrapper, explain why a loop with `var` logs the wrong index, implement a memoize function.
- **The event loop** — predict the output of interleaved `setTimeout`, promises and `queueMicrotask`. Know that microtasks drain fully before the next macrotask.
- **Promises** — implement `promiseAll` from scratch, and explain how you'd add a timeout and a retry with backoff.
- **`this` and binding** — implement `call`, `apply` and `bind`. This shows up more often at Razorpay than at most product companies.
- **Rendering path** — how HTML and CSS become pixels, what triggers reflow versus repaint, and why a transform animates cheaper than `top`.
- **React internals** — reconciliation and keys, why a derived-state `useEffect` is usually a bug, `useMemo` versus `useCallback`, and what actually causes a re-render.

Answer these by giving the mechanism first and the definition second. "Because the callback closes over the variable binding, not the value at the time" lands very differently from "because of closures." Our [React interview questions guide](/blog/react-interview-questions) and [frontend developer interview questions guide](/blog/frontend-developer-interview-questions) cover both layers in depth.

## Frontend system design at Razorpay

For senior candidates there's a design round, and Razorpay's prompts are pleasingly concrete: design the Checkout widget that merchants embed on their own sites; design a dashboard table showing a million transactions; design an offline-tolerant refund flow.

What to cover, roughly in this order:

- **Boundaries first** — what's a component, what's shared state, what's server state. Say out loud that server state and UI state are different problems.
- **Embedding and isolation** — an iframe-based checkout keeps the merchant's page out of your DOM and keeps card data out of the merchant's scope. That last part is a compliance answer, not a styling preference.
- **Performance budget** — a checkout that loads on someone else's page must be small. Talk bundle size, code splitting, and what you'd lazy-load.
- **Failure UI** — what the user sees when the payment API times out, and how you avoid telling someone a payment failed when it actually succeeded.
- **Accessibility** — keyboard traps in modals, focus management, and labelled inputs. Razorpay does ask.

State the constraint before the design. "Because this renders inside a stranger's page, I'd isolate in an iframe and keep the initial bundle under a hard budget" is a senior sentence. The [Razorpay frontend engineer prep page](/prep/razorpay-frontend-engineer-interview) has a compact round-by-round checklist.

## Behavioral rounds and the "why payments" question

Razorpay's hiring-manager round is not filler, and one question comes up nearly always: why payments, or why fintech. A vague answer here reads as "I applied to forty companies," which is fine as a fact and bad as an answer. The workable version connects a real preference to the domain: you like problems where correctness is checkable, where a bug has a visible number attached to it.

Beyond that, expect: a production incident you caused and what you changed afterwards; a time you shipped something you disagreed with; a performance problem you found and fixed on the client. Two-minute stories, first person, real numbers. "I improved page load" is invisible; "the dashboard's initial bundle was 1.4MB, I code-split the charts and dropped time-to-interactive from 6s to 2.3s on a mid-range Android" is a hire signal. Our [tell me about a time you failed](/blog/tell-me-about-a-time-you-failed) guide has the structure.

## LeetCode, GeeksforGeeks, Frontend Masters — where each fits

An honest map of the prep stack for this specific loop:

- **LeetCode** — necessary but not sufficient. The OA and DSA round are real; medium-difficulty arrays, strings and hash maps. It does nothing for the machine coding round, which is most of your risk.
- **GreatFrontEnd and Frontend Masters** — the closest paid practice to Razorpay's machine coding and JS rounds, and the place to drill implementing `bind`, `promiseAll` and debounce from scratch.
- **MDN** — the honest answer for the rendering-path and event-loop questions. Read the pages on the event loop and on rendering performance; interviewers are asking about the model MDN describes.
- **GeeksforGeeks and Blind interview experiences** — useful for calibrating round formats and difficulty. Anecdotes, not a syllabus.
- **ChatGPT** — genuinely good for reviewing a machine coding solution you already wrote and pointing out unhandled edge cases. It won't click your Pay button twice and then go quiet.
- **Greenroom** — the spoken layer. [Ari, the AI interviewer](/), runs the round out loud, asks the follow-up when your answer says "closures" without saying why, and scores structure and clarity. Fair tradeoff: Ari won't review your React code line by line; pair it with GreatFrontEnd.

**The core truth:** Razorpay's frontend loop rewards correctness narrated clearly. Question banks prepare your first answer; only spoken practice prepares the follow-up — and in machine coding, you're explaining and typing at the same time.

## How to prepare for the Razorpay frontend interview

- **Week 1:** DSA daily — arrays, strings, hash maps, recursion at medium difficulty. Narrate complexity aloud on every problem.
- **Week 2:** vanilla JS from scratch — `debounce`, `throttle`, `once`, `memoize`, `bind`, `promiseAll`, a retry with backoff. Then explain each aloud in sixty seconds.
- **Week 3:** three timed machine coding builds under a real 90-minute clock — autocomplete, multi-step form, infinite scroll. Ship working before pretty, every time.
- **Final week:** frontend system design aloud (an embeddable checkout, a large data table), five behavioral stories in first person, two full spoken mocks, and the [role-specific prep page](/prep/razorpay-frontend-engineer-interview) the night before — not new material.

Interviewing across Razorpay's other tracks, or at similar Indian fintechs? The [Razorpay backend engineer guide](/blog/razorpay-backend-engineer-interview-questions) covers idempotency and ledger design, the [Razorpay data engineer guide](/blog/razorpay-data-engineer-interview-questions) covers settlement and reconciliation, the [general Razorpay interview questions guide](/blog/razorpay-interview-questions) covers the company-wide loop, and the [PhonePe](/blog/phonepe-interview-questions) and [CRED](/blog/cred-interview-questions) guides cover the nearest comparable bars.

## Frequently asked questions

### What is the Razorpay frontend engineer interview process?

Candidates consistently report an online assessment with timed DSA problems, a DSA and coding round, a machine coding round of 60 to 90 minutes building a working component, a JavaScript and framework deep-dive, and a hiring-manager plus culture round. Senior candidates also get a frontend system design round. The machine coding round carries the most weight in the decision.

### What is asked in the Razorpay machine coding round?

Typical prompts are an autocomplete with debounced search, a multi-step checkout form, a shopping cart with quantity controls, or an infinite-scroll feed, built in 60 to 90 minutes. Scoring priorities are: it runs, edge cases are handled, state is modelled sensibly, and the code is readable. Styling comes last — an unfinished but beautiful component fails this round.

### What JavaScript questions does Razorpay ask?

Reported questions cover closures and scope, the event loop and microtask ordering, implementing promiseAll, call, apply and bind from scratch, debounce versus throttle, the browser rendering path and reflow versus repaint, and React internals such as reconciliation, keys and what triggers a re-render. They are asked as "why does this happen" rather than as definitions.

### Is the Razorpay frontend interview hard?

It is a high bar, but a predictable one. The DSA round sits at medium difficulty rather than hard, and the JavaScript questions are standard fundamentals asked deeply. The genuine difficulty is the machine coding round, where you build a working component under a clock while explaining your decisions — a combination most candidates have never practised.

### Does Razorpay ask DSA questions for frontend roles?

Yes. There is an online assessment and a dedicated DSA round for frontend candidates, typically covering arrays, strings, hash maps and recursion at medium difficulty. It is a genuine filter, but Razorpay weights the machine coding and JavaScript rounds more heavily, so DSA grinding alone will not carry a frontend loop.

### How many rounds is the Razorpay frontend interview and how long does it take?

Most reported loops run four to six rounds — online assessment, DSA, machine coding, JavaScript deep-dive, hiring manager, plus system design for senior roles — over roughly two to five weeks end to end. Scheduling gaps between rounds are the longest part; use them for timed machine coding practice rather than more DSA.

Razorpay's loop is a correctness test you have to narrate while typing. [Greenroom](https://usegreenroom.app/) runs mock frontend interviews out loud with Ari — machine-coding and JavaScript pushback included — and scores structure, clarity and depth. Free to start. Curious how it works? See [how AI mock interviews work](/blog/ai-mock-interview).