React Developer Interview Questions Indian Companies Actually Ask
React interview preparation content is full of questions nobody asks. Here is what actually comes up in Indian hiring loops, based on the patterns that repeat across startup and enterprise interviews, and what separates an answer that passes from one that impresses.
The JavaScript round comes first, and it is where most people fail
Before anyone asks about React, expect thirty minutes of plain JavaScript. Closures, the event loop, promise ordering, this binding, and prototypal inheritance. The single most common rejection reason for React candidates is weak JavaScript underneath.
A very common question: given a snippet mixing setTimeout, a resolved promise and synchronous logs, what is the output order? If you cannot explain the macrotask and microtask queues confidently, spend a weekend there before anything else. It comes up constantly.
Hooks questions, and what they are really testing
Why do we need a dependency array in useEffect? The weak answer is "so the effect runs when things change". The strong answer explains that the effect closes over the render it was created in, so a stale dependency means the effect body sees stale values, and then gives an example of a bug that causes.
When would you use useMemo or useCallback? Interviewers ask this hoping you say "not by default". A strong answer notes that both have a cost, that useCallback is usually pointless unless the child is memoised or the value is an effect dependency, and that you reach for them after measuring, not before.
What actually causes a re-render? State change, parent re-render, or context value change. Candidates who confidently say "prop change" are usually about to get a follow-up they cannot answer, because a parent re-render re-renders children whether or not props changed.
useState versus useReducer. Say that once several pieces of state change together in response to the same event, a reducer keeps transitions explicit and testable. Then mention that you would not reach for it on a two-field form.
The practical round
Most Indian companies now include a live build or a take-home. Common tasks: a search input with debouncing, a paginated list with loading and error states, a modal with correct focus handling, or a form with validation.
What gets marked, in roughly this order:
- Did you handle the loading state, the error state and the empty state, and are the error and empty states distinguishable?
- Did you clean up — abort the fetch or cancel the timer — when the component unmounts?
- Are keys on lists stable and derived from data, not the array index?
- Is the markup accessible enough that a keyboard user can complete the task?
Candidates lose most points on the first one. Building the happy path and stopping there reads as inexperience, because in production the unhappy paths are most of the work.
Questions that separate mid from senior
How would you improve the performance of a page that feels slow? A junior answer jumps to React.memo. A senior answer starts by asking what "slow" means — first load or interaction — then talks about measuring before changing anything, and only then discusses code splitting, bundle size, image handling, list virtualisation and render cost, in that order.
How do you decide what state lives where? Look for the distinction between server state and client state. Senior candidates separate cached remote data from genuine UI state and note that conflating the two is the source of most state management pain.
How would you structure a component library for a team of fifteen? This is about API design, versioning, documentation and how you stop the library from becoming a dumping ground.
What to ask them
Ask how they handle data fetching and caching, how much test coverage the front end really has, and what the last performance problem they fixed was. The answers tell you a great deal about what your day would look like, and asking them signals seniority better than any answer you give.
