Paytm Frontend Development Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Paytm hiring for Frontend Development roles
Paytm, operated by One 97 Communications, is an Indian digital payments and financial services company offering UPI payments, merchant soundboxes, payment gateway, lending distribution and ticketing. Its technology teams work on payments infrastructure, risk and merchant services. It hires for software engineers, QA engineers, data analysts and data scientists.
For Frontend Development roles, this Paytm practice set focuses most on Build Tools and Tooling (5), Frontend Testing (5), TypeScript (5), Browser APIs (4). It has 4 easy, 20 medium, 6 hard questions, so you can start easy and work up to the harder ones.
Company type
Fintech
Headquarters
Noida, India
Main India offices
Noida, Bengaluru, Mumbai
Paytm Frontend Development interview process
Online assessment (coding + MCQs)
Technical round 1
Technical round 2
Hiring manager round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for PaytmStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
When a user logs out in one tab, other open tabs stay logged in. How do you fix it?
I would broadcast a logout message using BroadcastChannel, or the storage event as a fallback, so every tab clears its in-memory state and redirects to the login page. The server must also invalidate the session or refresh token, so stale tabs fail their next API call with a 401, which the app handles by logging out. Both client sync and server invalidation are needed.
02
Run linting and formatting automatically before each commit.
Use Husky with lint-staged:
npm i -D husky lint-staged
npx husky init
echo 'npx lint-staged' > .husky/pre-commit
// package.json
"lint-staged": {
"*.{ts,tsx,js}": ["eslint --fix", "prettier --write"],
"*.{css,md,json}": "prettier --write"
}
Only staged files are checked, so commits stay fast. CI should still run the full lint because hooks can be skipped locally.
Tokens go in CSS with the @theme directive:
@import 'tailwindcss';
@theme {
--color-brand-500: #2563eb;
--color-brand-700: #1d4ed8;
--font-display: 'Poppins', sans-serif;
--radius-card: 12px;
}
/* usage in markup */
/* <button class='bg-brand-500 hover:bg-brand-700 rounded-card font-display'> */
Tailwind generates utilities like bg-brand-500 from these variables and also exposes them as CSS custom properties for use in plain CSS.
04
How do you test code that depends on the current date or timers?
Real time makes tests slow and nondeterministic. I would use fake timers, such as vi.useFakeTimers() and vi.setSystemTime(new Date('2026-11-12T10:00:00+05:30')), then advance time with vi.advanceTimersByTime to test debounce, countdowns or expiry logic instantly. Restoring real timers after each test avoids leaking state. Designing functions to accept a clock or date parameter makes them even easier to test.
05
How would you explain a difficult JavaScript concept to a junior teammate?
Situation: a junior developer kept writing bugs with async code. Task: I wanted them to understand promises rather than copy fixes. Action: I drew the event loop on a whiteboard, wrote three small console examples for them to predict, and then reviewed one of their real pull requests together. Result: within two weeks, their async bugs stopped and they started explaining the concept to the next new joiner.
06
Write a Playwright end-to-end test for a login flow.
Use role-based locators and web-first assertions:
import { test, expect } from '@playwright/test';
test('user can log in and see dashboard', async ({ page }) => {
await page.goto('/login');
await page.getByLabel('Email').fill('student@example.com');
await page.getByLabel('Password').fill('Secret@123');
await page.getByRole('button', { name: 'Log in' }).click();
await expect(page).toHaveURL(/dashboard/);
await expect(page.getByRole('heading', { name: 'My courses' })).toBeVisible();
});
Assertions auto-wait, so no manual sleeps are needed. Save login state with storageState to reuse in other tests.
07
After a release, the app shows a blank page in some older browsers. What could be wrong?
The build probably targets newer syntax or uses an API that older browsers lack, causing a parse error that stops the whole bundle. I would check the console in that browser, compare the build target and browserslist with our support policy, and add missing polyfills for used APIs. Error monitoring with browser breakdowns catches this quickly, and testing on the oldest supported browser should be part of release checks.
08
A full-screen hero section is cut off at the bottom on mobile phones. How do you fix it?
The section uses height: 100vh, which on mobile includes the area hidden behind the browser's address bar. I would change it to min-height: 100svh or 100dvh so the height matches the visible viewport, keeping 100vh as a fallback line before it for very old browsers. Using min-height instead of height also lets content grow on small screens instead of overflowing.
The worker runs on its own thread and talks through messages:
// worker.js
self.onmessage = (e) => {
const total = e.data.reduce((sum, row) => sum + row.amount, 0);
self.postMessage(total);
};
// main.js
const worker = new Worker(new URL('./worker.js', import.meta.url), { type: 'module' });
worker.postMessage(bigArrayOfRows);
worker.onmessage = (e) => showTotal(e.data);
The UI stays responsive. Data is copied between threads, so for huge binary data use transferable objects like ArrayBuffer.
10
Mock fetch in a Vitest test to check error handling.
Stub the global fetch and assert behaviour:
import { it, expect, vi, afterEach } from 'vitest';
import { loadCourses } from './api';
afterEach(() => vi.unstubAllGlobals());
it('returns an empty list when the server fails', async () => {
vi.stubGlobal('fetch', vi.fn().mockResolvedValue(
new Response('Server error', { status: 500 })
));
const result = await loadCourses();
expect(result).toEqual([]);
expect(fetch).toHaveBeenCalledWith('/api/courses');
});
For larger suites, MSW handlers are cleaner than stubbing fetch in every test.
11
Lighthouse shows a score of 95, but Search Console reports failing Core Web Vitals. Why?
Lighthouse is a single lab run on a simulated device, while Search Console uses field data from real Chrome users at the 75th percentile over 28 days. Real users may have slower phones, interact with the page, which affects INP and CLS later in the session, or see different content like ads and personalised blocks. I would add real user monitoring with attribution to find which pages and elements fail.
12
Collect Core Web Vitals from real users with the web-vitals library.
Report metrics to your analytics endpoint:
import { onLCP, onINP, onCLS } from 'web-vitals';
function send(metric) {
const body = JSON.stringify({
name: metric.name,
value: metric.value,
rating: metric.rating,
page: location.pathname
});
navigator.sendBeacon('/analytics/vitals', body);
}
onLCP(send);
onINP(send);
onCLS(send);
sendBeacon delivers data reliably even when the page is closing. Aggregate at the 75th percentile per page.
Tree shaking removes exports that are never imported from the final bundle. It relies on static ES module imports and exports. It fails with CommonJS modules, dynamic property access on imported objects, and code with side effects that the bundler must keep. Libraries mark themselves safe with sideEffects: false in package.json. Importing { debounce } from a modular package instead of the whole library lets tree shaking work.
14
The build works on your machine but fails in CI. How do you troubleshoot?
I would compare environments first: Node version, package manager version, and whether CI uses npm ci with the committed lockfile while I used npm install. Other common causes are case-sensitive file paths on Linux, missing environment variables, and files ignored by Git. Pinning Node with an .nvmrc or engines field and reproducing the CI command locally in a clean clone or container usually reveals the difference.
15
How would you learn TypeScript quickly if your new project required it?
Situation: I joined an internship where the codebase was fully TypeScript, which I had never used. Task: I needed to contribute within the first week. Action: I read the official handbook basics, studied existing types in the project, and converted small JavaScript exercises into TypeScript each evening. Result: I submitted my first typed component on day five and became comfortable with generics within a month.
A higher-order function takes a function as an argument or returns one, like map, filter or a custom withLogging(fn) wrapper. Currying transforms a function with many arguments into a chain of single-argument functions, so add(2)(3) returns 5. Currying makes partial application easy, for example creating formatINR = formatCurrency('INR') once and reusing it. Overusing it can reduce readability for teams unfamiliar with functional style.
17
What are WeakMap and WeakRef, and when are they useful?
A WeakMap holds object keys weakly, so when no other reference to the key exists, the entry can be garbage collected. This makes it ideal for attaching private metadata or caching computed data for DOM nodes without causing memory leaks. WeakMap keys are not enumerable. WeakRef holds a weak reference to a single object and is rarely needed, mostly for caches, because garbage collection timing is unpredictable.
18
Most of your users are on low-end Android phones with slow networks. How does that change your approach?
I would test with real budget devices and network throttling rather than a fast laptop. The priorities become sending less JavaScript, rendering important content on the server, compressing images aggressively, and keeping the initial page under a strict size budget. Caching with a service worker helps repeat visits. Features like large animations and heavy carousels should be reduced or loaded only when the device can handle them.
19
npm audit reports a critical vulnerability in a dependency. What do you do?
I would check whether the vulnerable package is actually used in the production bundle or only in build tooling, and whether the vulnerable code path is reachable. Then I would update to a patched version, using npm update or overrides for transitive dependencies. If no fix exists, I would look for an alternative package or mitigate. Automated tools like Dependabot or Renovate keep dependencies current.
20
An accordion animation stutters on low-end Android phones. What is wrong?
Most likely it animates height, max-height or margin, which forces layout recalculation every frame. I would check the Performance panel for long layout events. Fixes include animating transform and opacity, using the newer interpolate-size or calc-size features for height where supported, or animating grid-template-rows from 0fr to 1fr, which is cheaper. Testing with CPU throttling in DevTools reveals these issues before users do.
21
A third-party library you need has no TypeScript types. What do you do?
First I check if types exist on DefinitelyTyped by installing @types/library-name. If not, I write a minimal declaration file, for example declare module 'old-chart-lib' with only the functions I use, in a types folder included by tsconfig. This is better than a blanket any import. If the library is important to the community, contributing those types upstream helps everyone.
22
Your app must now support an Arabic right-to-left version. What changes are needed in CSS?
I would set dir='rtl' on the html element for that locale and replace physical properties like margin-left, padding-right and left with logical ones such as margin-inline-start and inset-inline-start. Flexbox and Grid follow direction automatically. Directional icons like arrows need flipping with a transform in RTL, while logos and media do not. I would test layouts with real Arabic text, which has different line heights.
23
Why do you want to build a career in frontend development?
I like work where users see the result directly. In college I built a timetable app for my class, and watching classmates use it daily taught me how small UI details matter. Frontend combines logic, design and performance, and the ecosystem keeps evolving, which keeps me learning. I want to build fast, accessible interfaces for products used by millions of people across India.
Generics let you write reusable code that keeps type information, using type parameters like <T>. For example, function first<T>(items: T[]): T | undefined returns a number for a number array and a User for a User array without losing types. Constraints such as <T extends { id: string }> restrict what T can be. Generics power typed API clients, form libraries and reusable UI components.
25
Type checking takes several minutes in a large monorepo. How do you speed it up?
I would enable project references with composite builds so only changed packages are rechecked, and turn on incremental with build info files cached in CI. skipLibCheck avoids rechecking node_modules declarations. Very complex conditional types and huge unions slow the checker, so I would profile with --generateTrace and simplify hotspots. The bundler can use fast transpilation while type checking runs separately in parallel.
Snapshot tests save a component's rendered output and fail when it changes, which quickly detects unintended changes with little effort. However, large snapshots are hard to review, so developers often update them blindly, and they break on harmless markup changes. They work best for small, stable outputs like serialised config or error messages. For UI behaviour, explicit assertions on visible text and roles are more meaningful.
27
Register a service worker that caches static assets with a cache-first strategy.
Register from the page, then handle install and fetch in sw.js:
// main.js
if ('serviceWorker' in navigator) navigator.serviceWorker.register('/sw.js');
// sw.js
const CACHE = 'static-v3';
self.addEventListener('install', e => {
e.waitUntil(caches.open(CACHE).then(c => c.addAll(['/', '/app.css', '/app.js'])));
});
self.addEventListener('fetch', e => {
e.respondWith(caches.match(e.request).then(hit => hit || fetch(e.request)));
});
Changing the cache name on each release lets the activate step delete old caches.
28
How would you migrate a large JavaScript codebase to TypeScript?
I would migrate gradually rather than in one big rewrite. First add tsconfig with allowJs and checkJs off, rename entry files to .ts, and keep the build working. Then convert shared utilities and API types first, because many files depend on them, and enable strict for new files. I would track the number of any usages, add type checking to CI, and convert feature folders as they are touched.
29
How have you built a testing culture in a frontend team?
Situation: my team had almost no automated tests and frequent regressions. Task: as tech lead, I wanted testing to become a habit, not a mandate. Action: I set up Vitest and Playwright with examples, ran two short workshops, required tests only for bug fixes at first, and celebrated bugs caught in CI. Result: within six months, most pull requests included tests and production regressions dropped significantly.
30
Compare IntersectionObserver, ResizeObserver and MutationObserver.
IntersectionObserver reports when an element enters or leaves the viewport or a container, used for lazy loading, infinite scroll and analytics impressions. ResizeObserver reports changes to an element's size, useful for charts that must redraw when their container changes. MutationObserver reports DOM changes like added nodes or changed attributes. All three are asynchronous and far more efficient than polling or scroll and resize listeners.
Tips to crack the Paytm Frontend Development interview
Learn UPI flow basics, including the role of NPCI, PSP apps and banks, for payments domain questions.
Practise testing scenarios for payment failures, refunds and timeouts if applying for QA roles.
Read about Paytm's merchant business like Soundbox and payment gateway, which are major parts of its strategy.
Keep a one-minute story ready for every project on your CV: problem, your part, tools, result.
Practise the hard questions on this page aloud; Paytm interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Paytm Frontend Development interview?
Candidates usually go through 5 stages: Online assessment (coding + MCQs); Technical round 1; Technical round 2; Hiring manager round; HR round. The exact rounds change with the role, team, location and your experience, so confirm the process with the recruiter.
Which topics should I prepare for the Paytm Frontend Development interview?
This practice set leans on Build Tools and Tooling (5), Frontend Testing (5), TypeScript (5), Browser APIs (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Paytm interviewers ask you to walk through real work.
Are these the exact questions asked at Paytm?
No. These are curated practice questions that match the skills and difficulty usually tested in fintech interviews like Paytm's. They are not a leaked or verified list of past questions.
Where does Paytm hire Frontend Development professionals in India?
Paytm has large teams in Noida, Bengaluru, Mumbai. Openings and locations change often, so check the Paytm careers page and filter by city and experience.
Frontend Development questions for similar companies