Frontend Beauty
ESC

Type to search the knowledge base.

Zepto Frontend Interview

Quick-commerce frontend loops often stress machine coding, DOM/CSS, and delivery-speed UI. Composite round types, not a claimed onsite transcript.

advanced5 min read
  • interview-experience
  • zepto

Composite guidance based on publicly shared candidate reports and common hiring patterns for frontend / UI roles at quick-commerce and high-frequency consumer apps. Processes vary by role, level, and year. Always confirm with your recruiter. This is not a claimed onsite transcript and is not affiliated with Zepto.

Zepto frontend interviews often filter on machine coding. The miss is spending the first 25 minutes on a CSS grid for a grocery card while the cart still cannot add an item. Delivery-speed products care whether you can ship a list + cart under time, keep scrolling smooth, and talk about inventory that changes while the user is staring at a 10-minute promise.

DSA still appears. It is rarely the only bar. Treat the UI round as the gate.

Key takeaways

  • Machine coding is frequently the hard filter: working cart beats perfect spacing.
  • Lists, search, and maps show up because that is the consumer surface.
  • Inventory and ETA are stale-by-default. Design for change, not for a static JSON fixture.
  • Confirm OA vs live MC, and whether CSS/DOM without a framework is expected.

Speed, lists, and a hard machine-coding filter

Stage Focus Format
Recruiter / HR Role, notice, location Call
OA (common) Timed DSA in JS Platform
Machine coding List, cart, filters, search 45–90 min
JS / DOM Language, events, CSS layout Editor
HM / culture Pace, ownership Call

Some loops add a second coding round or a lightweight design talk (home feed, store picker, live order tracking). Senior candidates should still be ready for frontend system design. Do not assume a FAANG-shaped five-round packet.

How the machine-coding filter is scored

Interviewers in this product family typically watch for:

  1. MVP in 30–40 minutes: products render, add-to-cart works, totals update
  2. State: cart keyed by sku, not an array you scan with find on every click
  3. List performance: keys, avoid rebuilding the world on one quantity change
  4. UI states: empty store, OOS item, slow image, failed cart add
  5. Layout competence: flex/grid enough to look like an app, not a 2012 blog

Timebox with the machine coding interview framework. If the happy path is not working at 70% time, stop tweaking shadows.

Practice builds that transfer:

Surface Practice page
Catalog + filters Product filters sidebar
Infinite home feed Infinite scroll feed
Cart Shopping cart drawer
Search Autocomplete search box
Store / slot picker Custom dropdown

DOM-only variants exist (no React). Be ready to delegate events on a list root. See event delegation and creating DOM nodes.

function createCart() {
  const qty = new Map(); // sku -> count
  function add(sku) {
    qty.set(sku, (qty.get(sku) || 0) + 1);
  }
  function set(sku, n) {
    if (n <= 0) qty.delete(sku);
    else qty.set(sku, n);
  }
  function count() {
    let n = 0;
    for (const v of qty.values()) n += v;
    return n;
  }
  return { add, set, count, qty };
}

Tiny, boring, and enough to keep totals O(1) to update if you also cache a running total. Interviewers notice when every click remaps a 200-item catalog to compute “3 in cart.”

Speed as a product constraint

Quick commerce is latency-sensitive in two ways: page speed (low-end Android, 4G) and promise speed (minutes, not days). In a design or HM chat, connect UI choices to both.

Inventory flicker is a domain footgun. The card said 4 left; the add returns 409. Show an inline “just went out of stock,” do not toast into the void, and do not leave a ghost quantity in the cart.

JavaScript and DSA

OA and live JS rounds look like other Indian product companies: arrays, hashing, strings, occasional trees. Practice timed: Two Sum, Group Anagrams, Merge Intervals, LRU Cache, Number of Islands. Language: JavaScript unless they tell you otherwise.

Language depth: event loop, closures, promises, flattening, debounce. Use the JavaScript interview guide as a map, not a 200-question list. Output-style warmups: JavaScript output-based questions. List transforms: flatten nested array.

Footguns

  • CSS first, cart last
  • Using array index as React keys on a shuffleable catalog
  • Infinite scroll without a loading sentinel or “end of list”
  • Assuming GPS accuracy on the tracking map
  • Ignoring the OA because “I am a UI person”

Preparation plan (4–6 weeks)

  1. Daily: one timed DSA problem in JS. Log the pattern, not the title.
  2. Twice a week: 60-minute MC from a blank file (list + cart, or filters).
  3. Once a week: teach-back of event loop + one CSS layout (flex vs grid).
  4. Last 10 days: two full mocks. Sleep. Recruiter confirmation of format.

OA tactics if you get a paper: frontend online assessments.

Out loud: “I would spend the first five minutes writing acceptance bullets: render SKUs, add/remove, badge count, empty cart. Cart state is a Map of sku to qty. The list virtualizes if they give me hundreds of rows. Out-of-stock is an item-level error, not a silent no-op. I can talk maps and ETAs in a design follow-up, but I will not start there if the filter round is a cart.”

Further reading