How would you use a nested navigation graph for a login flow?

WHAT THIS TESTS: Your understanding of the Navigation component graph hierarchy and your ability to reason about encapsulation at the architecture level. The interviewer wants to see if you treat navigation as a first-class modularization boundary rather than a flat list of screens.

A GOOD ANSWER COVERS: Four things in order. First, define a nested navigation graph, either in an XML navigation resource or in the Kotlin DSL, and give it a global route such as login_graph. Second, place the three destinations, Welcome, Email Input, and Password Input, inside that nested graph and explicitly set Welcome as the start destination so the graph has a clear entry point. Third, explain that the top-level graph references the nested graph by its route, which keeps the root graph declarative and small. Fourth, list concrete benefits: encapsulation of login-specific navigation actions such as transitions from email to password, reusability of the entire flow across different entry points or even modules, cleaner deep linking because you can target the nested graph route directly, and reduced merge conflicts since multiple developers can own separate graph files.

COMMON WRONG ANSWERS: Three red flags stand out. One, describing nested graphs as purely visual grouping in the navigation editor without explaining runtime behavior. Two, forgetting to mention the start destination inside the nested graph, which breaks the contract when another graph calls into it. Three, claiming that nested graphs improve performance or reduce memory usage; they are a structural abstraction and do not inherently change the lifecycle or memory footprint of the fragments or composables inside.

LIKELY FOLLOW-UPS: The interviewer may ask how you would deep link directly into the Password screen from a notification, which requires understanding that deep links can target destinations inside a nested graph if the graph is properly exported. They may also ask how to share a ViewModel scoped to the nested graph, which in the Navigation component ties to the nav graph ViewModelStoreOwner. Another follow-up is how to programmatically pop the entire login flow once the user authenticates, which you achieve by popping up to the nested graph route with inclusive true.

ONE CONCRETE EXAMPLE: In a Kotlin DSL setup, you would write navigation with startDestination set to the Welcome route. Inside a nested navigation block with route login_graph and startDestination welcome_route, you define composable destinations for welcome, email, and password. The root graph then references login_graph as a single navigation node. When the user completes login, you call popBackStack(login_graph, inclusive true) to remove all three screens at once, leaving the main graph clean.