Navi Frontend Interview

Composite guidance based on publicly shared candidate reports and common hiring patterns for frontend / UI roles at NBFCs and lending or payments products. Processes vary by role, level, team, and year. Always confirm with your recruiter. Not a personal diary, and not affiliated with Navi.

A Navi frontend interview is easy to misread as a prettier checkout. The miss is usually a second Apply. KYC OCR is slow, Continue is tapped again, and you now have two client application ids, or the same OTP is consumed twice. Lending UI is a document that lives for days, not a three-second Pay tap.

Teams still run a JavaScript screen and machine coding. Product sense is amounts, gated KYC, retries that do not duplicate a submit, and honest status when sanction takes hours. Sister loops: Razorpay (gateway checkout) and PhonePe (consumer UPI).

Key takeaways

• JS problem solving plus a timed UI build. The product talk is KYC, amounts, and retries, not a new visual language.
• Apply, eSign, and mandate setup are commands: in-flight lock, server idempotency key, no silent second POST.
• Requested, sanctioned, and disbursed amounts are three fields. Store integer paise.
• KYC is server-gated. Persist the application id, restore the step, do not skip a gate because Next is enabled in CSS.
• Confirm org (lending, UPI, insurance, platform) and whether machine coding is pair, OA, or take-home.

Lending UI, KYC flows, and a JS plus machine-coding loop

Stage	Focus	Format
Recruiter	Role, org, stack, notice	Call
JS / problem-solving	Language, polyfill, async util	Shared editor or OA
Machine coding	Stepper, amount, upload, status	45-90 min
Product / web	Money UX, KYC resume, a11y	Conversation + code
Hiring manager	Ownership, incidents	Call

Some packets start with an OA. Some go straight to a pair session. Senior loops add a design talk (application home, offer, repayment). Ask the recruiter what you will sit.

They score correct JS under time, a working form path, and respect for money and PII: no double submit, no lost amounts, no PAN in console.log.

JavaScript problem solving

NBFC screens look like other Indian product companies: closures, the event loop, this, array transforms, debounce, promise combinators. You might implement a util rather than a graph problem. You might still get medium DSA in JavaScript.

Walk how to approach polyfill questions, then ship standalone functions: array map, Promise.all, once, retry a promise N times (status GET, not a blind POST). Warmups: output-based questions.

Restate inputs, one example, a standalone function, dry-run empty list, rejected promise, double click. If you touch builtins, name holes and thenables. map skips holes. Promise.all rejects on the first rejection and keeps fulfillment order.

Machine coding: KYC, amounts, retries

Typical shapes (not claimed Navi transcripts): multi-step KYC (identity → address → bank → review), amount plus tenure plus an EMI preview, document upload with progress and a retry that hits the file POST only, a status timeline (draft, submitted, sanctioned, disbursed, rejected).

Build those with multi-step wizard, multi-step forms in React, OTP input boxes, and the machine coding interview framework: happy path, then loading/error/empty, then keyboard. Lift wizard state. If step two unmounts and wipes PAN, you failed resume. A client-side lock is not a substitute for a server idempotency key.

const TERMINAL = new Set(['rejected', 'disbursed', 'cancelled']);

function canApply(state) {
  return state.status === 'draft' && state.kyc === 'complete' && !state.inFlight;
}

function reduceApplication(state, action) {
  switch (action.type) {
    case 'setAmountPaise':
      if (state.status !== 'draft') return state;
      return { ...state, amountPaise: action.amountPaise };
    case 'applyStart':
      if (!canApply(state)) return state;
      return { ...state, inFlight: true, error: null };
    case 'applyOk':
      return { ...state, inFlight: false, status: 'submitted', applicationId: action.id };
    case 'applyFail':
      return { ...state, inFlight: false, error: action.error };
    case 'serverStatus':
      if (TERMINAL.has(state.status)) return state;
      return { ...state, status: action.status, inFlight: false };
    default:
      return state;
  }
}

Disable the CTA. Keep amount in one place. Poll status by id. Abort the previous fetch with AbortController. Retry 429/5xx, not a 400 you caused, and do not rewind a terminal status from a stale poll. Client EMI is a preview rounded from integer paise. Production fees come from the server. Display with Intl.NumberFormat (en-IN). See number precision.

What they score on money-safe UI

Topic	Frontend owns	Do not overclaim
Amounts	Display, locale, integer minor units	IRR, underwriting, pricing engine
KYC	Step UI, validation, upload progress	Aadhaar protocol, CKYC ledger
Apply / eSign	Idempotent POST, disabled CTA, resume	Credit decision
Retries	UX + shouldRetry + backoff	Silent loops on a charge or disbursal
PII	Mask PAN, no logs, no innerHTML	Homegrown document vault

Persist applicationId before you navigate. Hydrate from the server document. Let the server say which step is allowed. Back must not edit a field locked after sanction. Next must not skip a failed PAN check because the local stepper is optimistic.

Uploads: progress, cancel, retry the file request. Do not re-POST the whole application because a selfie 503’d, and do not stash KYC images in localStorage. XSS on OCR text: XSS. Forms: names, errors next to fields (accessible forms). Dashboard prompts: filters, virtualized rows, debounce search. Mid+ design: one job of the screen, source of truth for amount and status, failure UI. Stay in frontend scope.

Footguns

• Enabling Apply while amount or tenure is still being edited
• Two client ids because Continue was not in-flight locked
• GET for apply, or secrets in the query string
• Auto-retrying send-OTP without a user action
• Float rupee math, or overwriting sanctioned amount with the requested one
• Empty states skipped: KYC rejected, offer expired, mandate failed

Preparation plan (5-7 weeks)

1. Weeks 1-2: Teach-back event loop, promises, closures. One polyfill-style function a day, including once and retry.
2. Weeks 3-4: Timed DSA in JS (Two Sum, Valid Parentheses, LRU Cache) plus one MC rebuild per weekend (stepper + amount).
3. Week 5: KYC wizard from memory. Fifteen-minute outline of an offer screen with three amounts and a resume path.
4. Weeks 6-7: Mocks. After each, write three concrete fixes. Confirm the loop with the recruiter.

Out loud: “I would ship an application that cannot double-fire Apply, keeps requested amount in paise in one place, and hydrates KYC from the server document so refresh does not restart the stepper. Retries are for status and uploads, not for a second submit. I would mask PAN and skip innerHTML on OCR text. For the JS screen I start with a standalone function, edges, then complexity.”

Further reading

• Fetch API: MDN
• Constraint validation: MDN
• Intl.NumberFormat: MDN

Related on this site

• Razorpay · PhonePe · Stripe
• How to approach polyfill questions
• Once function · Retry a promise
• Multi-step wizard · OTP input