What is the purpose of an Angular Resolve guard vs ngOnInit?
Tests routing lifecycle timing and UX state management. Strong answers: Resolve blocks activation until data returns; ngOnInit renders first then fetches, causing flicker.
What's really being asked
This question probes your understanding of the Angular router lifecycle and whether you think about user experience at the route boundary versus inside the component. Interviewers want to see that you know when navigation is blocked, when the component actually instantiates, and how to prevent janky UI transitions.
The full answer
A strong response hits four points in order. First, the Resolve guard is a data provider whose resolve method runs after the ResolveStart event and blocks route activation until the returned observable, promise, or value emits. The router only activates the component once the data is ready, so the component can read it synchronously from ActivatedRoute.data. Second, fetching inside ngOnInit happens after the component and its template are already rendered, which means the user sees an empty or skeleton state while the request is in flight. Third, the UX problem is the flicker and layout shift that occurs when the template transitions from uninitialized to populated, plus the difficulty of gracefully cancelling or redirecting navigation if the fetch fails after the route is already visible. Fourth, modern Resolve implementations can return a RedirectCommand, allowing the router to redirect before the target component ever renders if the data cannot be loaded.
The mistakes people make
Red flags include saying Resolve is just a best practice or cleaner architecture without mentioning that it blocks navigation. Another mistake is claiming that Resolve runs inside or after the component lifecycle. Some candidates also miss the error-handling angle, failing to explain that a rejected resolve can prevent navigation entirely or trigger a redirect, whereas a failed ngOnInit fetch leaves the user stranded on a broken page.
What usually comes next
Expect the interviewer to ask how you would handle very slow resolvers without freezing the UI, whether you would combine Resolve with lazy loading, or how to migrate from class-based Resolve to the modern ResolveFn. They may also ask how to test a resolver in isolation.
A concrete example
Imagine a dashboard that requires a large configuration object before any widget can render. Without Resolve, the dashboard component mounts, shows six loading spinners, and then snaps into place as each widget receives its config. If the config endpoint returns a 403, the user briefly sees the dashboard frame before being kicked out. With Resolve, the router waits for the config, then instantiates the dashboard with data already present. If the config fetch fails, the resolver returns a RedirectCommand to the access-denied page, and the user never sees the dashboard shell at all.
Interview question
Why might a dashboard with a required config object use a Resolve guard instead of fetching in ngOnInit?
- a.Resolve is primarily a best practice for cleaner separation of concerns without changing routing behavior
- b.Resolve allows the dashboard to render immediately while the config loads asynchronously in the background
- c.Resolve runs inside the dashboard's ngOnInit to keep data fetching logic close to the component
- d.Resolve blocks navigation until the config loads, preventing the dashboard shell from rendering if the fetch failsCorrect
Why? this is the answer
Resolve guards block route activation until the observable emits, guaranteeing the component mounts with data present and enabling pre-render redirects. Option B incorrectly describes ngOnInit behavior, which causes visible layout shifts and leaves users on a broken page when the fetch fails.
Just read this? Test yourself on what you have been reading.
Read the original → angular.dev
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on angular — each one lists the topics its interview covers.
See open roles