React Interview Questions
What Interviewers Actually Ask
LinkedIn Hook
I have sat on both sides of the interview table. I have asked React questions and I have answered them. And here is the brutal truth: the gap between what developers study and what interviewers actually ask is enormous.
Most candidates spend weeks memorizing hook signatures and lifecycle method names. Then the interviewer says "explain what happens when you type a URL and a React app loads" or "how would you optimize a dashboard that renders 10,000 rows" — and the candidate freezes. They studied the API. The interviewer tested the understanding.
Here is the pattern I have seen in over a hundred React interviews: interviewers do not ask you to recite documentation. They ask three types of questions. First, conceptual one-liners — "what is the virtual DOM?" — where they want a confident, precise 15-second answer, not a 3-minute lecture. Second, "explain what happens when..." questions — where they want you to trace execution flow step by step. Third, "how would you optimize..." questions — where they want you to demonstrate real-world problem-solving, not textbook answers.
The candidates who fail are not the ones who know less. They are the ones who cannot explain what they know. They use vague words like "it makes things faster" instead of "React diffs the previous and current virtual DOM trees, computes the minimal set of DOM mutations, and batches them into a single update." Precision wins interviews.
In this final lesson, I am giving you the exact 30 questions interviewers ask most frequently, the "explain what happens" scenarios they love, the optimization questions that separate mid-level from senior candidates, the red flags that get you rejected, and a framework for explaining your React decisions clearly and confidently.
This is not a trivia list. This is an interview survival guide built from real interviews, real rejections, and real offers.
Read the full lesson -> [link]
#React #JavaScript #InterviewPrep #Frontend #WebDevelopment #CodingInterview #100DaysOfCode #TechInterview
What You'll Learn
- The top 30 conceptual React questions interviewers ask with precise one-liner answers
- How to answer "explain what happens when..." questions by tracing execution step by step
- How to approach "how would you optimize..." questions with structured reasoning
- The red flags interviewers look for that get candidates rejected immediately
- A framework for explaining your React architecture decisions clearly and confidently
The Concept — Interviews Are Not Exams, They Are Conversations
Analogy: The Driving Test vs Actual Driving
Imagine two people taking a driving test. The first person memorized the entire driver's manual — every speed limit, every sign code, every regulation number. The examiner asks "what do you do at a yellow light?" and this person recites: "According to section 4.3.2, a steady yellow signal indicates the green signal is ending and you should prepare to stop unless doing so would be unsafe." Technically correct. But robotic.
The second person says: "I check my speed and distance. If I am close enough that braking hard would be dangerous, I proceed through. If I have room, I stop. My decision depends on context." Same knowledge, but this person clearly drives.
React interviews work the same way. The interviewer does not want you to recite documentation. They want to see that you have driven React — that you have hit bugs, made tradeoffs, debugged rendering issues at 2 AM, and formed opinions about why things work the way they do. The questions are just the steering wheel. Your answers show whether you are reading the manual or driving the car.
This lesson teaches you to drive.
Part 1: Top 30 Conceptual Questions With One-Liner Answers
Interviewers often open with rapid-fire conceptual questions. They are not looking for essays. They want sharp, confident, precise answers — ideally under 20 seconds each. If you ramble, they move on. If you nail it in one sentence, they go deeper.
Code Example 1: The 30 Questions — Organized by Category
REACT CORE (Questions 1-10)
==============================================================
Q1: What is React?
A: A JavaScript library for building user interfaces
using reusable, composable components.
Q2: What is the virtual DOM?
A: A lightweight JavaScript object representation of
the real DOM that React uses to compute the minimum
number of actual DOM changes needed after a state update.
Q3: What is reconciliation?
A: The algorithm React uses to diff the previous and
current virtual DOM trees and determine which real
DOM nodes need to be created, updated, or removed.
Q4: What is JSX?
A: A syntax extension that lets you write HTML-like
markup inside JavaScript, which Babel compiles into
React.createElement() calls.
Q5: What is the difference between a controlled and
uncontrolled component?
A: A controlled component stores its form value in React
state and updates via onChange. An uncontrolled
component lets the DOM handle the value and reads it
via a ref when needed.
Q6: What is the key prop and why is it important?
A: The key prop helps React identify which list items
changed, were added, or removed during reconciliation.
Without stable keys, React may reuse the wrong DOM
nodes and cause bugs.
Q7: What is the difference between state and props?
A: Props are read-only data passed from parent to child.
State is mutable data owned and managed by the
component itself.
Q8: Why does React enforce one-way data flow?
A: One-way data flow makes the app predictable — data
always flows from parent to child, so you can trace
where any piece of data comes from by following the
component tree upward.
Q9: What is a React fragment and why use it?
A: A Fragment (<> </> or <Fragment>) lets you group
multiple elements without adding an extra DOM node,
keeping the markup clean.
Q10: What is the difference between React.createElement
and JSX?
A: JSX is syntactic sugar. <Component prop="value" />
compiles to React.createElement(Component,
{ prop: "value" }, null). They produce the same output.
HOOKS (Questions 11-18)
==============================================================
Q11: What are hooks?
A: Functions that let you use state, side effects, and
other React features inside function components
without writing classes.
Q12: What is the difference between useState and useReducer?
A: useState is for simple, independent state values.
useReducer is for complex state logic where the next
state depends on the previous state or when multiple
state values change together.
Q13: Why does useEffect need a dependency array?
A: The dependency array tells React when to re-run the
effect. Without it, the effect runs after every render.
With an empty array, it runs only on mount.
Q14: What is the cleanup function in useEffect?
A: A function returned from useEffect that React calls
before re-running the effect and before unmounting,
used to cancel subscriptions, timers, or event
listeners to prevent memory leaks.
Q15: What is useRef and when do you use it?
A: useRef returns a mutable object whose .current
property persists across renders without causing
re-renders. Use it for DOM references, storing
previous values, or holding mutable values that
should not trigger updates.
Q16: What is useMemo and how is it different from
useCallback?
A: useMemo memoizes a computed value. useCallback
memoizes a function reference. useMemo returns the
result of calling the function. useCallback returns
the function itself.
Q17: What are the rules of hooks?
A: Call hooks only at the top level (not inside loops,
conditions, or nested functions) and only from
function components or custom hooks. This ensures
React can track hook state by call order.
Q18: What is a custom hook?
A: A function starting with "use" that composes built-in
hooks to extract and reuse stateful logic across
multiple components.
PERFORMANCE (Questions 19-24)
==============================================================
Q19: When does a React component re-render?
A: When its state changes, when its parent re-renders
(passing new props), or when a context value it
consumes changes.
Q20: What is React.memo?
A: A higher-order component that memoizes a function
component, skipping re-render if props have not
changed (shallow comparison by default).
Q21: What is code splitting in React?
A: Loading parts of your application on demand using
dynamic import() and React.lazy, so users only
download the code they need for the current view.
Q22: What is the purpose of the React Profiler?
A: A DevTools feature that measures how often components
render, how long each render takes, and what triggered
the render, helping you identify performance
bottlenecks.
Q23: What is list virtualization?
A: A technique that renders only the visible items in a
long list (plus a small buffer), dramatically reducing
DOM nodes and improving scroll performance. Libraries
like react-window implement this.
Q24: What causes unnecessary re-renders?
A: Creating new object or function references in the
render body, not memoizing expensive computations,
passing unstable props to memoized children, or
consuming context that changes too frequently.
PATTERNS AND ARCHITECTURE (Questions 25-30)
==============================================================
Q25: What is prop drilling and how do you solve it?
A: Passing props through many intermediate components
that do not use them. Solve it with Context API,
state management libraries, or component composition.
Q26: What is the Context API?
A: A React feature that lets you share values (theme,
auth, locale) across the component tree without
passing props through every level.
Q27: What is a higher-order component (HOC)?
A: A function that takes a component and returns a new
component with additional props or behavior — a
pattern for reusing component logic.
Q28: What is the difference between server-side rendering
(SSR) and client-side rendering (CSR)?
A: CSR sends an empty HTML shell and JavaScript builds
the page in the browser. SSR generates the full HTML
on the server, sends it to the browser for immediate
display, then hydrates it with JavaScript for
interactivity.
Q29: What is React's Strict Mode?
A: A development-only wrapper that intentionally
double-invokes certain functions (renders, effects)
to help you find bugs like impure renders and
missing effect cleanups before they reach production.
Q30: What is the difference between lifting state up and
using global state?
A: Lifting state up moves state to the nearest common
parent of the components that need it — good for
localized sharing. Global state (Redux, Zustand)
makes state accessible anywhere in the tree — good
for app-wide data like auth or theme.How to use this list: Practice answering each question out loud in under 20 seconds. If you cannot explain it simply, you do not understand it deeply enough. Record yourself. Listen back. Cut the filler words.
Part 2: "Explain What Happens When..." Questions
These are the questions that separate candidates who memorized React from candidates who understand it. The interviewer describes a scenario and asks you to walk through the execution step by step. They are listening for precision and completeness.
Code Example 2: Tracing a setState Call
import { useState } from "react";
// The interviewer shows you this component and asks:
// "Explain what happens when the user clicks the button."
function Counter() {
const [count, setCount] = useState(0);
// When user clicks, what happens step by step?
const handleClick = () => {
setCount(count + 1);
setCount(count + 1);
setCount(count + 1);
console.log(count); // What does this log?
};
console.log("Render with count:", count);
return (
<div>
<p>Count: {count}</p>
<button onClick={handleClick}>Add 3?</button>
</div>
);
}
// Output after clicking the button:
// Console: 0 (the log inside handleClick)
// Console: Render with count: 1
// EXPLANATION (what you should tell the interviewer):
// 1. User clicks the button, handleClick fires.
// 2. setCount(count + 1) is called three times.
// But "count" is a CLOSURE over the current render's value (0).
// So all three calls are: setCount(0 + 1), setCount(0 + 1), setCount(0 + 1).
// 3. React BATCHES these updates. After the event handler finishes,
// React processes the queue: the final value is 1, not 3.
// 4. console.log(count) logs 0 because state updates are asynchronous —
// "count" still refers to this render's snapshot.
// 5. React schedules a re-render. The component function runs again.
// useState(0) returns 1 this time. "Render with count: 1" logs.
// 6. React diffs the new virtual DOM with the previous one,
// finds the <p> text changed, and updates that single DOM node.
// FOLLOW-UP: "How would you make it increment by 3?"
// Answer: Use the functional updater form:
const handleClickCorrect = () => {
setCount((prev) => prev + 1); // prev = 0, result = 1
setCount((prev) => prev + 1); // prev = 1, result = 2
setCount((prev) => prev + 1); // prev = 2, result = 3
};
// Now React processes each updater with the LATEST pending value.
// Final count: 3Code Example 3: Tracing a useEffect Lifecycle
import { useState, useEffect } from "react";
// The interviewer asks: "In what order do the console logs appear
// when this component mounts, then the user clicks the button?"
function EffectDemo() {
const [count, setCount] = useState(0);
console.log("1. Render phase — count is:", count);
useEffect(() => {
console.log("2. Effect runs — count is:", count);
return () => {
console.log("3. Cleanup runs — count was:", count);
};
}, [count]);
return (
<button onClick={() => setCount(count + 1)}>
Increment ({count})
</button>
);
}
// Output on MOUNT:
// "1. Render phase — count is: 0"
// "2. Effect runs — count is: 0"
// Output after CLICKING the button:
// "1. Render phase — count is: 1"
// "3. Cleanup runs — count was: 0" <-- cleanup from PREVIOUS effect
// "2. Effect runs — count is: 1"
// EXPLANATION (what you should tell the interviewer):
// 1. On mount: React calls the component function (render phase),
// paints to the DOM, then runs useEffect asynchronously.
// 2. On update: React calls the component function again with new state.
// Before running the new effect, React runs the CLEANUP from the
// previous effect (with the previous closure values).
// Then the new effect runs with the current values.
// 3. On unmount: React runs the cleanup from the last effect.
// 4. Key insight: each render has its own effect and its own cleanup,
// each closing over that render's state values. Effects are not
// mutating a single callback — each render creates a fresh one.Part 3: "How Would You Optimize..." Questions
These questions test whether you have debugged real performance problems or just read about optimization techniques. The interviewer gives you a scenario and wants a structured approach, not a list of random tools.
Code Example 4: Optimization Strategy Framework
// SCENARIO: "We have a dashboard that renders 5,000 rows in a table.
// Users report that typing in the search filter feels laggy.
// How would you optimize this?"
// STEP 1: Identify the bottleneck (always say this first)
// "Before optimizing, I would use the React Profiler and browser
// DevTools Performance tab to measure what is actually slow.
// Guessing leads to wrong optimizations."
// STEP 2: Apply targeted fixes based on findings
// FIX A: Debounce the search input so we do not filter on every keystroke
import { useState, useMemo, useCallback } from "react";
function Dashboard({ rows }) {
const [searchTerm, setSearchTerm] = useState("");
const [debouncedTerm, setDebouncedTerm] = useState("");
// Debounce: only update the filter after the user stops typing for 300ms
// This prevents filtering 5,000 rows on every single keystroke
const handleSearch = useCallback((value) => {
setSearchTerm(value);
clearTimeout(window._searchTimer);
window._searchTimer = setTimeout(() => {
setDebouncedTerm(value);
}, 300);
}, []);
// FIX B: Memoize the filtered list so it only recalculates
// when debouncedTerm or rows change — not on every render
const filteredRows = useMemo(() => {
return rows.filter((row) =>
row.name.toLowerCase().includes(debouncedTerm.toLowerCase())
);
}, [rows, debouncedTerm]);
return (
<div>
<input
value={searchTerm}
onChange={(e) => handleSearch(e.target.value)}
placeholder="Search rows..."
/>
{/* FIX C: Virtualize the list — only render visible rows */}
{/* Instead of rendering all 5,000 rows: */}
<VirtualizedTable rows={filteredRows} rowHeight={40} />
</div>
);
}
// FIX C implementation sketch using react-window
import { FixedSizeList } from "react-window";
function VirtualizedTable({ rows, rowHeight }) {
// Only renders ~20 visible rows instead of 5,000
// Dramatically reduces DOM nodes and paint time
return (
<FixedSizeList
height={600}
itemCount={rows.length}
itemSize={rowHeight}
width="100%"
>
{({ index, style }) => (
<div style={style}>
{rows[index].name} — {rows[index].email}
</div>
)}
</FixedSizeList>
);
}
// Output:
// Search input responds instantly (debounced, not filtering per keystroke)
// Table renders smoothly (only ~20 DOM rows visible at any time)
// Filtering is efficient (memoized, recalculates only when search changes)
// WHAT THE INTERVIEWER WANTS TO HEAR:
// 1. "I would measure first" — shows you do not guess
// 2. Debounce the input — reduces unnecessary computation
// 3. Memoize the filtering — avoids recalculating on unrelated re-renders
// 4. Virtualize the list — reduces DOM nodes from 5,000 to ~20
// 5. Mention trade-offs: "Virtualization breaks Ctrl+F browser search,
// so I would check if that is a requirement before choosing this approach."Part 4: Red Flags Interviewers Look For
Knowing the right answers is only half the battle. You also need to avoid the signals that make interviewers lose confidence in you immediately.
Red Flag 1: Vague or incorrect fundamentals. Saying "the virtual DOM makes React fast" without being able to explain HOW it makes React fast. The correct framing: "The virtual DOM allows React to batch and minimize real DOM mutations, which are the expensive operations. React itself adds overhead — the benefit comes from intelligent diffing, not from the virtual DOM being inherently fast."
Red Flag 2: Using useEffect as a Swiss Army knife. When an interviewer sees a candidate reach for useEffect to derive computed values, synchronize state with other state, or handle events that should be in event handlers, they see someone who does not understand the React mental model. Derived values belong in useMemo or inline computation. State synchronization often means your state is poorly structured.
Red Flag 3: No mention of trade-offs. When asked "would you use Redux or Context API?" the wrong answer picks one and defends it. The right answer: "It depends on the use case. Context is great for low-frequency updates like theme or auth. Redux handles high-frequency updates better because it avoids the re-render problem that Context has — every consumer re-renders when the context value changes, even if they only use a portion of it."
Red Flag 4: Inability to explain your own project decisions. "Why did you use Redux in your last project?" If you answer "because the team was already using it," that is fine for a junior role. For a senior role, the interviewer expects: "We had 15+ components across 4 routes that needed shared state with frequent updates. Context would have caused cascading re-renders. Redux gave us predictable state updates, time-travel debugging during development, and middleware for async operations."
Red Flag 5: Optimizing without measuring. If you jump straight to "I would use React.memo and useMemo everywhere," the interviewer sees premature optimization. Always lead with: "I would profile the application first using React DevTools Profiler to identify which components are re-rendering unnecessarily and how long each render takes."
Part 5: How to Explain Your React Decisions
Use the STAR-T framework (Situation, Task, Action, Result, Trade-off) for every architecture decision you explain in an interview.
STAR-T FRAMEWORK FOR REACT DECISIONS
============================================================
Situation: "We had a multi-step checkout form with 6 steps,
each step having 5-10 fields with cross-step
validation."
Task: "I needed to choose a state management approach
that could handle complex form state, validate
across steps, and persist progress if the user
navigated away."
Action: "I chose useReducer with a context provider at
the checkout layout level. Each step dispatched
actions like UPDATE_FIELD, VALIDATE_STEP, and
GO_TO_STEP. I stored the form state in
sessionStorage on every dispatch for persistence."
Result: "Form state was predictable — every change went
through the reducer. Debugging was simple because
I could log every action. Cross-step validation
worked because the reducer had the full form state."
Trade-off: "The trade-off was boilerplate — the reducer had
40+ action types. If I did it again, I might use
a form library like React Hook Form with a Zustand
store to reduce the custom code. But for the
deadline we had, useReducer gave us full control
without adding dependencies."
// WHY THIS WORKS:
// - Shows you faced a real problem (not textbook)
// - Shows you evaluated options (not just picked one)
// - Shows you measured results (not just shipped)
// - Shows you would improve it (not defensive about choices)
// - The trade-off is what separates senior from mid-levelCommon Mistakes
Mistake 1: Giving textbook answers instead of demonstrating understanding
// BAD INTERVIEW ANSWER:
// Q: "What is the virtual DOM?"
// A: "The virtual DOM is a programming concept where a
// virtual representation of the UI is kept in memory
// and synced with the real DOM by a library such as
// ReactDOM. This process is called reconciliation."
// (This is the Wikipedia definition. The interviewer has
// heard it 500 times and learns nothing about YOUR
// understanding.)
// GOOD INTERVIEW ANSWER:
// A: "When state changes, React creates a new virtual DOM
// tree — which is just a plain JavaScript object
// describing the UI. It diffs this new tree against the
// previous one using its reconciliation algorithm,
// which works in O(n) time by assuming two elements of
// different types produce different trees. It then
// batches the minimal set of changes and applies them
// to the real DOM in one go. The win is not that the
// virtual DOM is fast — the diffing adds overhead. The
// win is that it minimizes the number of real DOM
// mutations, which are expensive because they trigger
// layout recalculation and repainting."
// (This shows you understand the WHY and the trade-off.)Mistake 2: Not structuring your optimization answers
// BAD: When asked "how would you optimize a slow component?"
// Jumping to: "I would use React.memo and useMemo."
// (This is a guess, not engineering.)
// GOOD: Follow the Measure-Identify-Fix-Verify cycle:
// 1. MEASURE: "First I would open React DevTools Profiler
// and record the slow interaction to see which
// components re-render and how long they take."
// 2. IDENTIFY: "I would look for components that re-render
// but produce the same output, or components with
// renders over 16ms that block the frame budget."
// 3. FIX: "Based on what I find, I would apply the
// appropriate fix — React.memo for stable components
// receiving new object references, useMemo for expensive
// computations, virtualization for long lists, code
// splitting for heavy routes."
// 4. VERIFY: "Then I would profile again to confirm the
// fix actually improved performance and did not
// introduce regressions."Mistake 3: Failing to mention trade-offs on any question
// BAD: "I always use Redux for state management."
// (No technology is always the right choice.)
// GOOD: "I choose based on the problem:
// - Local component state (useState) for UI-only state
// like open/closed modals.
// - useReducer + Context for medium complexity shared
// state like a multi-step form.
// - Redux Toolkit or Zustand for complex, frequently
// updated global state like a real-time dashboard.
// The trade-off with Redux is boilerplate and learning
// curve. The trade-off with Context is re-render
// performance when values change frequently. Zustand
// sits in between — minimal API but less ecosystem
// tooling than Redux."Interview Questions
Q: What happens when you call setState inside a React event handler?
React does not update the state immediately. It queues the update, continues executing the rest of the event handler (during which the old state value is still accessible via closure), then batches all queued updates together after the handler finishes. React calculates the new state, calls the component function again with the new state value, diffs the resulting virtual DOM against the previous one, and applies the minimal set of real DOM changes. Since React 18, this batching also applies to setTimeout, promises, and native event handlers — not just React event handlers.
Q: How would you optimize a React app that feels slow on initial load?
I would start by measuring with Lighthouse and the Network tab to identify the bottleneck. Common fixes: code split routes with React.lazy and Suspense so users only download code for the current page. Tree-shake unused dependencies. Compress assets with gzip or Brotli. Defer non-critical JavaScript with dynamic imports. Use SSR or static generation for above-the-fold content if SEO and first paint matter. Lazy load images below the fold. The trade-off with code splitting is that subsequent navigations require loading new chunks, so I would prefetch likely next routes during idle time.
Q: Explain the difference between useEffect, useMemo, and useCallback. When do you use each?
useEffect runs side effects after render — data fetching, subscriptions, DOM mutations. useMemo memoizes a computed value so expensive calculations only re-run when dependencies change — use it for filtering large lists or heavy transformations. useCallback memoizes a function reference so it stays stable across renders — use it when passing callbacks to memoized child components that would otherwise re-render because of a new function reference. The key distinction: useEffect is for effects (things that happen AFTER render), while useMemo and useCallback are for optimization (things that help React skip unnecessary work DURING render).
Q: A component re-renders but its output has not changed. Why is this happening and how do you fix it?
The most common cause is the parent re-rendering and passing new prop references even though the values are the same — for example, creating a new object literal or arrow function in the parent's render body. To fix it: wrap the child in React.memo so it skips re-render when props are shallowly equal. If the parent passes objects or functions, stabilize them with useMemo or useCallback. But first, I would check if the re-render actually causes a performance problem — React is fast at rendering, and adding memoization everywhere adds complexity and memory overhead for potentially zero user-visible benefit.
Q: How do you decide between Context API and a state management library like Redux or Zustand?
Context API works well for low-frequency updates consumed by many components — theme, authentication status, locale. Its weakness is that every consumer re-renders when the context value changes, even if it only uses part of that value. For high-frequency updates (form state across many fields, real-time data, complex derived state), a library like Redux Toolkit or Zustand performs better because components can subscribe to specific slices of state. My decision framework: if fewer than 3-4 components share the state and it changes infrequently, I use prop passing. If many components need it but it rarely changes, Context. If it changes often or the update logic is complex, a dedicated state library.
Quick Reference -- Cheat Sheet
REACT INTERVIEW QUESTIONS SURVIVAL GUIDE
============================================================
THE 3 QUESTION TYPES:
1. Conceptual -> One-liner, under 20 seconds
2. Trace/Explain -> Walk through execution step by step
3. Optimize -> Measure first, then fix, then verify
ANSWER FRAMEWORK (STAR-T):
Situation -> What was the context?
Task -> What did you need to solve?
Action -> What did you choose and why?
Result -> What was the outcome?
Trade-off -> What would you change next time?
RED FLAGS TO AVOID:
x "React is a framework"
x Vague answers: "it makes things fast"
x useEffect for everything
x Optimizing without measuring
x No trade-offs mentioned
x Cannot explain your own project decisions
GREEN FLAGS TO SHOW:
+ Precise vocabulary (library, reconciliation, batching)
+ Step-by-step execution tracing
+ "I would measure first with Profiler/DevTools"
+ Unprompted trade-off discussion
+ "It depends on the use case" with specifics
KEY CONCEPTS — ONE SENTENCE EACH:
Virtual DOM -> JS object tree diffed against previous
tree to compute minimal DOM mutations
Reconciliation -> O(n) diffing algorithm using element
type and key to match nodes
Batching -> React groups multiple setState calls
into one re-render (auto in React 18+)
Fiber -> React's internal unit of work enabling
interruptible rendering and prioritization
Hydration -> Attaching event listeners to server-
rendered HTML to make it interactive
Closure trap -> State inside event handlers reflects
the render snapshot, not latest value
Strict Mode -> Development tool that double-invokes
renders/effects to catch impure code
OPTIMIZATION CHECKLIST:
1. Profile with React DevTools and browser Performance tab
2. Check: unnecessary re-renders? expensive renders? too
many DOM nodes? large bundle?
3. Fix:
Re-renders -> React.memo + stable props
Expensive -> useMemo for values, useCallback for
functions
Long lists -> react-window or react-virtuoso
Large bundle -> React.lazy + Suspense + route splitting
Slow images -> lazy loading + proper sizing + WebP
4. Verify: profile again, compare before and after
THE 5-SECOND ANSWER TEST:
If you cannot explain a concept in one sentence,
you do not understand it well enough for an interview.
Practice out loud until every answer is crisp.Congratulations — You Have Completed the React Interview Prep Course
You made it through all 10 chapters and 42 lessons. That is not a small thing.
Here is what you have built across this course:
- Chapter 1-2: You learned how React actually works under the hood — the virtual DOM, JSX compilation, component composition, props, state, and one-way data flow. These are the fundamentals that every single interview starts with.
- Chapter 3: You mastered hooks — not just their API, but when and why each one exists. useState for simple state, useReducer for complex state, useEffect for side effects, useRef for escape hatches, useMemo and useCallback for optimization, useContext for shared data, and custom hooks for reusable logic.
- Chapter 4: You understood the rendering lifecycle — when components re-render, how React batches updates, what React.memo does, and how concurrent features work.
- Chapter 5: You handled events and forms — the patterns every real React application needs.
- Chapter 6: You navigated state management decisions — when to use local state, Context, Redux Toolkit, or modern alternatives like Zustand and Jotai.
- Chapter 7: You built routing knowledge — client-side navigation, dynamic routes, and protected routes.
- Chapter 8: You learned to optimize — profiling, virtualization, code splitting, and asset optimization.
- Chapter 9: You studied advanced patterns — HOCs, render props, compound components, and the thinking behind them.
- Chapter 10: You prepared for the actual interview — testing strategies, debugging approaches, coding challenges, and the exact questions interviewers ask.
The knowledge is here. Now the work is practice. Explain these concepts out loud. Build projects that use them. Review your own code and ask "why did I make this decision?" The candidates who get offers are not the ones who know the most — they are the ones who can explain what they know with clarity and confidence.
Go get that offer.
Previous: Lesson 10.3 — Common Interview Coding Challenges ->
This is Lesson 10.4 of the React Interview Prep Course — 10 chapters, 42 lessons.