1. What are signals used for?
A signal holds a value and lets Angular track where that value is read. Writable signals can be updated, while computed signals derive values from other signals. For example, a computed total can depend on a quantity signal and a unit-price signal.
Follow-up to practise: identify the original state and the derived value in a cart. Explain why you would avoid keeping two manually synchronised copies of the same calculation. [1]
2. Why use dependency injection?
Dependency injection supplies a class with the services it needs instead of requiring the class to construct them itself. This helps separate responsibilities and lets tests provide a substitute implementation.
Practice example: a component needs product data. Describe a product service dependency and how a test could replace its network-backed implementation. Then consider whether the service should be shared widely or scoped more narrowly. [2]
3. What happens when you subscribe to an HttpClient request?
HttpClient methods return Observables. Subscribing sends the request, and subscribing again can send another request. When diagnosing duplicate API calls, inspect where subscriptions are created rather than assuming a single Observable means a single shared response.
Another useful detail: a type parameter such as get<Product>() describes the expected response to TypeScript; it does not validate the server’s data at runtime. Discuss how you would handle a response that does not match the expected shape. [3]
4. How would you investigate duplicate requests?
Practice scenario: a customer profile screen sends the same GET request twice when opened. Begin by confirming the request URLs, timing and initiators in browser tools. Check whether two components need the same data, whether a lifecycle path runs again, or whether the application deliberately retries.
Explain the change only after identifying the cause. If two consumers genuinely need the same result, discuss where ownership should live and what freshness behaviour they need. If a component accidentally starts work twice, fix that flow. Describe how you would reproduce the problem in a test and verify the network behaviour.
5. How would you present an Angular feature design?
Use a concrete example such as an employee search screen. Explain the user flow, the component’s responsibilities, the service boundary, and the loading, empty and failure states. Show how you would keep business rules understandable without putting every responsibility into one component.
Prepare a follow-up about change: what if the same search is needed on another screen, the API response changes, or the user navigates away mid-request? You do not need a single universal architecture. You need to make your assumptions and reasoning clear.
Turn each concept into a small exercise
Build a small page with a filter, a result list and an editable detail view. Describe which values are source state and which are derived. Add an error case and explain what the user should see. Test one behaviour at a time so you can connect the outcome to your implementation.
Before an interview, practise describing one bug you investigated and one design decision you changed after feedback. If you have mainly worked with older Angular applications, be explicit about that experience and distinguish it from features you have explored in a practice project.
Practise explaining your decisions aloud
Use InterviewFM to listen to structured interview conversations, then pause and answer the follow-up yourself. Choose topics that match your target role, and generate a personalised interview when you want to focus on your stack or a job description. Pair the listening session with a working Angular example.
Frequently asked questions
Do I need to prepare Angular version-specific features?
Use the job description as your starting point. Explain the versions you have worked with and verify feature availability before presenting a solution for a different version.
How should I answer an Angular architecture question?
Start with the user flow and constraints. Explain responsibilities, data ownership and failure handling, then compare a reasonable alternative and describe how you would test the design.
Technical references
Examples and practice scenarios are original exercises.
Listen. Learn. Practise your answer.
Explore interview conversations in InterviewFM and build a preparation routine around your role.