How would you implement lazy loading for an Angular feature module?

What's really being asked

The interviewer wants to know if you understand how Angular's router enables code splitting at the route level and how the CLI supports this workflow. It is not enough to know the syntax; they care whether you understand the build-time implications, the module graph, and the difference between eager and lazy-loaded chunks. This is a fundamental performance optimization for large Angular applications.

The full answer

A strong response starts with the CLI command, specifically ng generate module FeatureModule --route=feature --module=app, which scaffolds the module and a default component and wires the lazy-loaded route in one step. Next, it explains the routing change: in the parent route configuration, you replace a direct component reference or eager module import with loadChildren. For NgModule-based apps, this means using a dynamic import function returning the module class, such as loadChildren: () => import('./feature/feature.module').then(m => m.FeatureModule). It also covers the critical step of removing any eager import of that feature module from AppModule or other eagerly loaded modules, because if the module remains in the static dependency graph, the bundler cannot tree-shake it into a separate chunk. Finally, a senior candidate mentions that the Angular CLI and Webpack handle the actual chunk creation automatically when it detects the dynamic import, so no manual bundle configuration is needed.

The mistakes people make

A major red flag is suggesting manual Webpack entry points or externals to solve the problem, which shows a misunderstanding of Angular's abstraction over the build tool. Another mistake is describing loadChildren but forgetting to remove the module from AppModule imports, which would nullify the optimization. Some candidates conflate standalone component lazy loading, which uses loadComponent, with the traditional NgModule-based loadChildren pattern, or they suggest using the string-based loadChildren syntax from older Angular versions without mentioning the modern dynamic import approach.

What usually comes next

The interviewer may ask how you would handle preloading strategies to speed up subsequent navigations without hurting initial load. They might also ask how to share dependencies between lazy-loaded chunks to avoid duplicate code, or how to protect lazy routes with guards. Another common pivot is asking about the difference between loadChildren and loadComponent in standalone applications, or how to measure the actual bundle size reduction.

A concrete example

Suppose you have a SettingsModule that is only accessed by administrators. You would run ng generate module settings --route=settings --module=app. The CLI creates a settings folder with SettingsModule and SettingsComponent, and it automatically adds a lazy route to AppRoutingModule. You then verify that AppModule does not import SettingsModule. When the application builds, the CLI emits a separate chunk, such as src_app_settings_settings_module_ts.js, which the browser only fetches when the user navigates to the settings path. This keeps the main bundle smaller and improves the initial load time metric.