yoklainterview sim
ProgressHistory

Frontend State Management Interview Questions

75 verified Frontend State Management interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

State ManagementDifficulty 1
What is "state" in a UI component?
  • aConfiguration values that are hard-coded once and can never change while the app runs
  • bData a component holds over time that can change and drive what the UI shows✓
  • cThe static HTML structure the browser parses before any scripting has run
  • dStyling rules that determine how the component looks on the screen
Explanation:State is the changing data a component owns; when it changes, the UI is expected to update to reflect it. Hard-coded constants (a) never change, so they are not state, and styling rules (d) describe appearance rather than the data behind the view.
State ManagementDifficulty 2
In component-based UIs, how do state and props differ?
  • aState is passed in from a parent, while props are created and mutated inside the component itself
  • bState and props are two names for the same thing; teams just pick one of them by convention
  • cState is data a component owns and can change; props are values passed in from the outside✓
  • dProps change freely over time, but state is fixed once the component has first been created
Explanation:A component owns and changes its state, while props are inputs handed to it from a parent and are not meant to be rewritten by the child. Option (a) swaps the two definitions, and (d) is backwards — state is exactly the part that is meant to change over time.
State ManagementDifficulty 2
// items is the current state (a list)
function addItem(items, newItem) {
  items.push(newItem)   // add to the same array
  return items
}

The UI decides whether to re-render by comparing references (old === new). Why might the list fail to update on screen?
  • apush mutates the same array, so old and new references are identical and the check sees no change✓
  • bpush returns the new length, so this function ends up returning a number rather than the list
  • cArrays cannot be returned from a function, so the UI receives an empty value back
  • dpush builds a brand-new array, so the old references go invalid and get dropped
Explanation:Mutating in place keeps the same array reference; a reference check (old === new) then reports "no change" and skips the re-render. The fix is to return a new array, e.g. return [...items, newItem]. Option (d) claims the opposite of what push does — push mutates the existing array, it does not create a new one.
State ManagementDifficulty 1
What does the term "prop drilling" describe?
  • aSplitting one large component into several smaller and more narrowly focused components
  • bValidating the values passed into a component before that component starts using them
  • cLoading data from a server the moment a component first appears on the screen
  • dPassing data down through many intermediate components that don't use it themselves✓
Explanation:Prop drilling is threading a value through layers of components that merely forward it to reach a deep child; the middle components gain no use of the data but must relay it. Splitting a component (a) is unrelated decomposition, and validating inputs (b) is a separate concern entirely.
State ManagementDifficulty 2
Two sibling components must stay in sync on one value: a filter dropdown and a results list. Where should that value live?
  • aDuplicate it in both siblings and keep them in sync by copying it over on every change
  • bStore it in a top-level variable outside all components as one global mutable value
  • cLift it into their closest common parent and pass it down to both siblings✓
  • dKeep it inside the dropdown and let the list reach into the dropdown's internal state
Explanation:When two siblings must share a value, the standard move is to lift the state into their nearest common ancestor and pass it down, giving one owner and one source of truth. Duplicating it (a) lets the two copies drift out of sync, and reaching into another component's internal state (d) breaks its encapsulation.
State ManagementDifficulty 3
A cart keeps items in state. A developer also stores totalPrice in state and updates it in the 'add item' handler. A new 'remove item' path is added later but forgets to touch totalPrice. What is the underlying design problem?
  • atotalPrice is derivable from items, so storing it separately lets the two fall out of sync✓
  • btotalPrice should have been stored as a string to sidestep floating-point rounding errors
  • cThe cart keeps too little in state; every value it displays should also be stored explicitly
  • dState must never hold numbers, only the raw items, so totalPrice is simply the wrong type
Explanation:A value that can be computed from existing state (total = sum of item prices) should be derived on render, not stored, because a second stored copy has to be kept consistent by hand and eventually drifts — exactly what happened here. Option (c) is the opposite lesson: storing more derived values multiplies the sync problem instead of solving it.

By specialization

Angular 450JavaScript 450React 450TypeScript 450Vue 450

By seniority

Frontend JuniorFrontend MidFrontend Senior

Other fields

BackendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 2925-question Frontend bank.

Start interview