Explain prop drilling and why it's a problem

WHAT THIS TESTS: Your ability to distinguish between legitimate parent-child data flow and accidental structural coupling. Senior engineers should recognize that prop drilling is primarily a maintenance and readability problem rather than a runtime performance crisis, and should know the built-in React tools to solve it.

A GOOD ANSWER COVERS: Four things in order. First, a crisp definition: prop drilling is the pattern of passing data through many intermediate components that do not need the data themselves solely to reach a deeply nested child. Second, the concrete problems this creates: every intermediary must accept and forward the prop, so renaming or removing the prop requires touching many files; components become harder to reuse because they carry signatures for data they ignore; and the data path becomes harder to trace for teammates. Third, the nuance that drilling is not evil for shallow or tightly related trees, and that Context introduces its own complexity and render-scope rules. Fourth, the standard solutions: lift via component composition when possible, or use React Context when the data is needed by many components at different depths.

COMMON WRONG ANSWERS: Claiming that props themselves are an anti-pattern. Recommending Redux, MobX, or Zustand without first mentioning React Context or composition. Confusing prop drilling with performance issues like memory leaks or excessive re-renders; drilling is primarily a maintenance and coupling concern. Proposing useContext for every single shared value regardless of tree depth.

LIKELY FOLLOW-UPS: When would you still prefer prop drilling over Context? How do you prevent Context consumers from re-rendering too often? Can you refactor a drilled prop using composition instead of Context? How do you type drilled props in TypeScript when intermediaries should not know about them?

ONE CONCRETE EXAMPLE: Imagine a theme string passed from App to Layout to Header to Navigation to UserMenu. Layout, Header, and Navigation do not use theme; they only forward it. If the design team renames theme to colorScheme, four files must change. If Navigation is later reused in a different app shell, it now carries an irrelevant prop. The fix is either to wrap the subtree in a ThemeContext provider so UserMenu reads directly, or to use composition by having App render a themed UserMenu node and pass it as children through the tree, eliminating the need for the intermediate layers to know about theme at all.