Angular Interview Questions for Freshers

“They're related, but they're really two different frameworks. AngularJS is the original version, the 1.x line. It was plain JavaScript, and you organised code with controllers and a scope object, with two-way binding checked by a digest loop. Angular, from version 2 onward, was rewritten from scratch. It uses TypeScript, the app is built from components, it has a proper dependency injection system and a CLI, and it compiles templates ahead of time so the app starts faster. Because it was a rewrite, an AngularJS app can't be upgraded just by bumping the version. Teams either rewrite it or run both together for a while and move screens across one by one. AngularJS isn't supported anymore, so anything new I'd build is in Angular.”

“TypeScript is JavaScript with types added on top. I can say a function takes a number, or describe the shape of a user object with an interface, and if I pass the wrong thing the compiler tells me straight away instead of the app breaking in the browser. That also makes the editor much smarter, so I get autocomplete on my own objects and can rename things safely. The browser never runs TypeScript. The Angular build compiles it down to normal JavaScript, and the types disappear. In my project it saved me when the API renamed a field: I updated the interface and the compiler pointed at every place that used the old name. Angular also leans on TypeScript for decorators like @Component and for checking bindings in templates.”

“A decorator is a TypeScript feature: a function written with an at sign above a class, property or method, which attaches extra information to it. On its own, a component class is just a normal class with some fields and methods. The @Component decorator is what tells Angular it's a component, and it carries the metadata: the selector tag, the template or template file, the styles, and in a standalone component the imports it uses. @Injectable does the same job for services. It tells Angular's injector it can create this class, and with providedIn root there's one shared instance. There are property decorators too, like @Input for data coming in from a parent. Newer Angular also offers functions like input() in place of some decorators, but the idea of describing the class to Angular stays the same.”

“In a single-page application the browser loads one HTML page and the JavaScript for the app once. After that, when I click a link, Angular's router swaps the component on screen and updates the address bar, but the browser doesn't fetch a whole new page. Only the data comes from the server, usually as JSON. That makes navigation feel quick, like an app. The downsides are real, though. The first load can be heavier because there's more JavaScript up front, which is why lazy loading matters. Search engines and link previews may see an almost empty page unless you add server-side rendering. And the server has to return index.html for any route, or refreshing on a deep link breaks. For a mostly static content site, a multi-page site can be simpler.”

“The Angular CLI is the command-line tool I use for almost everything in a project. I start with ng new and a project name, which sets up the folder, the TypeScript config, the build setup and a first component. Then ng serve starts a local dev server, and every time I save a file the page reloads. When I need a new piece, I run ng generate component, or the short form ng g c, with a name, and it creates the TypeScript, template, styles and test file with consistent naming. There are generators for services, pipes and guards too. When I'm ready to deploy, ng build produces optimised JavaScript and CSS in the dist folder, and ng test runs the unit tests. Using the CLI keeps the project laid out like other Angular projects, which helps anyone joining.”

“The browser loads index.html, which is almost empty apart from an app-root tag. main.ts is the entry point. In a standalone project it calls bootstrapApplication with the root component and the app config, and Angular renders that component where the app-root tag sits. The app config file lists app-wide providers, like provideRouter with the routes file, and provideHttpClient if I'm calling APIs. The root component itself has a TypeScript class, a template and styles. Outside src, angular.json holds the workspace settings: how to build and serve, and where global styles and assets live. package.json lists the dependencies and npm scripts, and tsconfig holds the TypeScript settings. Older projects have an AppModule instead of the app config, but the idea is the same: something tells Angular which component to start with and what the whole app needs.”

“That error means Angular doesn't know what ngModel is in this template. ngModel isn't built into every component; it comes from FormsModule. In a standalone component I fix it by adding FormsModule to the component's imports array, and in an older module-based app I'd add it to the NgModule that declares the component. The same kind of error shows up for any directive or child component I forget to import, so it's the first thing I check. It's also worth knowing what the syntax means. Square brackets inside round brackets, which people call banana in a box, is shorthand. It's a property binding that pushes my value into the input, plus an event binding on ngModelChange that writes the new value back to my field. So data flows both ways.”

“I'd use the @for block. It loops over the products array and needs a track expression, so I track by the product id. That tells Angular which row is which when the list changes, so it only updates the rows that changed instead of rebuilding everything. Inside, I show the name and the price with the currency pipe so it's formatted properly. Then @for has an @empty block, which is perfect here: if the array has no items, it shows 'No products yet' instead. In older Angular code you'd see star ngFor on the list item and a separate star ngIf for the empty message, with trackBy as an optional function. The new syntax is built into the template language, so there's nothing to import for the loop itself.”

“The Angular way is to keep the selection as data, not to touch the DOM. I store selectedId in the component, and each tab has a click binding that sets selectedId to that tab's id. Then on the tab I use a class binding, class.active, set to whether this tab's id matches selectedId. Angular adds the active class when that's true and removes it when it's false, so only one tab is ever highlighted, and the CSS for active handles the look. If several classes depend on state, I'd use ngClass with an object, where each key is a class name and each value is a condition, or bind class to the same kind of object. What I avoid is document.querySelector and classList, because then the screen and my data can drift apart.”

“A template reference variable is a name I give an element with a hash sign, like hash box on an input. Anywhere else in the same template I can refer to box, and for a plain element it's the actual DOM element, so box.value is whatever the user typed. For a quick todo input I don't need forms at all. I bind keyup.enter and a button click to an add method, pass box.value, and then clear the input by setting its value to an empty string. The variable only lives in the template, so the class doesn't see it unless I use a view query. On a component tag, the variable points to the component instance instead of an element. For anything with validation or several fields, I'd switch to a real form.”

“Both are elements that don't show up in the final HTML. ng-container is just a grouping box. If I need to wrap some elements, but an extra div would break a table or a flex layout, I use ng-container and Angular renders only the children. In older code it's also how you'd use star ngIf and star ngFor on the same content, since one element can't take two structural directives. ng-template is different: its content isn't rendered at all until something asks for it. I use it for a block that repeats, like a person's name and role that I show in two places. I write it once, give it a reference name, and stamp it out with ngTemplateOutlet, passing the data in through a context object. And the star in star ngIf is really shorthand: Angular wraps that element in an ng-template behind the scenes.”

“I'd keep the count in a signal starting at zero. The template shows it by calling count() inside double curly braces, and each button has a click binding that calls a method. The increase method just adds one with update. The decrease method is where the rule lives: it subtracts one but uses Math.max with zero, so the value can't go negative. I keep that check in the class rather than in the template, because logic in templates is harder to read and test. As a small extra, I bind the disabled property of the minus button to count() being zero, so the user can see they can't go lower. If the interviewer prefers, the same thing works with a plain number field instead of a signal, because the click event makes Angular update the screen anyway.”

“This is content projection. In the card's template I put the frame, the border and padding, and an ng-content tag where the body should go. Whatever the parent writes between the opening and closing app-card tags lands there. If I want a separate title area, I add a second ng-content with select, for example matching an attribute called card-title, and the parent marks its heading with that attribute. Anything without a match goes into the plain ng-content. I use inputs for simple values like a title string, but for markup such as a button or an image, projection is cleaner than adding an input for every option. The projected content still belongs to the parent, so its bindings use the parent's data and click handlers.”

“By default Angular uses emulated view encapsulation. When it renders a component, it adds a generated attribute to that component's elements, and it rewrites the component's CSS so each selector also requires that attribute. So my .title rule really becomes .title plus that component's attribute, and it can't match elements in another component. If I want something to apply to the whole app, like fonts or a reset, I put it in the global styles file. To style the component's own tag, I use the :host selector. The flip side is that my styles don't reach into child components either, which surprises beginners. There's ViewEncapsulation.None, which makes a component's styles global, and ShadowDom, which uses the browser's real shadow DOM, but I'd pick those on purpose, not as a quick fix.”

“@ViewChild is a view query, and the view isn't finished when ngOnInit runs. Angular sets normal view queries once it has created the component's view, and the hook for that is ngAfterViewInit, so I'd move the focus call there and use the ElementRef's nativeElement to call focus. If the input is always in the template, never inside an @if or a loop, I can mark the query static true, and then it's already set in ngOnInit. If it's inside an @if, it may not exist at all until the condition turns true, so I'd focus it after that happens. In newer Angular I'd use the viewChild function, which gives a signal, so reading it later always gives the current element or undefined. What I wouldn't do is wrap it in a setTimeout without knowing why that seems to work.”

“A pipe transforms a value for display in the template, using the vertical bar. The data in my component stays as it is; only what's shown changes. For a date, I'd use the date pipe with a format, like day, short month and year. For a price, the currency pipe with a currency code, and it adds the right symbol and decimal places. For a name, titlecase or uppercase. Pipes take parameters after a colon and can be chained, so I could lowercase a value and then slice it. The json pipe is handy for debugging, to dump an object on screen, and the async pipe subscribes to an observable for me. In a standalone component I have to import the pipes I use, like DatePipe, or CommonModule to get all the common ones.”

“I'd generate it with ng g pipe truncate, which gives me a class with the @Pipe decorator and the name truncate. It implements PipeTransform, so it has a transform method. The first argument is the value from the left of the bar, and extra arguments come after colons, so I take the text and a limit with a default of twenty. First I handle the edge cases: if the text is null or empty I return an empty string, and if it's already short enough I return it unchanged. Otherwise I slice it to the limit, trim any trailing space and add three dots. Any component that wants it imports TruncatePipe and writes the text, a bar, truncate, a colon and thirty. Because it's a pure pipe, it only reruns when the text or the limit changes.”

“A component should mostly be about the screen: showing data and handling what the user does. If I put the HTTP call, the URL and the data mapping inside the component, the next component that needs the same data copies that code, and when the API changes I have to fix it in several places. So I move it into a service, say ProductService, with a method like getProducts. Components ask Angular for that service through dependency injection and just call the method. That also makes testing easier, because in a component test I can give it a fake service that returns fixed data, with no real network. And a service can hold shared state, like the items in a cart, so two unrelated components see the same cart.”

“First, the app config needs provideHttpClient, otherwise injecting HttpClient fails. In the component I keep three signals: the users, a loading flag that starts true, and an error message. I use signals so the template updates reliably when the response arrives. In ngOnInit I call get with the User type, so the result is typed, and subscribe with an object. In next, I set the users and turn loading off. In error, I set a friendly message like 'Could not load users' and also turn loading off, because a spinner that never stops is a common beginner bug. The template uses @if blocks for loading and error, and a loop for the list. In a real app I'd move the call into a UserService, and since HttpClient completes after one response, this subscription ends by itself.”

“CORS isn't an Angular error; it's the browser protecting the user. An origin is the scheme, host and port, so localhost 4200 and localhost 3000 count as different origins. The request may even reach the server, but the browser won't hand the response to my code unless the response includes a header saying my origin is allowed. So the proper fix is on the backend: enable CORS for the front end's origin, for example with a CORS middleware in a Node server. For local development there's also the Angular CLI proxy. I add a proxy config file that forwards anything under /api to localhost 3000, point the serve settings at it, and call relative URLs like /api/users. Then the browser only ever talks to 4200. Adding headers in an Angular interceptor won't fix it.”

“I'd write a routes array. An empty path goes to HomeComponent, users slash colon id goes to UserDetailComponent, and double star goes to NotFoundComponent. The wildcard has to be last, because the router takes the first match. I pass the routes to provideRouter in the app config. In the root template I put router-outlet where pages should appear, and my links use routerLink instead of href, so clicking doesn't reload the whole app. In the detail component I inject ActivatedRoute and read the id from paramMap. The snapshot is fine if the component is created fresh each time, but if the user can go from user 5 to user 6 on the same page, the component is reused, so I'd subscribe to paramMap instead. Newer apps can also turn on component input binding and receive the id as an input.”

“In my final year I built a library booking app with two classmates. Students could search books, reserve one and see their loans, and the librarian had an admin page. I did most of the Angular side, and the backend was a small Node API. I had routes for search, book details, my loans and admin. The search page had a search bar component and a list of book cards, and I reused the card on the loans page with an input that switched its button between reserve and return. All the HTTP calls went through a BookService and an AuthService, so components never built URLs themselves. One thing I'd change is that I put too much logic in the search component early on and had to pull it into the service later. Next time I'd start with the service.”

“During my internship I added a new page with a form, and the whole page came up blank with an error in the console I didn't understand, something about no provider for a service. I spent a while changing random imports, which didn't help, so I stopped and read the message properly. It named the exact service and the component asking for it. I opened the service and saw I'd dropped providedIn root while copying code from another file, so Angular didn't know how to create it. Adding it back fixed the page. What I took from it is to read the full error before touching code, and to check the console and Network tab first. Now when I'm stuck I also write down what I've tried, which makes it easier to ask a senior for help.”

“First I'd get the app running locally and find the form in the browser. Then I'd search the codebase for a label or field name I can see on screen, which usually takes me straight to the component. Before writing anything, I'd look at how the existing fields are done: is it a reactive form, how validators are added, how errors are shown, and how the data reaches the API through a service. I'd copy that pattern rather than doing it my own way. I'd also check whether the backend already accepts a phone field, and ask my mentor about the rules, like country codes and whether it's required, instead of guessing. Then I'd test it by hand, add or update a unit test if the project has them, and keep the change small for review.”