React Interview Questions for Freshers: Live Machine Coding & Output Challenges

In a frontend machine coding round, you are evaluated on engineering craftsmanship under time constraints. Interviewers do not just look at whether your feature works on the surface; they inspect how cleanly your code is structured and whether it follows production-ready best practices.

Evaluation Criteria 1: Component Decomposition and Separation of Concerns. Avoid writing monolithic 400-line components that mix data fetching, state logic, and raw JSX. Break your solution into focused presentation components, custom business logic hooks, and reusable UI elements.

Evaluation Criteria 2: State Normalization and Immutability. Keep your state minimal and derived. Avoid storing redundant data in state that can easily be calculated on the fly during rendering (for example, storing a filtered array in state alongside the original array instead of computing filteredResults = items.filter(...) inline).

Evaluation Criteria 3: Edge Case and Defensive UI Handling. Senior interviewers look for how gracefully your component handles empty states, loading skeletons, network timeouts, rapid user clicking, and API errors. A component that crashes when an API returns an empty array or null field fails the machine coding screen immediately.

Evaluation Criteria 4: Clean CSS and Responsive Layout. Write clean, scoped CSS without layout shifts or broken mobile alignments. Ensure basic keyboard accessibility (such as pressing Enter or Escape in modals and search inputs).

• Separate data fetching and state logic into dedicated custom hooks
• Derive state values dynamically instead of synchronizing duplicate state variables
• Implement explicit Loading, Empty, and Error UI states for all async operations
• Ensure interactive components support keyboard navigation and focus management

Technical interviewers frequently share short code snippets to test your mental model of React execution order, asynchronous state batching, and JavaScript lexical closures.

Output Challenge 1: The Stale Closure in useEffect / setInterval. Consider a component with const [count, setCount] = useState(0) that sets up an interval inside useEffect(() => { const timer = setInterval(() => { setCount(count + 1); }, 1000); return () => clearInterval(timer); }, []). What happens? The displayed count will increase from 0 to 1 and then stay at 1 permanently. Why? Because the effect has an empty dependency array [], its closure captures the initial value of count (which is 0) during mount. Every second, it executes setCount(0 + 1), setting count to 1 indefinitely. To fix this, use the functional state updater setCount(prev => prev + 1), which always receives the latest state value from React's internal fiber queue.

Output Challenge 2: State Batching in React 18. In an event handler, if you execute setCount(count + 1); setCount(count + 1); setCount(count + 1); where count is initially 0, what is the count on the next render? The count will be 1, not 3. In React 18, state updates are batched, and all three calls reference the same snapshot value of count (0). However, if you write setCount(c => c + 1); setCount(c => c + 1); setCount(c => c + 1);, React queues three distinct updater functions in the fiber work queue, resulting in a final count of 3.

Output Challenge 3: Object Reference Equality in useEffect Dependencies. Passing an unmemoized inline object or array (e.g., useEffect(() => { ... }, [{ id: 1 }])) causes an infinite re-render loop if the effect updates state. In JavaScript, two distinct object literals {} !== {} never share reference equality, causing React's shallow comparison to trigger the effect on every single render.

Sample Output Snippet (Snapshot State Capture in Event Handlers): Consider an event handler: `const handleClick = () => { setCount(count + 1); setTimeout(() => { alert(count); }, 3000); };`. If `count` is initially 0, clicking the button schedules the alert. If the user clicks the button 3 times rapidly, what does the alert display after 3 seconds? The alert displays "0" for the first timeout, because the closure captures the snapshot value of `count` at the time `handleClick` executed for that render. Demonstrating that state behaves like a constant snapshot within a single render cycle proves a deep understanding of React's execution model.

• Always use functional state updates setCount(prev => prev + 1) when new state depends on previous state
• Understand that React 18 batches state updates automatically across timeouts and promises
• Avoid passing inline object literals as dependencies in useEffect or useMemo arrays
• Explain the difference between snapshot rendering values and fiber work queue updaters

The Debounced Autocomplete Search Bar is one of the most common machine coding problems at top product startups. It tests asynchronous handling, event throttling, cleanup functions, and race condition mitigation.

Problem Specification: Build a search input that accepts user text, waits for 300ms of typing inactivity before triggering an API request, displays a loading indicator while fetching, renders search results in a dropdown list, and cancels previous in-flight requests if the user types a new character before the previous network response finishes.

Handling Race Conditions with AbortController: When a user types "rec" followed quickly by "react", two HTTP requests are dispatched. If the first request ("rec") takes 800ms due to network latency while the second request ("react") finishes in 200ms, the older request can resolve after the newer request, overwriting the UI with outdated results. This is a classic asynchronous race condition.

Solution Architecture: Inside the useEffect hook that triggers on debouncedQuery changes, create a new AbortController instance: const controller = new AbortController(). Pass controller.signal to your fetch(url, { signal: controller.signal }) call. In the useEffect cleanup return function, invoke controller.abort(). If the user types a new character before the previous fetch completes, the cleanup function runs immediately, cancelling the pending HTTP request at the browser network layer.

For complementary portfolio project ideas that demonstrate full-stack frontend competence, explore /guides/react-project-ideas-for-resume and /guides/best-resume-projects-for-software-freshers.

• Implement a generic useDebounce hook with a configurable delay parameter
• Attach an AbortController signal to cancel in-flight fetch requests in cleanup
• Catch and ignore AbortError exceptions so cancelled requests do not trigger error alerts
• Provide clear empty state messages when a search query yields zero results

Building reusable custom hooks demonstrates an understanding of modular frontend architecture, TypeScript generics, browser APIs, and state lifecycle management.

Implementing useLocalStorage<T>(key: string, initialValue: T): A production-grade storage hook must do more than call localStorage.setItem. It must handle:

1) SSR Safety: Check typeof window !== 'undefined' before accessing localStorage to prevent Next.js / SSR hydration errors.

2) JSON Serialization: Safely parse stored values with a try...catch block to fallback to initialValue if the storage string is corrupted or invalid JSON.

3) Cross-Tab Synchronization: Listen to the global window storage event (window.addEventListener('storage', handler)) so that when localStorage updates in one browser tab, other open tabs update their React state automatically.

Implementing useFetch<T>(url: string, options?: RequestInit): Managing asynchronous requests with simple useState variables often leads to race conditions and impossible UI states (such as loading: true and error: Error at the same time). Instead, implement useFetch with useReducer to guarantee atomic state transitions between IDLE, LOADING, SUCCESS, and ERROR actions.

Practice these concepts in our interactive code sandbox at /learn and track your frontend applications systematically at /tracker.

• Include SSR safety guards typeof window !== "undefined" in browser-dependent hooks
• Use useReducer inside data-fetching hooks to prevent contradictory UI states
• Synchronize localStorage hooks across browser tabs using storage event listeners
• Write custom hooks with full TypeScript generics for strict type safety

In architectural interviews, tech leads evaluate whether you can justify when to use local state, React Context, or external state managers like Zustand and Redux Toolkit.

The State Decision Hierarchy:

Level 1: Local Component State (useState). Use for isolated UI interactions that no other component needs: modal visibility, form input text, active tab index, and dropdown toggles.

Level 2: Complex Local State (useReducer). Use when multiple state fields change together or state transitions follow a strict finite state machine: multi-step checkout forms, complex canvas editors, and media players.

Level 3: Low-Frequency Global Configuration (React Context API). Use for global application settings that change infrequently: user authentication session, dark/light theme toggle, and localization/i18n language selection.

Level 4: High-Frequency Global Cache (Zustand / TanStack Query). Use for server data caching, background polling, optimistic updates, and complex multi-screen relational workflows.

The Context Re-render Performance Trap: The most common mistake freshers make is putting frequently updating data (like form keystrokes or mouse coordinates) into a single React Context. Whenever any value in a Context Provider changes, every single component that calls useContext(MyContext) re-renders, bypassing React.memo. To solve this, split your context into two separate providers: a StateContext for read-only values, and a DispatchContext for updater functions.

Illustrative Scenario (Resolving Dual-State Desynchronization): A classic synchronization bug occurs when duplicating props into local state (e.g., `const [selectedId, setSelectedId] = useState(props.initialId)`). When the parent component passes a new `props.initialId` following a route change, the child component does not re-initialize its local state, leading to stale UI. The clean architectural fix is either deriving the active selection directly from props or applying a dynamic `key={props.initialId}` attribute on the child component to cleanly reset its internal state when the underlying identity changes.

• Keep UI state as local as possible before lifting it up the component tree
• Separate high-frequency server cache from low-frequency UI configuration state
• Split Context Providers into StateContext and DispatchContext to prevent wasteful renders
• Use TanStack Query or SWR for caching, deduplicating, and revalidating server data

CampusToCareer is an independent career-readiness platform helping freshers find curated jobs, prepare for interviews, and build placement-ready profiles. This guide is published as an educational resource for student job seekers.