React Interview Questions and Answers for Freshers
A fresher can often build a counter, fetch an API, and copy a useEffect pattern. The interview becomes harder when someone asks why the counter increments incorrectly, why an Effect runs twice in development, or why an input loses its value after a list is reordered.
That is the real purpose of React interview questions for freshers: to test whether you understand how components, state, rendering, events, and Effects work together. Syntax matters, but interviewers also want to see whether you can reason through a small bug and explain your decision without hiding behind framework vocabulary.
This guide uses React 19.2, the version covered by the current official documentation as of August 2026. It focuses on the fundamentals a fresher should know, introduces newer React 19 concepts at an appropriate depth, and includes practical exercises you can run rather than merely memorise. React’s version page identifies 19.2 as the current documented release.
Table of Contents
What Freshers Are Actually Being Tested On
Core React Interview Questions for Freshers
Hooks and State Questions That Expose Weak Fundamentals
Coding Exercises Worth Practising
Modern React Topics to Know in 2026
Legacy React Without Getting Stuck in the Past
Performance Accessibility and Testing
How to Turn a Correct Answer into a Strong Answer
Frequently asked questions (FAQ)
A Focused Preparation Plan
What Freshers Are Actually Being Tested On
Most entry-level React interviews evaluate four connected abilities.
First, can you describe a user interface as components with clear data ownership? Second, do you understand what causes React to render and when state is preserved or reset? Third, can you work with browser behavior such as forms, events, network requests, and focus? Finally, can you debug an incorrect result instead of immediately adding another library?
A fresher isn’t expected to design a multinational streaming platform. You may, however, be asked to build a searchable list, repair an Effect, explain a stale state value, or decide where form state should live.
Your preparation environment should also be current. Create React App was deprecated for new projects in February 2025. For a small learning project, a build tool such as Vite is a practical option; for a production application, the right framework depends on its routing, data, rendering, and deployment requirements. The official Create React App deprecation announcement explains that distinction.
Don’t spend an evening changing tools if the interviewer supplies a repository. Work inside their environment and concentrate on the requested behavior.
Core React Interview Questions for Freshers
What problem does React solve?
React provides a component model for building user interfaces from data. You describe what the interface should display for the current props and state, and React coordinates rendering and updates to the browser DOM.
Without a library, developers may imperatively locate elements and modify them after each interaction. React moves most of that coordination into declarative components:
import { useState } from "react";
export default function SubscribeButton() {
const [subscribed, setSubscribed] = useState(false);
return (
<button onClick={() => setSubscribed(true)} disabled={subscribed}>
{subscribed ? "Subscribed" : "Subscribe"}
</button>
);
}The component doesn’t manually change the button text or disabled attribute. It returns the appropriate interface for the current subscribed value.
A weak answer says React is fast because of the Virtual DOM. A better answer explains the component model first. Performance depends on application design, browser work, network activity, and how updates are scheduled—not on a single slogan.
What is JSX, and does the browser understand it?
JSX is a JavaScript syntax extension that lets developers write markup-like component descriptions inside JavaScript. Browsers don’t execute JSX directly. A build tool transforms it into calls used by the React JSX runtime.
An older interview answer says JSX always becomes React.createElement(). That describes the classic JSX transform. Modern React projects normally use the newer transform, which React 19 requires. This newer approach also allows JSX without importing the React identifier into every file.
export default function Greeting({ name }) {
const safeName = name.trim() || "Guest";
return <h1>Welcome, {safeName}</h1>;
}The expression inside {} is JavaScript, but JSX itself is neither a string nor ordinary HTML. The official guides explain both how JSX represents markup and why the modern JSX transform matters when upgrading to React 19.
How are props and state different?
Props are inputs supplied by a parent. State is information retained by a particular component instance. Both can cause new rendering when their values change, but the receiving component must treat its props as read-only.
Consider a product quantity control:
import { useState } from "react";
function Quantity({ minimum = 1 }) {
const [quantity, setQuantity] = useState(minimum);
return (
<button onClick={() => setQuantity(value => value + 1)}>
Quantity: {quantity}
</button>
);
}minimum is configuration from the parent. quantity changes because of interaction inside this component.
Copying a prop into state without a clear reason often creates two competing sources of truth. If the parent later changes minimum, the existing state won’t automatically reset. Sometimes that independence is intentional; when it isn’t, the design produces synchronization bugs.
What happens after calling a state setter?
A state setter requests another render. It does not mutate the state variable already captured by the current event handler. React processes queued updates, calls the affected components, and then commits the necessary changes to the DOM.
This explains a common coding-round surprise:
import { useState } from "react";
export default function Score() {
const [score, setScore] = useState(0);
function addThree() {
setScore(score + 1);
setScore(score + 1);
setScore(score + 1);
}
return <button onClick={addThree}>Score: {score}</button>;
}All three expressions read the same score snapshot. To apply three sequential updates, use updater functions:
function addThree() {
setScore(value => value + 1);
setScore(value => value + 1);
setScore(value => value + 1);
}React batches these updates and processes the updater functions in order. The useful interview phrase is not “state is asynchronous,” which is too vague. Say that state behaves as a snapshot for a render and setters queue future work. The official explanation of state as a snapshot develops this mental model.
Why do list items need keys?
Keys identify children among their siblings. React uses them to match items between renders and preserve the correct component or DOM state when records move, appear, or disappear.
Use stable identifiers from the data:
function StudentList({ students }) {
return (
<ul>
{students.map(student => (
<li key={student.id}>{student.name}</li>
))}
</ul>
);
}An array index can be acceptable for a genuinely static list. It becomes risky when users can reorder, filter, insert, or delete records because the index describes a position rather than the record’s identity.
Random values are not a safe alternative. A new random key on every render tells React that every child is new, which can reset input values and component state.
Hooks and State Questions That Expose Weak Fundamentals
Why can’t Hooks run conditionally?
React relies on Hooks being called in the same order on every render. A condition can change that order, leaving React unable to associate a stored state value with the correct Hook call.
This is invalid:
function Profile({ loggedIn }) {
if (loggedIn) {
const [name, setName] = useState("");
}
return <p>Profile</p>;
}Call the Hook at the top level and branch when producing the result:
function Profile({ loggedIn }) {
const [name, setName] = useState("");
if (!loggedIn) {
return <p>Please sign in.</p>;
}
return <input value={name} onChange={e => setName(e.target.value)} />;
}Hooks may be called at the top level of a function component or another custom Hook—not inside loops, ordinary nested functions, event handlers, or conditions. The use API is a deliberate exception: despite its name, it is not a conventional Hook and may be used conditionally.
The official Rules of Hooks explain the supported call locations.
When should a fresher choose useReducer over useState?
Use useState when an update is straightforward and the state values are easy to manage independently. Consider useReducer when several related fields change through named transitions or when update rules are spread across too many handlers.
import { useReducer } from "react";
function reducer(state, action) {
switch (action.type) {
case "increment":
return { ...state, quantity: state.quantity + 1 };
case "reset":
return { quantity: 1 };
default:
throw new Error(`Unknown action: ${action.type}`);
}
}
export default function CartQuantity() {
const [state, dispatch] = useReducer(reducer, { quantity: 1 });
return (
<>
<button onClick={() => dispatch({ type: "increment" })}>
Quantity: {state.quantity}
</button>
<button onClick={() => dispatch({ type: "reset" })}>Reset</button>
</>
);
}A reducer centralizes transition logic, but it doesn’t automatically make state global. That is a separate architectural decision. This practical comparison of React Context and Redux can help you distinguish shared-value delivery from application-wide state coordination.
What is useEffect actually for?
useEffect synchronizes a component with something outside React: a browser event, timer, network connection, analytics system, media API, or third-party widget. It is not a general place for every calculation performed after rendering.
import { useEffect, useState } from "react";
export default function NetworkStatus() {
const [online, setOnline] = useState(navigator.onLine);
useEffect(() => {
function updateStatus() {
setOnline(navigator.onLine);
}
window.addEventListener("online", updateStatus);
window.addEventListener("offline", updateStatus);
return () => {
window.removeEventListener("online", updateStatus);
window.removeEventListener("offline", updateStatus);
};
}, []);
return <p>{online ? "Online" : "Offline"}</p>;
}The setup subscribes to an external system. Cleanup removes the exact subscriptions that setup created.
An empty dependency array does not mean “React guarantees this code runs once forever.” Strict Mode intentionally performs an extra development-only setup and cleanup cycle to expose unsafe Effects. Components can also unmount and remount later.
Don’t suppress the dependency linter simply to stop an Effect from running. Identify why the dependency changes, move event-specific work into an event handler, or remove an unnecessary Effect. The deeper guide to useEffect cleanup and the diagnosis of React Effect infinite loops cover these two frequent interview bugs.
When should you use Context?
Context lets a component provide a value to descendants without passing that value manually through every intermediate layer. Theme, locale, authenticated-user information, and feature configuration are common examples.
Context is not automatically the best home for every piece of state. When a frequently changing provider value is consumed by a large subtree, many consumers may update. Sometimes component composition, lifting state to a nearby parent, or splitting one broad context into focused providers produces a clearer result.
A strong interview answer identifies what owns the value, who needs it, and how often it changes. Saying “Context prevents prop drilling” is correct but incomplete.
What belongs in useRef instead of state?
A ref holds a mutable value across renders without scheduling a new render when its current property changes. It is suitable for DOM access, timer identifiers, previous values, and integration objects that do not directly determine visible output.
import { useRef } from "react";
export default function SearchBox() {
const inputRef = useRef(null);
return (
<>
<input ref={inputRef} placeholder="Search articles" />
<button onClick={() => inputRef.current?.focus()}>
Focus search
</button>
</>
);
}If the value must appear on screen, state is normally the right choice because changing a ref won’t update the interface. Refs are also an escape hatch, not permission to modify DOM nodes that React is actively managing.
Coding Exercises Worth Practising
Build a debounced search without hiding the timing logic
A useful interview exercise combines controlled input, Effects, cleanup, and asynchronous thinking.
import { useEffect, useState } from "react";
function useDebouncedValue(value, delay) {
const [debounced, setDebounced] = useState(value);
useEffect(() => {
const timer = setTimeout(() => setDebounced(value), delay);
return () => clearTimeout(timer);
}, [value, delay]);
return debounced;
}
export default function Search() {
const [query, setQuery] = useState("");
const debouncedQuery = useDebouncedValue(query, 400);
return (
<>
<label>
Search
<input value={query} onChange={e => setQuery(e.target.value)} />
</label>
<p>Request term: {debouncedQuery || "None"}</p>
</>
);
}The cleanup matters because each new keystroke should cancel the previous timer. The delay value is part of the dependency list because changing it changes the synchronization behavior.
After this works, add a request triggered by debouncedQuery. Handle empty input, pending state, an unsuccessful response, aborted stale requests, and a retry. The related guide to implementing a JavaScript debounce function explains the underlying JavaScript independently of React.
Repair a list that loses input values
Create three editable rows with stable database-like IDs. Add buttons to reverse the array, remove the first record, and insert a new one in the middle. First use array indexes as keys and observe which input value moves incorrectly. Then replace the index with each record’s ID.
This exercise teaches more than the sentence “keys must be unique.” It shows that keys are unique among siblings, should remain stable across renders, and participate in state identity.
Build an API screen with all meaningful states
A useful API exercise should display more than successful JSON. Represent the initial, loading, empty, success, and failure states. Cancel an obsolete request when the query or selected record changes.
Don’t assume every failed request is a React problem. A request rejected because of the browser’s cross-origin rules has a different cause from an Effect loop or an invalid response body. If you encounter that distinction during practice, use the diagnostic steps in this guide to fixing CORS errors in React fetch requests.
Completion means you can change the selected record rapidly without older responses replacing newer data, explain your cleanup, and show a useful error without crashing the page.
Persist a reducer-driven task list
Use a reducer for added, toggled, and deleted actions. Store confirmed task data in localStorage, but keep temporary input text as nearby component state. Load the initial state through the reducer’s initializer rather than parsing storage on every render.
Then test an edge case: malformed stored JSON. A production-aware solution catches the parsing failure and restores a safe initial value instead of preventing the application from rendering.
The distinction demonstrates good state boundaries. A reducer is useful for task transitions; it doesn’t need to own every keystroke on the page.
Modern React Topics to Know in 2026
How much React 19 should a fresher know?
Understand the purpose of the major additions without pretending you have production experience you don’t possess. React 19 introduced Actions and APIs such as useActionState, useOptimistic, and use. React 19.2 added <Activity>, useEffectEvent, and React-specific Performance Tracks.
For a fresher, the priority remains state, rendering, events, Effects, component composition, and browser fundamentals. Newer APIs sit on top of those ideas; they don’t replace them.
A simple form Action illustrates the direction:
import { useActionState } from "react";
async function saveName(previousState, formData) {
const name = String(formData.get("name")).trim();
if (!name) {
return { error: "Name is required" };
}
await Promise.resolve();
return { message: `Saved ${name}` };
}
export default function NameForm() {
const [state, submitAction, pending] = useActionState(saveName, {});
return (
<form action={submitAction}>
<input name="name" />
<button disabled={pending}>Save</button>
<p>{state.error || state.message}</p>
</form>
);
}An Action can coordinate an asynchronous transition and pending state, but validation and authorization still belong wherever data is trusted and persisted. The React 19 release explanation provides the authoritative overview.
Are React Server Components the same as server-side rendering?
No. React Server Components execute in a separate build-time or request-time environment and send their rendered output rather than their component JavaScript to the browser. Server-side rendering generates initial HTML for a React tree that may later be hydrated on the client.
The two approaches can work together. Their boundaries affect data access, bundle size, interactivity, and serialization.
Freshers don’t need to implement a Server Component bundler. In fact, the low-level framework and bundler APIs do not follow ordinary semantic-version guarantees across React 19 minor releases. Use a supporting framework and learn its conventions. The official Server Components documentation explains this important stability boundary.
Does React Compiler remove the need to understand memoization?
No. React Compiler can automatically memoize components and Hooks, reducing the need for routine manual useMemo, useCallback, and React.memo. React Compiler 1.0 is stable, but it does not make performance measurement or the Rules of React optional.
Manual memoization remains available when code needs explicit control. More importantly, neither compiler-generated nor manual memoization fixes slow network responses, large DOM trees, expensive non-React code, or poor state ownership.
A good fresher answer is measured: understand what the compiler optimizes, keep rendering pure, and confirm the real bottleneck before changing code.
Legacy React Without Getting Stuck in the Past
Should freshers learn class components?
Learn to read class components and understand their lifecycle terminology, but write function components unless the exercise or codebase requires classes. Existing applications still contain classes, and interviews may ask how componentDidMount, componentDidUpdate, and componentWillUnmount relate to Effect synchronization.
Classes remain supported. Calling them obsolete or broken is inaccurate.
Error Boundaries are the main current reason a fresher should recognise class syntax. React still documents class methods for defining a boundary that catches rendering errors below it:
import { Component } from "react";
export default class ErrorBoundary extends Component {
state = { failed: false };
static getDerivedStateFromError() {
return { failed: true };
}
componentDidCatch(error, info) {
console.error(error, info.componentStack);
}
render() {
if (this.state.failed) {
return <p>This section could not be displayed.</p>;
}
return this.props.children;
}
}An Error Boundary does not catch every error in an application. Errors thrown by event handlers, server rendering, the boundary itself, or arbitrary asynchronous callbacks need handling in the appropriate layer. React’s Component reference documents these limits.
Do Higher-Order Components and render props still matter?
They matter when reading established libraries and older applications. A Higher-Order Component accepts a component and returns an enhanced component. A render prop passes a function that determines what a component renders.
Hooks often provide a clearer way to share stateful logic in function components, but blindly converting a stable pattern has a cost. Wrappers may encode subscriptions, authorization rules, analytics, or error behavior that a quick rewrite overlooks.
For a fresher, recognition is enough: explain the pattern, identify its trade-offs, and avoid claiming that one modern technique makes every older abstraction invalid.
Performance Accessibility and Testing
How should a fresher answer a React performance question?
Begin with measurement. Identify whether the delay comes from rendering, Effects, JavaScript calculations, network requests, images, layout work, or an oversized DOM. Only then select an optimization.
React.memo, useMemo, and useCallback can help when referential stability or expensive repeated work is the measured problem. They also add comparison work and cognitive overhead. Adding all three to a tiny component is not evidence of performance skill.
React DevTools can show which components rendered, while the <Profiler> API records render timing programmatically:
import { Profiler } from "react";
function recordRender(id, phase, actualDuration) {
console.log({ id, phase, actualDuration });
}
export default function App() {
return (
<Profiler id="Results" onRender={recordRender}>
<SearchResults />
</Profiler>
);
}For large lists, rendering fewer rows through pagination or virtualization may matter more than memoizing each row. For a slow search, request timing may matter more than component rendering. The senior habit worth learning early is to separate the visible symptom from its actual cause.
What accessibility basics belong in a React interview?
Use semantic HTML before adding ARIA. Connect labels to controls, support keyboard interaction, preserve visible focus, describe errors clearly, and use real buttons for button behavior.
import { useId } from "react";
export default function PasswordField() {
const hintId = useId();
return (
<div>
<label>
Password
<input type="password" aria-describedby={hintId} />
</label>
<p id={hintId}>Use at least eight characters.</p>
</div>
);
}A clickable <div> doesn’t automatically receive button semantics or keyboard behavior. Adding an onClick handler solves only mouse activation.
Accessibility should also shape tests. A test that finds a control by its accessible role and name is often closer to the user’s experience than one that finds a private CSS class.
What should a React component test verify?
Test behavior visible through the rendered interface. Useful assertions cover content, accessible controls, user interactions, loading indicators, validation, errors, and state transitions. Avoid tying every test to internal state variables or a particular component breakdown.
React provides act to flush pending rendering work before assertions. Testing tools often wrap their helpers with it, but knowing why it exists helps diagnose tests that assert before React has committed an update.
A task-list test should prove that entering text and submitting creates a visible task. A reducer-only test can separately verify transition logic. An end-to-end test may prove the complete saved workflow against a real application environment. Those tests have different scopes; one does not replace the others.
How to Turn a Correct Answer into a Strong Answer
A useful interview response has four parts, but it shouldn’t sound like a memorised formula.
Start with the direct answer. Explain the mechanism that makes it true. Give a small example from a project or exercise you have genuinely completed. Finish with the condition that would change your choice.
For “When should you use Context?”, a weak answer is: “To avoid prop drilling.” A stronger answer is:
“Context passes a shared value to descendants without forwarding it through every intermediate component. I’d consider it for theme or authenticated-user information. I wouldn’t move every form field into one context because frequently changing provider values can update many consumers. For a local checkout step, I’d first keep state near that workflow.”
Notice what the answer does not contain: invented performance percentages, fake production stories, or a claim that one library solves every application.
Another common mistake is answering the buzzword beside the question instead of the question itself. If asked why an input loses its value after sorting a list, explaining the entire Virtual DOM is less useful than tracing the item’s unstable key.
The interviewer may interrupt once the required evidence is clear. That is normal. Lead with the answer rather than making them wait through background information.
Frequently asked questions (FAQ)
Which React interview topics should freshers prioritise when preparation time is limited?
Prioritise JavaScript fundamentals, components, props, state snapshots, event handling, list keys, controlled forms, Hooks, Effect cleanup, Context, refs, and basic testing. These topics appear repeatedly because they reveal whether you understand React’s mental model.
Study React 19 features after these foundations. Knowing the purpose of Actions or <Activity> is useful, but it won’t compensate for being unable to explain why three calls to setCount(count + 1) produce an unexpected result.
Which React version should a fresher prepare for in 2026?
Prepare the current React 19.2 concepts while remaining comfortable with React 18 patterns. Production teams upgrade at different speeds, and an interview repository may use the version already established by the company.
Avoid forcing React 19 APIs into an exercise that uses React 18. Instead, explain the version boundary when it matters. For example, you can describe useActionState as a React 19 API while solving a React 18 form with ordinary state and event handlers.
How much JavaScript is required before preparing for a React interview?
You should understand functions, closures, arrays, objects, destructuring, modules, promises, asynchronous execution, event propagation, and reference equality. These concepts directly affect state updates, Effect dependencies, immutable changes, and component behavior.
You don’t need to master every obscure language feature first. A practical readiness test is whether you can transform arrays without mutation, explain what a closure captures, handle a rejected Promise, and distinguish a new object reference from a mutated existing object.
Do freshers need data structures and algorithms for React roles?
The requirement depends on the employer and interview format. Front-end product roles may emphasise JavaScript, browser behavior, React components, accessibility, and practical debugging, while larger companies may include separate algorithmic rounds.
Prepare basic arrays, objects, sets, maps, searching, sorting, recursion, and complexity analysis. Don’t replace React practice with advanced algorithm study unless the job description or recruiter confirms that algorithms carry substantial weight in the selection process.
Is TypeScript necessary for a fresher React interview?
TypeScript is valuable when the position or supplied repository uses it, but weak TypeScript should not prevent you from demonstrating correct React reasoning. Start with typed props, state, form events, API responses, and reducer actions.
During a timed exercise, prefer a complete and understandable solution over unnecessary generic types. If JavaScript is permitted, you can use it and explain how you would add types. For a TypeScript-specific role, however, avoiding types entirely would leave an important part of the job untested.
Should a fresher learn Redux before attending React interviews?
Learn the purpose of external state management, but don’t treat Redux as a prerequisite for every React role. You should first understand local state, lifting state, Context, reducers, and server-state boundaries.
Redux Toolkit becomes relevant when an application needs predictable coordination across distant features, structured updates, middleware, or strong debugging tools. In an interview, explain why shared state requires a store before choosing one. Moving a two-field form into Redux usually adds machinery without solving a real ownership problem.
Should a coding-round project use Vite or Next.js?
Use the environment requested by the interviewer. For an isolated client-side exercise, Vite offers a focused setup with little framework-specific behavior. Next.js is appropriate when the task actually involves routing, server rendering, Server Components, metadata, or framework-based data access.
Don’t migrate a supplied project during a timed exercise merely because you prefer another tool. Framework changes create unrelated risk and make the reviewer evaluate setup work instead of the requested React behavior.
How can a fresher answer experience-based questions without an internship?
Use specific examples from projects you genuinely built. Explain the original requirement, the decision you made, the defect or limitation you found, how you verified the cause, and what you changed.
A small example is enough when it contains real reasoning. You might describe how unstable list keys moved checkbox state after reordering, or how aborting an obsolete request prevented older results from replacing a newer search. Don’t convert a tutorial you copied into fictional production experience.
What should a fresher do after getting stuck during a live React coding round?
State what you know, reduce the problem, and test one assumption at a time. Read the visible error, inspect the current props and state, and verify whether the failure happens during rendering, interaction, an Effect, or a network request.
For example, if a filtered list displays the wrong editable values, inspect the data and keys before adding memoization. Interviewers can still evaluate a structured debugging process even when the final solution is incomplete. Silent random edits provide much less evidence.
How should an unfamiliar React API be handled during an interview?
Be honest about the limit, explain the concept you do understand, and describe how you would verify the remaining details. Don’t invent a signature or claim production usage.
If asked about useEffectEvent, you could say that it separates event-like Effect logic from reactive synchronization, while acknowledging that you would confirm its call restrictions before implementation. This demonstrates technical judgement without pretending that every documented API is already part of your working experience.
What makes a fresher React take-home assignment feel complete?
A complete submission satisfies the requested behavior and makes its assumptions visible. It should handle meaningful loading, empty, success, validation, and failure states where applicable, while using understandable components, accessible controls, and focused tests.
Run the production build, verify the main flow outside the development server, and include concise setup and test instructions. Avoid spending most of the available time on decorative animation when error handling, keyboard operation, or a required interaction remains unfinished.
A Focused Preparation Plan
Begin with JavaScript. Revisit closures, reference equality, array transformations, modules, promises, event propagation, and async error handling. React cannot compensate for uncertainty about the language underneath it. The explanation of JavaScript closures through practical examples is particularly useful before studying stale state and Effect dependencies.
Next, build one small React application without a large state library. Include controlled forms, list operations with stable IDs, a reducer, a shared context, a ref, API states, Effect cleanup, and accessible controls. Add tests after the basic interaction works.
Then deliberately break it. Remove a dependency, replace IDs with index keys, mutate an array in place, create an unstable context value, and omit a request cleanup. Diagnose each result using the browser, React DevTools, and focused console output.
In the final pass, review current React 19 concepts, class-component recognition, Error Boundaries, Suspense, code splitting, and the difference between Server Components and server-side rendering. If the position mentions TypeScript, practise typing props, DOM events, reducer actions, and API results rather than learning advanced generics unrelated to the role.
Finish the project as if it were a take-home assignment. Add a short README describing setup, assumptions, known limitations, and test commands. Run a production build and deploy it only after checking that the built application works. This walkthrough for deploying a React application on Vercel can help with that final delivery step.
You are ready for a fresher React interview when you can build these interactions without following a step-by-step video, explain why the code behaves as it does, recover from the common failures, and distinguish a documented fact from something you still need to verify.
