Use useContext to provide theme state without prop drilling

WHAT THIS TESTS: The interviewer wants to know if you can distinguish between component-level communication with props and cross-cutting global state with Context. Specifically, they are checking whether you understand the Provider pattern, how to avoid prop drilling through intermediate components, and where the boundary lies between lifting state and injecting it via Context. They also care if you recognize the performance trade-offs that come with making values globally available.

A GOOD ANSWER COVERS: A good answer hits four things in order. First, create a context object with createContext and export it so any file can import it. Second, build a Provider component that wraps its children and holds the actual theme state with useState, passing both the current theme and a setter or toggle function into the context value. Third, place that Provider high enough in the tree, usually in the root layout or App component, so that every component needing the theme is nested inside it. Fourth, in any deeply nested leaf component, import the context and call useContext to read the theme and the toggle function directly without receiving props from every ancestor.

COMMON WRONG ANSWERS: Red flags include suggesting Context for every piece of shared state rather than only truly global data like themes or authentication. Another mistake is forgetting that updating the context value re-renders every component that consumes it, which means a theme switcher can accidentally trigger a full application re-render if the Provider is placed at the very top and the value object is not memoized. Some candidates also describe prop drilling as the only alternative and miss that composition or passing JSX children can solve many intermediate cases without Context.

LIKELY FOLLOW-UPS: The interviewer may ask how you would prevent unnecessary re-renders when the theme changes, which leads to discussing useMemo for the context value or splitting the context into ThemeValueContext and ThemeDispatchContext. They might also ask how to persist the theme across reloads, which introduces localStorage and a sync effect, or how to respect the user's OS preference via matchMedia. Another common follow-up is how this changes in Next.js with server components, where Context only works in client components and you may need a provider boundary marked with use client.

ONE CONCRETE EXAMPLE: Imagine a dashboard with a Sidebar nested inside a Layout nested inside App. Without Context, App would have to pass theme and setTheme through Layout props even though Layout itself does not use them. With Context, you create a ThemeContext object with createContext and a default of null in a separate file, then in App you return a ThemeContext Provider whose value is an object containing theme and toggleTheme, wrapping the Layout component. Inside Sidebar, you destructure theme and toggleTheme from useContext(ThemeContext) and render a button that toggles between light and dark classes.