yoklainterview sim

React Frontend Interview Questions

450 verified React Frontend interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

React Components JsxDifficulty 1
In React, what does JSX actually compile down to at build time?
  • aCalls to React.createElement(type, props, ...children) building a plain JS object tree
  • bA template string parsed by the browser at page-load time
  • cA set of document.createElement DOM calls executed during compilation
  • dA JSON configuration file describing the component tree
Explanation:JSX is syntactic sugar; a build tool (the JSX transform) turns <h1 className="title">Hi</h1> into React.createElement('h1', {className: 'title'}, 'Hi'), a plain JS call that builds an object tree describing the UI. Option (b) confuses it with a runtime template engine, (c) confuses build-time createElement calls with actual DOM manipulation, and (d) isn't a JSON artifact at all — it's JavaScript.
React Components JsxDifficulty 1
Which attribute is used to apply a CSS class to a JSX element?
  • aclass, exactly like in plain HTML markup
  • bclassName, since class is a reserved JavaScript word
  • ccssClass, a name unique to JSX components
  • dstyleName, matching the inline style prop
Explanation:JSX attributes ultimately become JavaScript object properties, and class is a reserved keyword in JS, so React uses className instead (which is applied to the DOM's actual class attribute under the hood). Using class directly doesn't apply the styling as expected and triggers a console warning; (c) and (d) aren't the prop names React actually defines.
React Components JsxDifficulty 2
What happens with this component?
function Banner({show}) {
  return (
    <div>
      {if (show) { 'Visible' }}
    </div>
  );
}
  • aIt renders "Visible" whenever show is true, and nothing when it's false
  • bIt renders an empty <div>, no matter what show is
  • cIt never compiles at all, since if is a statement, not an expression
  • dIt renders the literal text "if (show) { 'Visible' }"
Explanation:JSX curly braces {} only accept an expression that evaluates to a value (a string, number, element, etc.); if is a statement, not an expression, so this code is a syntax error and never actually runs. To conditionally render, the usual approach is a ternary (show ? 'Visible' : null) or &&.
React Components JsxDifficulty 2
A teammate defines a component this way and renders it with <userCard name="Ada" />:
function userCard({name}) {
  return <div>{name}</div>;
}

What actually happens?
  • aReact calls userCard and renders "Ada" inside a <div>
  • bReact throws a compile-time error over the lowercase name
  • cReact renders correctly but logs a lowercase-naming warning
  • dReact treats userCard as an unknown host tag name
Explanation:JSX treats a lowercase tag as a host (DOM) element, so <userCard /> is emitted as a literal <usercard> tag and the function is never called — the component silently renders nothing. React does log a dev warning here ("<userCard /> is using incorrect casing…"), but a warning is not the failure: the failure is that the component never runs. Components must start with a capital letter.
React Components JsxDifficulty 1
A junior dev writes:
function Toolbar() {
  return (
    <button>Save</button>
    <button>Cancel</button>
  );
}

What happens when this file is compiled?
  • aIt never compiles, since a component needs a single root JSX node
  • bBoth buttons render inside an implicit wrapper <div>
  • cOnly the first <button> renders; the second is dropped
  • dBoth render fine, but React logs a missing-key warning
Explanation:return can only be followed by one expression, and JSX with two adjacent top-level elements isn't valid syntax — there's no implicit array or wrapper created for it. The fix is to wrap them in one parent element or a Fragment (<>...</>), which was confirmed to render both children without adding an extra DOM node.
React Components JsxDifficulty 3
A TodoList component receives an array through props.todos and, directly inside its render logic, does:
function TodoList({todos}) {
  todos.push({id: Date.now(), text: 'new'});
  return <ul>{todos.map(t => <li key={t.id}>{t.text}</li>)}</ul>;
}

What's the real problem with this code, beyond style preference?
  • a.push is a deprecated array method in modern JavaScript
  • bIt mutates array data that is owned by the parent, not the child
  • ckey={t.id} is invalid since id is a number, not a string
  • dArrays passed as props are frozen, so the component crashes
Explanation:React's contract is that a component must never write to its own props — props flow one-way, from parent to child, and the underlying data belongs to the parent. todos.push(...) mutates the very array the parent is holding (same reference), so the parent's own data gets changed from the outside in an untracked way, a classic source of hard-to-debug bugs. Arrays aren't frozen by React (ruling out d) and .push isn't deprecated (ruling out a); a numeric id used as a key is perfectly fine, React coerces it (ruling out c).

Test yourself against the 2925-question Frontend bank.

Start interview