Angular Interview Questions for 3 Years Experience (2 to 4 Years)

“On an edit page, the Save button in the header was bound to a formValid flag in the parent. The form itself lived in a child component, and that child emitted its valid status to the parent from ngOnInit. The button sits above the child in the template, so Angular had already checked it with the old value when the child changed it. In development mode Angular checks twice and caught the difference, and the error showed false becoming true. My first instinct was a setTimeout, but a reviewer pointed out that just hides it. The real fix was to let the parent own the FormGroup and pass it down, so the button reads form.invalid directly and there's one source of truth. The error went away and the code got simpler too.”

“Angular sends uncaught errors to its ErrorHandler, which by default just logs to the console. I wrote our own class that implements ErrorHandler and provided it instead. It still logs to the console, but it also sends the error to our logging endpoint with the current route, the app version and the user id, so we can tell who hit it and on which build. HTTP errors that a component already handles don't reach it, which is fine, those are expected. Two lessons from doing it. Production stack traces are minified, so we upload source maps privately to the logging tool instead of serving them publicly. And one error in a loop sent thousands of reports, so now it drops repeats of the same message within a short window.”

“Our service mapped every response with new Date on the due date. A string like 2024-03-10 with no time is read by JavaScript as midnight UTC, and the date pipe then formats that moment in the browser's time zone. For anyone behind UTC, midnight UTC is still the evening of the ninth, which is why only some users saw it. Saving had the reverse bug: we built a Date at local midnight and sent it with toISOString, which converts to UTC and can land on the previous day for users ahead of UTC. The fix was agreeing that a due date is a date, not a moment in time. We keep it as the plain string end to end, and when we need a Date for a date picker we build it from the year, month and day parts, which gives local midnight.”

“Most days it's the browser devtools plus the Angular DevTools extension. In the component tree I can click a component and see its current inputs and properties, which answers most "why is this showing that" questions quickly. When a page feels slow, I use the profiler tab to see how many change detection runs happen and which components take the time. For logic bugs I set breakpoints in the Sources panel. Source maps mean I'm stepping through my TypeScript, not the built code. The network tab tells me whether the bug is in the request, the response or my code. And in development mode I sometimes select an element and call ng.getComponent on it in the console to look at the live component. I still use console.log, but only for quick checks.”

“The router sees the same route with a different parameter, so it reuses the existing component instead of creating a new one. That means ngOnInit doesn't run again. Our code read the id once from route.snapshot.paramMap in ngOnInit, so the URL changed but nothing reloaded. I changed it to listen to route.paramMap and switchMap into the API call, so every new id fetches its product and a slow earlier request gets cancelled instead of overwriting the newer one. Another clean option is turning on component input binding in the router, so the id arrives as an input and updates when the URL changes. While I was in there I also reset the scroll position and the selected tab, because those would have stayed from product 1 as well.”

“I made the URL the single place the filters live. When a user changes a filter, I navigate to the same route with the new query params and merge them with the ones already there. The list doesn't listen to the form directly. It listens to queryParamMap, parses the values with defaults, and fetches from there. That way refresh, back and a link pasted in chat all show the same list. Two details bit me. Typing in the search box was adding a history entry per keystroke, so I used replaceUrl for text search and debounced it. And when someone changed a filter on page five, they got an empty page, so any filter change now resets page to one.”

“HttpClient observables are cold. Nothing happens until someone subscribes, and every subscriber gets its own request. Our template used the async pipe on the same order stream in the header, in the summary and in a child input, so three subscriptions meant three calls. The quickest fix was to subscribe once at the top with @if and an alias called order, and use that everywhere below. Where a stream really had to be shared across components, I added shareReplay with bufferSize one and refCount true, so late subscribers get the last value without a new request. Converting it once with toSignal works too. I also check the network tab on every page I build now, because this kind of duplication doesn't show up any other way.”

“In a single-page app, logging out doesn't reload anything. Every service provided in root keeps living, so a BehaviorSubject holding the last loaded orders, or a small cache in an interceptor, still has the first user's data when the second one lands on the page. It shows until the new request comes back. I'd treat this as a privacy bug and fix it today, not as a flicker. The quick, reliable fix is to do a full page load on logout, which throws away all in-memory state. The cleaner fix, which we did next, was one logout function that tells every store to reset, and keying caches by user id so stale data can never match. Then I added a test that logs in as one user, logs out, logs in as another and checks nothing leaks.”

“We had an address form where changing the country clears the city and loads a new city list. When I loaded a saved address with patchValue, the country change fired valueChanges, and the listener cleared the city I had just set. So the form opened with an empty city. I changed the load to patchValue with emitEvent false, then loaded the city list for that country myself. I use patchValue for loading because the API object often has extra or missing fields, while setValue throws if a control is missing, which I sometimes use on purpose when I want the shape checked. One thing I didn't need was markAsPristine. Setting values from code doesn't make a form dirty, only user input does.”

“In a reactive form, disabled controls are left out of form.value. We had a customer code field that was disabled once the record existed, and the update call stopped sending it, which the API rejected. getRawValue returns everything, disabled controls included, so that's what I used for the save. But I also asked whether the field should go to the server at all. If the user can't change it, maybe it belongs in the URL or the record id, not the form body. The other thing I cleaned up was how it was disabled. Someone had put the disabled attribute on the input next to formControlName, and Angular warns about that in the console. The right way is control.disable() or creating the control disabled from the start.”

“I keep a FormGroup with a FormArray called items, and a small method that builds one line group with its validators. Add pushes a new group, remove calls removeAt with the index. In the template I use formArrayName and loop over the controls with formGroupName set to the index. The Add and Remove buttons need type button, or they submit the form, which I learned the hard way. The trap is editing. When I first loaded a saved invoice with three lines into a form that had one row, patchValue filled the first row and quietly ignored the other two. It doesn't create controls. So to load, I clear the array, push one group per saved line, and then patch the rest of the form.”

“Two things were going on. First, view queries aren't filled in until the view is created, so reading them in ngOnInit gives undefined. They're ready in ngAfterViewInit. Second, our input lived inside an @if, so even in ngAfterViewInit it was undefined while the panel was closed. When the user opened the panel, the code set the flag and tried to focus straight away, but the input only exists after Angular renders that change. The fix I used was a setter on @ViewChild, which runs whenever the element appears, and I focus it there. With newer Angular I'd use the viewChild signal query, which updates when the element shows up. static true doesn't help here, because it only works for elements that aren't inside a conditional block.”

“First I'd look for a way to make the change additive. If my page needs sortable columns, I add an optional sortable input that defaults to false, so every existing page behaves exactly as today. I'd avoid anything like checking which page it's on inside the shared component, because that turns it into a pile of special cases. Then I search every place the component is used and run the tests for those areas, and I click through a few of the busiest pages myself. I'd also add a test in the shared component for the old behaviour, so my change can't quietly alter it. Before merging, I'd post a short note in the team channel saying what changed and that the default is unchanged, and tag whoever owns it.”

“I don't want the real service or the network in a component test, so I provide a fake for the service with useValue, returning an observable of a couple of test orders. Then I create the component with TestBed and call fixture.detectChanges, which runs ngOnInit and renders the template. After that I check the DOM, for example that there are two rows and the first shows the right total, because that's what the user sees. I also add a test for the empty case and the error case, since those are where bugs hide. One thing that caught me once: if the component lists the service in its own providers array, the TestBed provider is ignored, and I have to use overrideComponent instead.”

“I set up TestBed with provideHttpClient and then provideHttpClientTesting, in that order, and inject both the service and the HttpTestingController. In the test I call the service method and subscribe, then use expectOne with the URL. That fails if the request wasn't made, or was made twice. I check the method and, for a post, the body. Then I flush fake data and assert what the subscriber got. For errors I flush with a status like 500 and check that the service maps it to the message or fallback we expect. In afterEach I call verify, which fails the test if any request was left unanswered. That's caught real bugs for me, like a service that quietly fired a second request.”

“I wrap the test in fakeAsync, so timers don't run on their own and only move forward when I call tick. I provide a fake API that records the terms it was called with. Then I type into the input and dispatch an input event, type again, and tick 299 milliseconds. At that point I expect no calls. One more tick and I expect exactly one call, with the last term. That proves both the debounce and that the first keystroke got dropped. Two things to know. If a timer is still pending when the test ends, fakeAsync fails it, so I use flush or make sure everything settles. And fakeAsync depends on zone.js, so in a project without zone.js in the tests I'd use the test runner's fake timers instead.”

“The first thing I'd open is the built index.html and look at the base tag. By default it's a single slash, so the browser asks for main.js at the site root, and under /portal/ that's a 404, which gives you a blank page. The fix is building with base href set to /portal/, either with the flag on ng build or in the build configuration so nobody forgets it. The router also uses the base href, so links become /portal/orders on their own. Then I'd check images and icons. We had a few written as /assets/logo.png, and a leading slash goes to the domain root and ignores the base href, so I changed them to relative paths.”

“The budget warning was the good part, it caught it before users complained. I built with stats turned on and opened the output in a bundle analyzer, which shows each package by size inside each chunk. Two things stood out. I'd imported a date helper from a big utility library as a default import, which pulled in the whole library instead of one function. And a chart component I'd added to a shared barrel file meant the dashboard's chart library was now in the initial bundle, even though only one lazy page used it. I switched to importing the single function, stopped exporting the chart from the shared barrel, and wrapped the chart in @defer. The main bundle went back under budget, and I added the analyzer check to my own routine for new libraries.”

“We keep an environment file per setup with things like the API base URL and feature flags, and the build configuration swaps them in with fileReplacements. So ng build with the production configuration bakes in the production file. The rule I stick to is that nothing secret goes there. Whatever's in an environment file ends up in the JavaScript anyone can open in the browser. Keys that are meant to be public, like a maps key locked to our domain, are fine. Anything else stays on the server, and the frontend calls our backend instead. On one project, ops wanted to build once and deploy the same files to staging and production, so we switched to loading a config.json at app startup and reading the URL from there.”

“Early on I had a table where each row called methods from the template, like isOverdue(order) for a CSS class and getTotal(order) in a cell. A senior dev left a comment asking how often I thought those ran. I guessed once per row. The real answer is on every change detection pass, so every click or keystroke anywhere on the page ran them again for every row. It wasn't slow yet, but getTotal looped over line items, so it would be with bigger orders. We moved that work out of the template: the total and the overdue flag were worked out once when the data arrived. In newer code I use computed signals or a pure pipe for this. Now when I write a function call in a template, I stop and ask how often it'll run.”

“I owned a bulk import screen where support staff upload a spreadsheet of orders. Before coding, I asked what should happen with bad rows, and we agreed to show a preview with errors per row and only import the valid ones. I agreed the response shape with the backend developer early, so I could build against a mocked service while the API was being written. I split it into an upload component, a preview table and a results summary, with the state in one service. I made sure the loading, empty and partly-failed states all had designs. I wrote component tests for the preview and service tests for the upload. It shipped behind a feature flag to two users first, and they found that files with a header row in a different order broke it. Next time I'd ask for real sample files on day one.”

“I estimated a date range filter for a reports page at two days. It took almost two weeks. The picker itself was quick. What I missed was everything around it. The dates had to survive in the URL, the backend expected a different time zone handling than I assumed, the empty state for a range with no data had no design, and the picker had keyboard problems that QA flagged. I also didn't say anything until day four, which made it worse. Now I break a task into the component, the state and the URL, the API contract, the states nobody designed, and tests, and I estimate each part. If the first unknown takes longer than expected, I tell my lead that day, not days later.”