React Interview Questions for FDE and Full-Stack Roles (With Answers and Tested Code)

What Do React Interviews for FDE and Full-Stack Roles Test?

React interview questions for FDE and full-stack roles test applied judgment about building user interfaces that stay correct under real conditions: slow responses, partial failures, large data and untrusted content. In practice, interviewers look for four things:

1. Core model. Components, props, state, rendering and keys.
2. Effects and data. Fetching, cleanup, race conditions and derived state.
3. Architecture. State placement, Server vs Client Components and API boundaries.
4. Production habits. Performance, testing, accessibility and security.

Full-stack candidates usually get more server-side and API questions; FDE candidates often get a live "build a small UI against this API" task. Compare the two roles in FDE vs software engineer.

Core React Questions

1. What is the difference between props and state?

Props are inputs a parent passes to a component; the component should not modify them. State is data a component owns and can change over time, which triggers a re-render. A strong answer adds: keep state minimal, and do not store anything you can compute from props or state.

2. Why do list items need keys?

Keys let React match items between renders, so it can update, move or remove the right elements and preserve their state. Use a stable ID from your data. Array indexes cause bugs when items can be reordered, inserted or deleted, because state can attach to the wrong row.

3. What are controlled and uncontrolled components?

A controlled input's value lives in React state and changes through handlers. An uncontrolled input keeps its value in the DOM and you read it when needed, often through a ref. Controlled inputs make validation and conditional logic easy; uncontrolled inputs can be simpler for basic forms. Be ready to say which you would pick and why.

4. What happens when state changes?

React schedules a re-render of the component that owns the state and its children, then updates the DOM with the differences. Mention that updates may be batched, and that you should treat state as immutable: create a new array or object instead of mutating the old one.

Hooks and Effects Questions

5. When should you use useEffect, and when should you not?

Use an Effect to synchronise a component with something outside React, such as a network request, a subscription or a browser API. Do not use one to transform data for rendering or to respond to a click. The React docs put it directly: "If you can calculate something during render, you don't need an Effect."

Here is the common mistake and the fix. We ran both versions locally with React 19.3.1:

jsx

// Anti-pattern: extra state and an extra render

const [visible, setVisible] = useState([]);

useEffect(() => setVisible(items.filter(i => i.includes(q))), [items, q]);

‍

// Better: derive it during render

const visible = items.filter(i => i.includes(q));

On mount the effect version rendered twice and the derived version rendered once, with the same output.

6. Why does useEffect run twice in development?

In development, Strict Mode runs each Effect's setup, then its cleanup, then its setup again, to expose missing cleanup. The extra cycle does not happen in production builds, according to the OpenReplay explainer (a secondary source; confirm in the React docs). We checked this in a test: with React.StrictMode, a probe effect ran setup twice and cleanup once.

The wrong fix is to remove Strict Mode or add a "has run" ref guard. The right fix is a cleanup function that undoes what setup started.

7. How do you fix a race condition when fetching in an Effect?

Responses can arrive out of order, so an old response can overwrite a newer one. The React docs say you can fetch data with Effects but need cleanup "to avoid race conditions." A local flag does it:

jsx

useEffect(() => {

  let ignore = false;

  fetchName(id).then(result => {

    if (!ignore) setName(result);

  });

  return () => { ignore = true; };

}, [id]);

In our test, we changed id from 1 to 2, resolved request 2 first, then request 1. Without cleanup the screen showed user-1 (stale). With the flag it showed user-2. You can also cancel with AbortController, which saves network work too. This test used jsdom with a fake API, not a real browser.

8. When do you use useRef?

Use a ref for a value that must persist across renders without triggering one, such as a DOM node, a timer ID or the previous value of something. Do not use a ref to hold data the screen displays; that belongs in state.

9. Do useMemo and useCallback make code faster?

Not automatically. They add cost and complexity and only help when a calculation is expensive or when a stable reference prevents a costly child re-render. A good answer: measure with the React DevTools Profiler first, fix the real bottleneck (often too much rendered data or state placed too high), then memoise selectively.

State and Architecture Questions

10. How do you decide where state should live?

Start local. Lift state to the nearest common parent only when two components need it. Use context for values many distant components read and that rarely change, such as the current user or theme. Reach for an external store only when the app's complexity calls for it. Also separate server state (data from an API, which needs caching, refetching and error handling) from UI state (open menus, form drafts). Interviewers like hearing that distinction.

11. What are Server Components and Client Components?

The React docs define Client Components as components rendered on the client and Server Components as components rendered on the server, and note the terms refer to component usages, not definitions. Server Components "can reduce the amount of code sent and run by the client" and can access server resources, but "cannot support interaction" and "cannot use most Hooks."

You mark a module with 'use client' at the top of the file to make it, and its imports, client code. Props passed from a Server to a Client Component "must be serializable," so you cannot pass an ordinary function. Mark a component as client when it uses state, hooks, event handlers or browser APIs.

Expect a follow-up: "Where would you put the 'use client' boundary in a dashboard?" A good answer keeps the boundary low, so only the interactive pieces (filters, charts with hover) ship to the browser while data-heavy shells stay on the server. Which frameworks support this, and how, varies, so state the stack you have used.

12. How do you handle loading and error states?

Treat each request as having three outcomes: loading, success and failure, plus an empty result. Show a skeleton or spinner quickly, show a clear error with a retry, and never leave the screen blank. FDE interviewers push on this: "The customer's API takes eight seconds and sometimes returns a 500. What does the user see?" Cover timeouts, retries with limits, stale data you can show while refreshing, and an error boundary so one broken widget does not take down the page.

Performance, Testing and Security Questions

13. How do you keep a large table or list fast?

First measure. Then reduce what is rendered: paginate, filter on the server, or virtualise so only visible rows exist in the DOM. Keep state local to the rows that change, and avoid creating new objects in props for memoised children. Say that you would profile before and after.

14. How do you render untrusted content, such as LLM output, safely?

Treat model output and customer data as untrusted. React escapes text rendered as children by default, which protects against many injection issues. The risk appears when you bypass it, for example with dangerouslySetInnerHTML, or when you render markdown to HTML. Sanitise with a maintained library, restrict allowed tags and links, and never let output trigger actions without confirmation. Keep API keys and secrets on the server, not in client code. An LLM-powered feature is a common FDE project, so be ready to describe this clearly.

For testing, a good answer names user-centred tests (render the component, click like a user, assert what the screen shows) over tests of internal state, plus accessibility basics: semantic HTML, labels, keyboard navigation and focus management.

A Short Prep Plan

A suggested plan, not a guarantee of results.

1. Week 1: Core and hooks. Rebuild a small list-and-filter app. Practise explaining each state decision aloud.
2. Week 2: Data. Build a page that fetches from a public API with loading, error, retry and cancellation. Break it on purpose with slow responses.
3. Week 3: Architecture. Read the React docs on Effects and Server Components. Sketch where 'use client' boundaries would go in an app you know.
4. Week 4: Mock interviews. Do a timed "build a dashboard against this API" exercise, then talk through trade-offs. Link it to your FDE portfolio.

The wider checklist is in our resume, portfolio and interview guide, and the system design round is covered in what system design means in an FDE interview.

How React Fits Into the Wider FDE Skill Set

React alone does not make an FDE. The role also needs data, integration and communication skills. See the technical skills an FDE needs, the FDE tech stack and the programming languages worth learning for an FDE role. If your backend work leans on Python, add Python skills for an FDE interview. Wondering whether your background is enough? See whether a full-stack developer can become a forward deployed engineer.

Common Mistakes in React Interviews

• Reciting definitions without a trade-off. Say when you would and would not use something.
• Using Effects for everything. Derived data and event logic belong elsewhere.
• Ignoring cleanup and failure. Race conditions and error states are favourite follow-ups.
• Memoising by habit. Show that you measure first.
• Treating server data as UI state. Name the difference.
• Forgetting security. Unsanitised HTML from an LLM is an easy catch.
• Not saying your assumptions. State the React version, framework and constraints.

TL;DR: React interviews for forward deployed engineer (FDE) and full-stack roles test whether you can build a reliable interface on top of an unreliable backend, not whether you can recite hook names. Expect questions on state, effects and cleanup, derived data, Server vs Client Components, performance, testing and safe rendering of untrusted output. This guide gives 14 questions with concise answers, two code samples we ran locally, and a short prep plan.