What is prop drilling and when is it a problem?

WHAT THIS TESTS: This question checks if you understand the maintenance cost of component hierarchies and can distinguish between local component contracts and global data dependencies. The interviewer wants to see that you view prop drilling as a symptom of tree shape rather than a moral failure, and that you know when lifting state stops being practical.

A GOOD ANSWER COVERS: First, define prop drilling precisely as the pattern where a parent passes data down through multiple intermediate layers that do not themselves read or modify that data, solely so a deep child can receive it. Second, name the concrete problems it causes: middle components accumulate props they do not care about, which increases their API surface and makes refactors risky because removing or renaming a prop requires touching every layer. Third, explain the threshold for centralized state management, which is not a magic number of layers but a signal pattern: when two or more distant branches of the tree need the same source of truth, or when a child must send an update back up through many emitters, the intermediate layers become purely mechanical plumbing. Fourth, mention that Vue provides provide and inject as a middle ground for localized deep sharing before jumping to a global store like Pinia.

COMMON WRONG ANSWERS: A red flag is treating all prop passing as bad; props are the default and best tool for direct parent-child contracts. Another red flag is prescribing Pinia for every shared piece of state regardless of tree depth or update frequency. Interviewers also worry when candidates blame the framework instead of the architecture, or when they suggest using template refs or event buses to bypass props without explaining the coupling trade-offs.

LIKELY FOLLOW-UPS: The interviewer may ask how provide and inject differs from a global store, or when you would still prefer props over context even in deep trees. They might also ask how you would refactor a drilled prop if the tree is ten layers deep, or how server-side rendering affects singleton stores in Vue.

ONE CONCRETE EXAMPLE: Imagine a user object that lives in App.vue but is only consumed by a deeply nested Avatar component. If UserProfile, Sidebar, and SidebarMenu all pass user down only to satisfy Avatar, any change to the user shape requires editing four files. If SidebarMenu also needs user for a greeting, the line blurs; but if Dashboard and Settings branches both need user independently, a reactive singleton store imported by each leaf becomes cleaner than lifting props through every fork.