Explain the Coordinator pattern and the navigation problem it solves in MVC

WHAT THIS TESTS: The interviewer wants to know if you understand the architectural pressure that traditional MVC puts on view controllers in UIKit. Specifically they are looking for recognition that view controllers naturally accumulate responsibilities that have nothing to do with views or user input and that navigation flow is one of the most damaging to reuse and testing. The question also checks whether you can articulate the coordinator pattern as a concrete solution rather than a vague buzzword.

A GOOD ANSWER COVERS: First name the three problems Khanlou identifies. One the app delegate becomes a dumping ground for root view controller configuration. Two view controllers bloat with unrelated duties like model mutation data fetching layout and navigation. Three navigation flow gets embedded inside view controller methods such as tableView didSelectRowAtIndexPath directly instantiating and pushing a detail view controller. Second define a coordinator as an object that sits above view controllers and owns the flow of the application. It creates view controllers injects dependencies and decides when to present or push them. Third explain the benefit view controllers become isolated units that know nothing about their presentation context making them reusable and testable. Fourth mention that coordinators can be nested or have children allowing complex flows to be broken into manageable pieces.

COMMON WRONG ANSWERS: Saying coordinators are just for deep linking or URL routing misses the core purpose of removing navigation from view controllers. Claiming that view controllers should still push each other but coordinators handle the back button is equally wrong. Another red flag is describing the pattern as overengineering for small apps without acknowledging that the problem is MVC structural tendency to create massive view controllers. Interviewers also frown on answers that conflate coordinators with view models or routers from VIPER without explaining the distinction.

LIKELY FOLLOW-UPS: How do you pass data back from a view controller to a coordinator. How do you handle deeplinking or state restoration with coordinators. What happens to the coordinator lifecycle when a user dismisses a modal flow. How do you avoid retain cycles between coordinators and view controllers. Can you mix coordinators with SwiftUI or UIKit programmatic layout.

ONE CONCRETE EXAMPLE: Imagine a login flow. A LoginCoordinator is initialized with a navigation controller. It creates a LoginViewController sets itself as the delegate or callback target and pushes the login screen. When the user taps sign up the LoginCoordinator creates a SignUpViewController and pushes it. When authentication succeeds the LoginCoordinator tells its parent AppCoordinator that the user is logged in and the AppCoordinator swaps the root flow for a MainTabCoordinator. The LoginViewController never touches the navigation controller directly it only notifies its delegate that a button was tapped.

Source: Khanlou | Coordinators Redux