Meesho frontend engineer interview questions and process

The candidate finished a genuinely clean product listing page. Virtualised list, memoised rows, nice skeleton states. The interviewer said: "Now run it on a ₹7,000 Android phone on a 3G connection in a town with one tower." Long pause. "...It would be slow." "Right. That's most of our users. What do you cut?"

That constraint is the whole personality of Meesho frontend engineer interview questions. Meesho's growth came from tier-2 and tier-3 India, where the median device is cheap and the network is unreliable, so "make it fast" is not a nice-to-have round — it is the product. This guide covers the loop, the machine coding round, the JavaScript depth and the performance questions.

The Meesho frontend engineer interview process in 2026

Meesho hires frontend engineers into the user app, seller/supplier tooling and internal platform teams, mostly in Bengaluru. The reported Meesho frontend engineer interview process:

• Online assessment — DSA problems plus, in some drives, a JavaScript output-prediction section.
• DSA round — LeetCode easy-to-medium. Arrays, strings, hashmaps, occasionally trees. Real but not the deciding round.
• Machine coding round — 60 to 120 minutes building a working UI component or mini-app in React (or vanilla JS). The signature round.
• JavaScript and frontend fundamentals — closures, event loop, promises, this, plus React internals and rendering behaviour.
• Performance / system design for frontend — bundle size, rendering strategy, caching, offline behaviour, Core Web Vitals.
• Hiring manager round — ownership, working with product and design, and a tradeoff you made under a deadline.

The machine coding and performance rounds carry the weight. A candidate with strong DSA and no opinion about bundle size does not clear this loop.

JavaScript fundamentals questions

The Meesho JavaScript interview questions go for internals rather than syntax. The reliable list: closures and a practical use, the event loop with microtasks versus macrotasks, this binding across regular and arrow functions, prototypal inheritance, debounce versus throttle (usually asked as "implement it"), event delegation and bubbling, and shallow versus deep copy.

Implementing debounce by hand is close to guaranteed, and the version that scores includes cancellation and correct this:

function debounce(fn, delay = 300) {
  let timer = null;

  function debounced(...args) {
    // Preserve `this` so it works as an object method too
    const ctx = this;
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(ctx, args), delay);
  }

  debounced.cancel = () => clearTimeout(timer);
  return debounced;
}

Expect the follow-up: when would you use throttle instead? Debounce waits for the pause and is right for search-as-you-type; throttle guarantees a call every N ms and is right for scroll and resize handlers. Then the practical one — "the user types fast on a slow network and responses arrive out of order, what breaks?" The answer is request cancellation (AbortController) or sequence checking, and volunteering it unprompted is a strong signal. Our JavaScript interview questions guide covers the full syllabus.

On React specifically: reconciliation and why keys matter, useMemo and useCallback and — importantly — when they are premature, the difference between useEffect and useLayoutEffect, why a state update inside render loops forever, controlled versus uncontrolled inputs, and context re-render behaviour. Our React interview questions guide covers these in depth.

The Meesho machine coding round

This is the round to prepare for specifically. The Meesho machine coding round gives you 60 to 120 minutes to build a working component. Reported prompts: an infinite-scroll product list, a search bar with debounced suggestions, a shopping cart with quantity controls, a star-rating component, an image carousel, a multi-step form, a nested comment thread, and an autocomplete with keyboard navigation.

What is scored:

• It works. A running two-thirds beats a beautiful non-compiling whole. Get one path working early.
• All the states. Loading, empty, error, success — plus, at Meesho, the slow-network state. Skeletons over spinners, and never a layout that jumps when data arrives.
• Component decomposition. Presentational components separate from data fetching; logic pulled into hooks.
• Accessibility basics. Keyboard navigation on the autocomplete, focus management, semantic elements. Frequently mentioned, rarely done by candidates.
• Edge cases said aloud. Rapid typing, duplicate requests, an empty result, a failed image.
• Performance instincts. Virtualisation on a long list, lazy images, and not re-rendering the whole list when one row changes.

Narrate as you build — "I'm debouncing at 300ms because on a 3G connection a 150ms debounce still fires three requests before the first returns" is the kind of sentence that wins this round. Our machine coding round guide covers timeboxing and the checklist.

Performance for low-end devices: the Meesho round

Back to the ₹7,000 phone. This round asks how you make a rich commerce UI usable on constrained hardware and networks, and there is a real answer structure:

• Ship less JavaScript. The dominant cost on a cheap phone is not download, it is parse and execute on a weak CPU. Code splitting by route, tree shaking, dropping heavy dependencies (a date library for one function, a full UI kit for four components), and measuring with a bundle analyser.
• Render strategy. Server-side rendering or static generation for the listing pages so content paints without waiting on JS. Say why: on a slow CPU, hydration is the expensive part, so partial or progressive hydration matters.
• Images. Usually the largest payload in commerce. Modern formats (WebP/AVIF), responsive srcset, lazy loading below the fold, explicit width and height to prevent layout shift, and a low-quality placeholder.
• Core Web Vitals, named properly. LCP (largest contentful paint — usually the hero product image), INP (interaction to next paint, which replaced FID and is the one that suffers most on weak CPUs), and CLS (layout shift, caused by images and ads without reserved space).
• Network reality. Caching with service workers, optimistic UI for cart actions, retry with backoff, and designing for the request that never returns rather than the one that fails fast.
• Measure on real devices. Chrome DevTools CPU throttling at 4–6× and network throttling, plus real-user monitoring rather than only lab scores. Saying "I'd test on a real low-end device, not just throttled desktop" is a strong, honest answer.

The mature closing note: name what you would not do. Removing all animation makes the app feel broken rather than fast; the goal is perceived performance, not a Lighthouse trophy. Our frontend developer interview questions guide covers the broader syllabus and the HTML and CSS interview questions guide covers the layout-shift material.

The hiring manager round

Meesho's manager round is about shipping under constraints. Expect: a time you cut scope to hit a date, a disagreement with a designer or PM, how you decide what to do when analytics say one thing and a stakeholder says another, and what you did when something you shipped regressed a metric.

Answers should carry numbers. "We cut the animated filter drawer to a simple modal, shipped four days earlier, and conversion was flat — so we never rebuilt it" is a complete story: decision, tradeoff, measurement, and the discipline not to gold-plate. Our tell me about a time you disagreed guide covers the structure.

LeetCode, frontend practice sites, ChatGPT — where each fits

• MDN and web.dev — the best free sources for the JavaScript internals and the Core Web Vitals material, and more accurate than most courses.
• GreatFrontEnd, Frontend Mentor and BigFrontEnd.dev — the closest practice to the machine coding round and the implement-debounce family. Genuinely high-yield here.
• LeetCode — easy-to-medium band only. It is a gate, not the deciding round; do not over-invest.
• Building one thing and profiling it — highest yield. Build the product list, throttle the CPU 6× in DevTools, and watch it fall apart. That experience is the performance round.
• GeeksforGeeks and AmbitionBox experiences — useful for round order and recurring prompts; treat details as approximate and dated.
• ChatGPT — good for reviewing a component and generating practice prompts. It will not put your clean code on a cheap phone and ask what you cut.
• Greenroom — the spoken layer. Ari, the AI interviewer, runs the fundamentals and performance rounds out loud, pushes when your optimisation answer is a checklist rather than a diagnosis, and scores structure and clarity. Fair tradeoff: Ari will not run Lighthouse for you.

How to prepare for the Meesho frontend interview

• Week 1: JavaScript internals with hand-written implementations — debounce, throttle, deep clone, promise-all, event emitter. Explain each aloud in ninety seconds.
• Week 2: machine coding under a timer, three builds, always with all states, keyboard access and one deliberate performance decision.
• Week 3: performance. Build something real, throttle CPU 6× and network to slow 3G, measure LCP, INP and CLS, then fix them and record what actually moved.
• Final week: React internals revision, two behavioral stories with numbers in first person, and two full spoken mocks with follow-ups.

Interviewing across Indian consumer tech? The general Meesho interview questions guide covers the company-wide loop, the Flipkart frontend engineer guide and Swiggy frontend engineer guide cover the nearest comparisons, and the CRED Android engineer guide covers the mobile equivalent.

Frequently asked questions

What is the Meesho frontend engineer interview process?

Candidates report an online assessment with DSA problems and sometimes JavaScript output prediction, a LeetCode easy-to-medium DSA round, a machine coding round of 60 to 120 minutes building a working React component, a JavaScript and React fundamentals round, a frontend performance and design round covering bundle size and Core Web Vitals, and a hiring manager round on ownership and tradeoffs.

What JavaScript questions does Meesho ask?

Recurring questions cover closures with a practical use, the event loop including microtasks versus macrotasks, this binding in regular versus arrow functions, prototypal inheritance, implementing debounce and throttle by hand, event delegation and bubbling, and shallow versus deep copy. Expect follow-ups on request cancellation with AbortController when fast typing on a slow network produces out-of-order responses.

What is asked in the Meesho machine coding round?

You get 60 to 120 minutes to build a working component. Reported prompts include an infinite-scroll product list, a debounced search with suggestions, a shopping cart with quantity controls, a star rating component, an image carousel, a multi-step form, a nested comment thread and an accessible autocomplete with keyboard navigation. Scoring favours working code, all states handled, clean decomposition, accessibility basics and visible performance instincts.

How do you optimise a React app for low-end Android phones?

Start by shipping less JavaScript, because parse and execute on a weak CPU costs more than download — use code splitting, tree shaking and drop heavy dependencies. Use server-side rendering or static generation so content paints without waiting on hydration. Optimise images with modern formats, responsive srcset, lazy loading and explicit dimensions. Then measure INP, LCP and CLS with real devices and CPU throttling rather than lab scores alone.

What are Core Web Vitals and why does Meesho ask about them?

Core Web Vitals are LCP, which measures when the largest content element paints and is usually the hero product image; INP, interaction to next paint, which replaced FID and degrades most on weak CPUs; and CLS, cumulative layout shift, typically caused by images without reserved dimensions. Meesho asks because a large share of its users are on low-end devices and unreliable networks, where these metrics directly affect conversion.

Is the Meesho frontend engineer interview hard?

The algorithmic bar is moderate at easy-to-medium, and it is not where the loop is decided. The difficulty is the machine coding round under time pressure and the performance round, which expects genuine opinions about constrained devices rather than a memorised optimisation checklist. Candidates who have only built on fast laptops and never profiled under CPU throttling find that round significantly harder.