Myntra Frontend Development Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Myntra hiring for Frontend Development roles
Myntra is an Indian fashion and lifestyle e-commerce platform and part of the Flipkart group. Its technology and analytics teams work on search, personalisation, size recommendations, pricing, supply chain and marketing. It hires for software engineers, SDETs, business analysts, data analysts and data scientists. Fashion-specific data such as sizing matters a lot.
For Frontend Development roles, this Myntra practice set focuses most on Frontend Architecture (6), Frontend Testing (5), Build Tools and Tooling (4), TypeScript (4). It has 1 easy, 23 medium, 6 hard questions, so you can start easy and work up to the harder ones.
Company type
E-commerce & consumer tech
Headquarters
Bengaluru, India
Main India offices
Bengaluru
Myntra Frontend Development interview process
Online assessment (coding or SQL)
Technical or machine coding round
Problem solving or case round
Hiring manager round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for MyntraStart 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
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.
02
How do environment variables work in frontend builds, and what is the risk?
Build tools replace variables at build time, for example Vite exposes only variables prefixed with VITE_ through import.meta.env. The values become plain text inside the JavaScript bundle that anyone can read. So frontend environment variables must never hold secrets like private API keys or database passwords; those belong on a server or backend proxy. Use them only for public configuration such as API base URLs.
03
Errors from failed promises are silently disappearing in production. How do you catch them?
Promises without a catch produce unhandled rejections that do not stop the app but hide failures. I would add a global window.addEventListener('unhandledrejection') handler and window.onerror that report errors to a monitoring tool like Sentry with source maps. In code, every async call should have try and catch or a .catch, and ESLint rules such as no-floating-promises in TypeScript projects catch missing handlers.
04
Why use requestAnimationFrame instead of setTimeout for animations?
requestAnimationFrame runs your callback right before the browser paints the next frame, usually 60 or 120 times per second matching the display. It pauses in background tabs, saving battery, and avoids the drift and dropped frames that setTimeout causes because timers are not synced with rendering. The callback receives a high-precision timestamp, so animations can be calculated from elapsed time rather than fixed steps.
05
A dashboard must show live order updates. Would you use polling, Server-Sent Events or WebSockets?
Polling is simplest and fine if updates every 30 seconds are acceptable. Server-Sent Events push one-way updates from server to browser over HTTP with automatic reconnection, ideal for live orders, notifications and stock tickers. WebSockets provide full two-way communication, needed for chat or collaborative editing, but require more infrastructure. For a one-way dashboard, I would choose SSE and reconnect gracefully on network changes.
06
Create a type where all fields are optional except id.
Lab data comes from controlled tests like Lighthouse or WebPageTest on a fixed device and network, which is great for debugging and comparing changes. Field data, or real user monitoring, comes from actual visitors through the Chrome UX Report or your own analytics, capturing real devices, networks and behaviour. Google ranks on field data. A page can score well in the lab but fail in the field on low-end phones.
08
Write a custom type guard to check if a value is a User.
A function returning value is User narrows the type:
interface User { id: number; email: string; }
function isUser(value: unknown): value is User {
return typeof value === 'object' && value !== null &&
'id' in value && typeof (value as User).id === 'number' &&
'email' in value && typeof (value as User).email === 'string';
}
const data: unknown = JSON.parse(raw);
if (isUser(data)) console.log(data.email);
Inside the if block, data is treated as User.
09
Management requires 100 percent code coverage, but bugs still appear. How do you respond?
Coverage shows which lines ran, not whether the behaviour was verified, so tests can execute code without meaningful assertions. I would explain this with an example and propose a balanced target, perhaps 80 percent on business logic, combined with quality measures like mutation testing, critical user flows covered by end-to-end tests and tracking escaped defects. Effort is better spent on risky areas than on trivial getters.
10
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.
Web Components are native, framework-independent reusable elements built from Custom Elements, Shadow DOM and HTML templates. Shadow DOM attaches an encapsulated DOM tree to an element, so its styles do not leak out and page styles do not leak in, except through CSS custom properties and ::part. They are used for design systems shared across React, Angular and plain HTML apps. Server rendering and form participation need extra work.
12
Build an API client that refreshes an expired access token once and retries.
I would introduce scoping so styles cannot leak, using CSS Modules or a consistent naming convention per team, and organise global styles with cascade layers for reset, tokens, components and utilities. A shared design token set and component library reduces one-off styles. Linting with Stylelint, visual regression tests in CI and clear ownership of global files prevent new conflicts.
Throttle allows a function to run at most once in a given interval:
function throttle(fn, wait) {
let last = 0;
return function (...args) {
const now = Date.now();
if (now - last >= wait) {
last = now;
fn.apply(this, args);
}
};
}
window.addEventListener('scroll', throttle(updateProgressBar, 100));
Unlike debounce, which waits for calls to stop, throttle fires regularly during continuous events such as scrolling or dragging.
15
What are long tasks and why do they hurt user experience?
A long task is any main-thread work lasting more than 50 milliseconds. While it runs, the browser cannot respond to taps or paint updates, so the page feels frozen. Common sources are large script evaluation, heavy JSON processing, big framework re-renders and third-party scripts. The Performance panel highlights them with red corners, and splitting work into smaller chunks or moving it to a worker keeps the page responsive.
16
Why do build tools add content hashes to filenames?
A content hash, like main.8c1f2a.js, changes only when the file's contents change. This lets servers cache assets for a year without worrying about stale code, because a new deploy references new filenames from fresh HTML. Unchanged chunks keep their hashes, so users re-download only what changed. Splitting vendor code into its own chunk improves this, since libraries change less often than app code.
17
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.
18
How would you choose a frontend framework for a new project?
I would base it on project needs and team context rather than trends: team experience, hiring market in India, SEO and rendering requirements, ecosystem maturity, long-term support and performance on target devices. React has the largest ecosystem and talent pool, Angular suits large enterprise teams wanting an opinionated structure, Vue is approachable, and Svelte or Astro produce less JavaScript. A small proof of concept helps confirm the choice.
TypeScript enums generate runtime JavaScript objects, and numeric enums accept any number, which weakens safety. String literal unions like type Status = 'draft' | 'published' have zero runtime cost, work naturally with JSON and give the same autocomplete. When you need a runtime list of values, an as const object plus a derived type works well. Many teams avoid enums, especially since type-stripping tools do not support them.
20
Field agents need a form app that works in areas with no internet. How would you build it?
I would build an offline-first PWA: a service worker caches the app shell, and submissions are saved in IndexedDB with a sync status. When connectivity returns, a background sync or online event uploads pending records with idempotency keys so retries never create duplicates. The UI clearly shows synced and pending items. Conflict rules, such as server timestamps winning, must be agreed with the backend team.
21
Test a DOM form with Testing Library and user-event.
Simulate real typing and clicks:
import { screen } from '@testing-library/dom';
import userEvent from '@testing-library/user-event';
import { mountSignupForm } from './signup';
it('shows an error for an invalid mobile number', async () => {
document.body.innerHTML = '<div id=app></div>';
mountSignupForm(document.getElementById('app'));
const user = userEvent.setup();
await user.type(screen.getByLabelText('Mobile'), '12345');
await user.click(screen.getByRole('button', { name: 'Sign up' }));
expect(screen.getByRole('alert')).toHaveTextContent('Enter a valid mobile number');
});
toHaveTextContent comes from @testing-library/jest-dom.
22
An audit finds twenty performance issues. How do you decide what to fix first?
Situation: a Lighthouse and field data audit of our app listed many issues. Task: I had one sprint to show improvement. Action: I ranked issues by user impact and effort, focusing first on the LCP image, render-blocking CSS and one oversized library on the most visited pages. Result: these three fixes delivered most of the gain, and I scheduled the remaining smaller items into later sprints.
23
Production builds take eight minutes on an old webpack setup. How would you speed them up?
I would profile the build to find slow loaders and plugins. Quick wins include replacing Babel and Terser with SWC or esbuild, enabling persistent filesystem caching, and removing unused plugins. For a bigger gain, I would evaluate migrating to Vite or Rspack, which keeps webpack-compatible config. In CI, caching dependencies and build outputs and running only affected packages in a monorepo cut time further.
24
Users report errors you cannot reproduce. How do you set up frontend observability?
I would add an error monitoring tool like Sentry with uploaded source maps, release tags and user context such as browser and route, without personal data. Real user monitoring tracks Web Vitals and slow API calls. Breadcrumbs of clicks and network requests before an error help reproduce issues, and session replay with privacy masking shows what users saw. Alerts on error spikes after a release enable quick rollbacks.
25
How can you communicate between multiple tabs of the same site?
BroadcastChannel lets same-origin tabs, windows and workers publish and subscribe to messages on a named channel, which suits syncing logout, theme or cart updates. The storage event fires in other tabs when localStorage changes, which is a simple fallback. SharedWorker can hold shared state for all tabs. Each option works only within the same origin, so cross-domain sync needs a server or postMessage.
26
The frontend test suite takes 20 minutes in CI. How do you make it faster?
I would measure which tests are slowest. Options include running tests in parallel and sharding across CI machines, moving logic checks from end-to-end tests into faster integration tests, reusing logged-in state instead of logging in every time, and running only tests affected by changed files on pull requests with the full suite nightly. Replacing real network calls with MSW and caching dependencies also helps.
27
Model API request state with a discriminated union.
A shared status field lets TypeScript narrow each case:
type ApiState<T> =
| { status: 'idle' }
| { status: 'loading' }
| { status: 'success'; data: T }
| { status: 'error'; message: string };
function render(state: ApiState<string[]>) {
switch (state.status) {
case 'success': return state.data.join(', ');
case 'error': return 'Error: ' + state.message;
default: return 'Loading...';
}
}
Impossible states, like having both data and an error, cannot be represented.
28
Write a React custom hook that fetches data and cancels on unmount.
I would first write characterisation tests that capture the current behaviour, including odd cases, by calling the module with real inputs and recording outputs. With that safety net, I make small refactors to separate logic from DOM or network code, adding focused tests as I go. Then I implement the change. Small commits and feature flags let me release gradually and roll back quickly if something breaks.
30
Cancel an older search request when the user types again using AbortController.
Keep a controller per request and abort the previous one:
let controller;
async function search(term) {
controller?.abort();
controller = new AbortController();
try {
const res = await fetch('/api/search?q=' + encodeURIComponent(term), {
signal: controller.signal
});
renderResults(await res.json());
} catch (err) {
if (err.name !== 'AbortError') showError(err);
}
}
This prevents slow old responses from overwriting newer results.
Tips to crack the Myntra Frontend Development interview
Prepare cases on fashion e-commerce issues like returns due to size, discount depth or End of Reason Sale planning.
Practise SQL and Python for analytics roles, including cohort and funnel analysis on order data.
Read about Myntra's use of data science in size recommendations and visual search.
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; Myntra interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Myntra Frontend Development interview?
Candidates usually go through 4 stages: Online assessment (coding or SQL); Technical or machine coding round; Problem solving or case round; Hiring manager 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 Myntra Frontend Development interview?
This practice set leans on Frontend Architecture (6), Frontend Testing (5), Build Tools and Tooling (4), TypeScript (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Myntra interviewers ask you to walk through real work.
Are these the exact questions asked at Myntra?
No. These are curated practice questions that match the skills and difficulty usually tested in e-commerce & consumer tech interviews like Myntra's. They are not a leaked or verified list of past questions.
Where does Myntra hire Frontend Development professionals in India?
Myntra has large teams in Bengaluru. Openings and locations change often, so check the Myntra careers page and filter by city and experience.
Frontend Development questions for similar companies