What causes a component to render again?
Its own state changing, new props from a parent re-render, a context value it reads changing, or a store subscription updating. Rendering describes the UI; React then decides what to change in the DOM.
React interview questions that check whether you understand rendering and state well enough to build reliable products. Each answer is short, practical and focused on what interviewers actually listen for.
Think you're ready? Take a free assessment20 questions • Free to start • No credit card
Its own state changing, new props from a parent re-render, a context value it reads changing, or a store subscription updating. Rendering describes the UI; React then decides what to change in the DOM.
Keys identify items across renders. With an array index as the key, inserting or reordering makes state follow a position instead of an item, so inputs and selections appear on the wrong row.
State is information you cannot calculate from something else. Anything derivable from props or state should be calculated during rendering rather than stored and kept in sync.
It synchronises a component with something outside React, such as a subscription, a browser API or a network request. It runs after render and should clean up whatever it started.
When several distant components genuinely share ownership of it. Frequent updates through a wide context re-render many consumers, so prefer composition, colocated state or a dedicated store for hot data.
It is a request race. Cancel the previous request or ignore non-latest responses, and prefer a server-state library that handles caching, deduplication and lifecycle.
A callback captured an older value of state or props. Fix it with correct dependencies, the updater form of setState, or a ref when you deliberately need the latest value.
When they avoid meaningful repeated work or keep a stable identity that a memoised child or dependency array depends on. Applied everywhere they add complexity for no gain.
Strict Mode intentionally mounts, unmounts and remounts to expose missing cleanup. If double running breaks something, the effect is missing cleanup or is not idempotent.
Profile the interaction first. Usually the input state re-renders the whole list; isolate that state, defer non-urgent updates, memoise row components or virtualise the list, then re-measure.
By feature boundaries with explicit data access, shared UI primitives, route-level code splitting, error and loading boundaries, and tests that assert behaviour rather than implementation.
Standardise them at the boundary: a server-state layer for status, suspense or shared skeletons for loading, error boundaries plus actionable retries for failures, and no silent empty screens.
Use semantic elements, keep focus management deliberate in dialogs and menus, label controls, ensure keyboard paths work, and test with a keyboard and a screen reader rather than assuming.
Extra state plus an effect to sync it is the most common source of inconsistent UI.
Reach for the profiler first; memoisation is a trade, not a free improvement.
Timers, subscriptions and requests need explicit lifetimes to avoid stale work and leaks.
Tie architecture and performance choices to feedback, accessibility and resilience.
Pick React in InterviewGround to check rendering, state, effects, performance and application design across 20 calibrated questions. You get an immediate score on choice questions, concise feedback on written answers and a topic breakdown of your weakest areas.
Your report shows a readiness score, demonstrated seniority for that assessment, strongest and weakest topics and recommended resources. It is a practice signal—not a hiring decision.
Think you're ready? Take a free assessmentThe study plan behind these questions.
The language fundamentals React behaviour rests on.
From component decisions to whole-application design.
Compare the same problems in another framework.