cashkaro Frontend Engineer Interview: Questions, Experience & Prep (2026)

CashKaro is India's largest cashback and coupon platform, backed by well-known investors and used by millions of shoppers. Frontend engineers here build the web and mobile-web experience that helps users discover deals, track cashback, and get paid out. The team ships fast and expects engineers who can own UI features end to end.

As of mid-2026, CashKaro has 46 open roles listed, signalling active hiring across experience levels. Candidates report that the interview process typically runs 2-4 rounds, covering JavaScript and React fundamentals, a live or take-home coding task, and one or two rounds on system thinking and culture fit. The focus is practical frontend engineering, not heavy algorithmic puzzles.

Current market salary ranges for Frontend Engineers in India:

For context on the broader market, there are 405 Frontend Engineer openings tracked across India right now, with Bangalore leading at 102 roles and Delhi at 36.

These questions are compiled from candidate reports and patterns common at product startups of CashKaro's scale. Prepare a concrete answer for each one before you go in.

1. 'Walk me through a React component you built that had real performance issues. How did you diagnose and fix them?'
2. 'Explain how the virtual DOM works and why React re-renders. When would you use React.memo or useMemo?'
3. 'CashKaro shows cashback offers from hundreds of stores. How would you design the frontend architecture for a high-volume listing page that loads fast on slow 4G connections?'
4. 'What is the difference between controlled and uncontrolled components in React? Give a real example of when you chose one over the other.'
5. 'How do you handle global state in a mid-size React app? Walk through your decision between Context API, Redux Toolkit, or Zustand.'
6. 'Describe how event delegation works in JavaScript and why it matters for a page with many dynamic elements.'
7. 'How would you make a coupon card component fully accessible for keyboard and screen reader users?'
8. 'You notice the main feed page has a Largest Contentful Paint of over 4 seconds. What steps do you take to investigate and improve it?'
9. 'How do you handle API errors and loading states in a way that keeps the user experience smooth, not broken?'
10. 'Tell me about a time you disagreed with a design decision. How did you handle it?'
11. 'What is your approach to testing a React component that fetches data and renders a list?'
12. 'How would you implement infinite scroll for a product listing page without causing memory leaks?'

Q: Walk me through a React component you built that had real performance issues. How did you diagnose and fix them?

*Situation:* I was working on a dashboard that listed a long set of transaction cards, each with dynamic cashback amounts and status tags. Users were reporting visible lag when filtering by category.

*Task:* I needed to identify why re-renders were cascading through the list and fix the slowdown without changing the product design.

*Action:* I used the React DevTools Profiler to spot components re-rendering on every keystroke. The root cause was a filter function being re-created on each render and passed down as a prop. I wrapped it in useCallback, memoized the card component with React.memo, and added a virtualized list using react-window so only visible cards stayed in the DOM.

*Result:* Filter interactions went from a noticeable freeze to feeling instant, confirmed by profiler recordings before and after. The fix shipped in the same sprint with no design changes.

---

Q: How would you design the frontend architecture for a high-volume listing page that loads fast on slow 4G?

*Situation:* At my previous role we had a product grid that loaded a full JSON payload upfront, causing slow Time to Interactive on mobile devices.

*Task:* My job was to redesign the data-fetching and rendering strategy to meet a performance target set by the product team.

*Action:* I introduced pagination with cursor-based API calls, lazy-loaded images using the Intersection Observer API, moved non-critical scripts to deferred loading, and replaced spinners with skeleton screens to reduce perceived wait time. I also added a service worker for caching repeated API calls on return visits.

*Result:* Time to Interactive improved measurably on Lighthouse scores, and bounce rate on the page dropped according to our analytics over the following month.

---

Q: Tell me about a time you disagreed with a design decision. How did you handle it?

*Situation:* A designer proposed a coupon reveal animation that required a full DOM remount on each click, which would cause jank on lower-end Android devices.

*Task:* I needed to raise the concern without blocking the feature or damaging the working relationship.

*Action:* I built a quick prototype showing the jank on a throttled device in Chrome DevTools, then proposed an alternative using CSS transitions that achieved the same visual effect. I shared both versions with the designer and the product manager in a short recorded video so they could compare without scheduling a meeting.

*Result:* The team picked my alternative. The designer appreciated having a concrete comparison rather than just a veto, and we shipped on time.

For technical 'how does X work' questions: Start with the core concept in one sentence, give a concrete example, then connect it to a real project decision you made. Avoid textbook definitions. Interviewers at product companies want to know you have used the concept, not just memorised it.

For system or architecture questions: Clarify constraints first (expected scale, device targets, network conditions), then describe your approach in layers: data fetching, component structure, state management, performance. CashKaro's product is consumer-facing and mobile-heavy, so always bring up low-end device and slow-network considerations even when the interviewer does not ask.

For behavioural questions: Use STAR (Situation, Task, Action, Result) but keep Situation and Task brief. Spend most of your time on Action (what exactly you did, which tools you used) and Result (a concrete outcome, even if qualitative). Candidates who dwell on background context and skip results tend to score lower.

For 'tell me about a bug or failure' questions: Pick a real, non-trivial incident. Show that you diagnosed it systematically rather than by guessing. End with what you learned or what you changed in your process afterward, which signals maturity to the interviewer.

CashKaro is a consumer product used by millions of shoppers, so interviewers typically look for engineers who think about real users, not just clean code.

Ownership: They want candidates who say 'I built' and 'I decided', not 'the team built'. Frontend engineers here are expected to take a feature from design handoff to production without hand-holding.

Performance instinct: Because CashKaro's core users are on mid-range Android phones with variable connectivity, candidates who proactively mention LCP, TTI, image optimisation, or lazy loading get noticed. If you wait to be asked about performance, you lose points.

React depth, not just syntax: Knowing useState is not enough. Interviewers probe whether you understand the rendering model, when to lift state, and how to avoid pitfalls like stale closures in hooks or unnecessary context re-renders.

Clear communication: Candidates report that interviewers at growth-stage startups value engineers who can explain a technical decision to a non-technical product manager. Practise thinking out loud during technical rounds so this comes naturally under pressure.

Week 1: Strengthen your JavaScript and React core
Revise closures, prototypes, the event loop, and Promise chaining. For React, go through the rendering lifecycle, reconciliation, and all major hooks (useEffect, useCallback, useMemo, useRef). Build one small project from scratch to cement these concepts in a real context.

Week 2: Frontend system design and performance
Study Core Web Vitals (LCP, CLS, INP) and how to measure them using Lighthouse and Chrome DevTools. Practice designing a listing page, a search-with-filters UI, and an infinite scroll feed on paper or a whiteboard. Write down your reasoning for each architectural choice so you can articulate it clearly under interview conditions.

Week 3: Practice questions and mock interviews
Solve coding problems focused on DOM manipulation, array methods, and async patterns. Record yourself answering 3-4 behavioural questions using STAR and watch it back. Candidates who do this almost always cut filler words and tighten their answers significantly.

Before each round: Use CashKaro's product as a real user. Install the app or visit the site, click through the cashback flow, and notice the UI patterns. Interviewers respond well when a candidate says 'I noticed your offer listing does X, so for the architecture question I was thinking about Y.'

If you are still in the job hunt, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so applications go out in the background while you focus on interview prep.

1. Treating every JavaScript question as a React question. Interviewers ask about closures, 'this', or the event loop to test fundamentals. Jumping straight to React hooks as an answer signals that you only know the framework surface, not the language underneath it.

2. Skipping the 'why' in architecture answers. Saying 'I would use Redux' is not an answer. 'I would use Redux Toolkit here because state is shared across multiple routes and needs middleware for async actions' is. Always justify your choices with a constraint or trade-off.

3. Ignoring mobile and network constraints. CashKaro's user base is largely on mobile. If your architecture answer does not mention lazy loading, image optimisation, or network-aware rendering at least once, you are missing what matters most to this team.

4. Over-engineering the take-home task. Candidates sometimes add authentication, multiple pages, and a backend to a simple component task. Read the brief precisely and deliver exactly what is asked with excellent code quality, rather than a sprawling demo that misses the brief.

5. Not asking clarifying questions during system design. Interviewers expect you to ask about scale, device targets, and browser support before diving into a solution. Starting without questions signals that you design in a vacuum.

6. Weak results in STAR answers. 'The team was happy' is not a result. Tie outcomes to something observable: load time improved, user complaints dropped, the sprint shipped on time. If you have no metric, describe the qualitative impact in specific terms.