All posts

Careers · Interview questions · React

React interview questions: the 11 that decide real rounds.

React dominates the Malaysian and remote frontend market, so it dominates the technical round too. These eleven questions cover what junior and early-mid interviews actually probe - with the answers interviewers want, the live follow-ups behind each, and the AI-review round that increasingly decides the offer.

Deric YeeDeric Yee Updated 25 August 2026 12 min read
React code and the React logo on a developer screen

How React gets tested now

React rounds in 2026 come in three shapes, usually combined: concept probes (the eleven below, with live follow-ups), a small build (a validated form, a filterable list - narrated while you type), and the newest fixture, the review round- a component, often AI-generated, that you critique aloud. The shift mirrors the whole market’s move from testing production to testing judgement (the full interview guide covers why), and it rewards one preparation style above all: having genuinely built things, hit the classic bugs yourself, and fixed them. Every answer below is written to that standard - the definition, then the follow-up, then the war story you should be able to attach.

The eleven questions

1. What is a component, and why does React organise UIs this way?

A component is a function that takes inputs (props) and returns what should appear on screen - a reusable, self-contained piece of interface. React organises UIs as trees of components because it makes complexity manageable: each piece can be built, tested, and reasoned about alone, then composed. The answer that scores adds the mental model interviewers listen for: "the UI is a function of state - when data changes, React re-runs the affected components and updates the screen to match." Candidates with that sentence internalised debug React; candidates without it fight React.

2. What are props and state, and how do they differ?

Props are inputs passed from a parent - read-only from the component’s perspective. State is data the component owns and can change, which triggers re-rendering when it does. The classic follow-up is "where should state live?" and the wanted answer is: as close as possible to where it is used, lifted up only when siblings need to share it. Expect a live probe here - "this child needs to update the parent’s data; how?" (pass a setter function down as a prop) - because the props-down-events-up flow is the daily grammar of real React work.

3. Explain useState - and the classic mistake with it.

useState gives a component a piece of state and a setter: const [count, setCount] = useState(0). Calling the setter re-renders with the new value. The classic mistake interviewers probe: mutating state directly (count = 5, or pushing into a state array) - React compares references, so in-place mutation does not trigger re-rendering and the UI silently goes stale. The strong answer includes the fix (always set a NEW value or copy: setItems([...items, newItem])) and, ideally, a war story of hitting the bug yourself - authenticity beats polish in this round.

state-mutation.jsx - the bug every interviewer probes
// The classic live-round bug: mutating state in place
function TodoList() {
  const [items, setItems] = useState(['pay rent'])

  function addItem(text) {
    items.push(text)        // BUG: same array reference -
    setItems(items)         // React sees no change, no re-render
  }

  // Fix: setItems([...items, text]) - a NEW array
}

4. Explain useEffect - what is it for, and what are the dependency-array rules?

useEffect runs side effects after render - data fetching, subscriptions, timers, anything that touches the world outside the component. The dependency array controls when it re-runs: empty array = once on mount; listed values = whenever those change; no array = every render (usually a bug). The follow-ups interviewers love: "what happens if you forget a dependency?" (stale values - the effect closes over old state) and "what is the cleanup function for?" (undoing subscriptions/timers when the component unmounts or the effect re-runs). This is the most probed hook in junior interviews because it is the most misused hook in junior code.

5. Why does React need keys when rendering lists?

Keys give React a stable identity for each list item so it can match old and new items efficiently when the list changes, preserving state and avoiding needless re-renders. Using array index as the key breaks when the list reorders or items are inserted - state sticks to the wrong rows (the classic bug: type in a list of inputs, delete a row, and text jumps to the wrong input). The wanted answer: use a stable unique id from your data, and know the index-key failure story - interviewers ask this precisely because the bug is invisible until it isn’t.

6. What causes a React component to re-render?

Three triggers: its own state changed, its props changed, or its parent re-rendered (children re-render with parents by default). The follow-up chain goes: "is re-rendering expensive?" (usually no - render is cheap, DOM updates are minimised; premature optimisation is the real smell) and "when would you reach for memo/useMemo/useCallback?" (measured hot paths: expensive computations, stable references for deeply-passed callbacks). The senior-signal answer resists over-optimising: "I write it plainly first and optimise what profiling shows" - interviewers hear memo-everything answers as tutorial-learned, not experience-learned.

7. How do you fetch and display data from an API in React?

The baseline answer: an effect (or a framework loader) fetches on mount, state holds the three phases - loading, data, error - and the JSX renders each phase explicitly. The differentiating detail is naming all three states: interviewers report that juniors who forget loading and error handling in the live round are the norm, so being the candidate who says "first I handle the unhappy paths" stands out immediately. Mentioning modern data libraries (React Query/SWR) or Next.js server components as the production approach earns credit - but only after demonstrating you understand what they abstract.

8. What is "lifting state up", and when does it stop scaling?

When two sibling components need the same data, the state moves up to their common parent, which passes it down - the standard React sharing pattern. It stops scaling when state is needed across distant branches: you get prop drilling (passing props through layers that don’t use them). The escalation ladder interviewers want to hear: lift state → composition tricks → context for genuinely app-wide data (theme, user session) → a state library only if complexity truly demands it. Jumping straight to Redux for a form is the over-engineering tell; never having heard of context is the under-engineering one.

9. What is the difference between controlled and uncontrolled form inputs?

Controlled inputs hold their value in React state (value + onChange) - the component is the source of truth, enabling live validation, formatting, and conditional logic. Uncontrolled inputs let the DOM hold the value, read on submit via a ref - less code for simple forms. The practical answer: default to controlled for anything with validation or interactivity; uncontrolled is fine for simple fire-and-forget forms. This question survives because forms are the bulk of real business UI - and the live exercise "build a small validated form" remains one of the most common practical rounds in Malaysian interviews.

10. What are Server Components / what does Next.js add to React?

Junior interviews increasingly touch this because the market standardised on Next.js. The satisfying answer at junior level: Next.js adds routing, server rendering, and build tooling; Server Components run on the server and send HTML (not JavaScript) to the browser - faster loads, direct data access, smaller bundles - while Client Components ("use client") handle interactivity. Know the practical division: server by default, client where there are event handlers and state. Deep RSC internals are not junior material; knowing WHERE code runs, and why it matters for speed and data access, is.

11. The AI-era question: here is an AI-generated React component - review it aloud.

The round that now decides premium offers. The reliable checklist to narrate: state mutations (AI frequently mutates arrays/objects in place - the silent re-render killer), effect dependencies (missing or excessive), key usage in lists (index keys everywhere), missing loading/error states in data fetching, and accessibility basics (labels, button vs div). Then the judgement layer: does this component fit the codebase’s patterns, and is it doing too much? Close with the sentence that frames all of it: "AI wrote the draft; the review is my job - this is what I would send back before merging." Interviewers are testing whether you can supervise the tool that writes most 2026 React - demonstrate the supervision.

The preparation that actually moves the needle

Notice what the eleven have in common: every single one maps to a bug or decision you meet within weeks of building real React. That is the preparation insight - one deeply-built project teaches this entire page as lived experience: your list app breaks on index keys, your form needs controlled inputs, your fetch needs three states, your siblings need lifted state. Build one real application (the criteria for making it portfolio-grade are in the portfolio guide), and interview prep becomes revision instead of memorisation. Then add the two drills: daily explain-aloud practice on one topic, and weekly AI-review practice - generate a component, critique it against question 11’s checklist, out loud. Those drills are also, not coincidentally, the daily shape of the job itself.

If the page reads as new information rather than revision, start further back - fundamentals first, then React through real builds, which is precisely the sequence of our programme and its free first week: the free trial’s six projects with a live instructor session, one signup, no card. The market’s reward for closing the gap is documented: React-capable, AI-fluent juniors start at RM 6,000–9,000/month in Malaysia.

FAQ

  • How much React do I need for a junior interview?

    The eleven topics on this page are the real syllabus: components and the UI-as-function-of-state model, props/state and data flow, useState and useEffect deeply (including the classic mistakes), keys, re-rendering, data fetching with all three phases, state architecture (lifting, context), forms, the Next.js/server-component division, and AI-code review. Notably absent: class components (legacy - mention you can read them), deep performance internals, and exotic patterns. Depth on the core beats breadth on the exotic, because live follow-ups punish shallow coverage.

  • Should I learn React or Next.js for the Malaysian job market?

    Both, in that order - they are not competitors. React is the foundation (and the interview subject); Next.js is how the market ships React (and increasingly appears in job requirements). The efficient sequence our own curriculum uses: React fundamentals through small projects, then Next.js as the production framework for real full-stack builds - by interview time you speak both fluently and can explain what Next adds, which is itself a common question (question 10 on this page).

  • What React projects best prepare me for these questions?

    Projects that force the questions’ content naturally: anything with a list you can add to and delete from (keys, state immutability), a form with validation (controlled inputs), API data with slow/failing endpoints (the three fetch phases), and shared state across pages (lifting, context). One well-built booking or inventory app touches all eleven topics - which is why interview prep and portfolio building are the same activity done properly, as the portfolio guide argues. Build one real thing deeply; the answers accumulate as bugs you personally fixed.

  • Are React interviews done with AI tools allowed?

    Increasingly yes - and it changes preparation more than people expect. When tools are allowed, the test shifts from producing the component to directing and reviewing the production: interviewers watch what you accept, what you question, and what you catch (stale closures, mutations, index keys - the classics AI still generates). Practise both modes: build small React pieces with AI while narrating your review aloud, and without AI to keep raw fluency honest. The review checklist in question 11 is the drill; run it weekly and both interview formats become comfortable.

Every question here is a bug you can meet this week.
Build one real thing; the answers accumulate.

Six real projects with a live instructor session - free. The React answers that survive follow-up questions are the ones you earned by fixing the bugs yourself.