Angular Developer Interview Questions 2026

Last updated: November 6, 2026

By Mike Carter, Managing Director, KORE1

The best Angular developer interview questions in 2026 test whether a candidate knows the version of Angular your app actually runs, from signals and OnPush defaults on v22 to upgrade paths for teams still on NgModules and Zone.js. A question can have a perfectly correct 2022 answer and still be the wrong question for your codebase, so write down your version number before you write the loop.

I watched a good interview loop produce the wrong hire this spring at a hospital system in Milwaukee, on the app patients use to book and move appointments. It was on Angular 14 with about 160 components in NgModules and a Karma suite nobody had run in months, and the manager pulled his questions from a 2026 post about modern Angular, signals and zoneless and Signal Forms. It looked like a good list to me too.

There were two finalists. The first one was quick and right on every signals question they asked him. The second one got the linkedSignal question wrong, said so herself, and then spent about ten minutes walking the panel through how she had taken a regional utility’s outage map from v11 to v16, one major version at a time, while the feature team kept shipping the whole way through. They hired the first one, which on paper made sense.

Around week six he circulated a proposal to rebuild the scheduling app from scratch on standalone components and signals. Nobody had budgeted for a rebuild, and to be fair there had barely been budget for the hire. What the app actually needed was the dull version of the work, v14 to v15 to v16 and on up, running ng update at each step and getting the tests passing before moving to the next one. The manager called us in month three. We sent a contractor who had done that exact walk twice before, and by the end of the quarter the app was on v20, which means they now get to do it again, because v20’s long-term support runs out on November 28, 2026.

I work on the business side at KORE1, not the engineering side. The Angular screens we run are done by engineers who have shipped it themselves, and I end up sitting through a lot of their debriefs with hiring managers, which is where most of what follows comes from. We get paid when you hire somebody our Angular developer staffing practice sent you, so weigh what follows with that in mind, although none of it needs us to work.

Some of the neighboring questions are covered elsewhere. Budget, sourcing, and whether you should be hiring for Angular at all are in our guide to hiring Angular developers, and the questions about TypeScript itself, generics and narrowing and so on, live in our TypeScript interview question set. This one sticks to Angular, and to matching the questions to the app the person you hire is actually going to inherit.

Start With Your Own Version Number

An Angular developer interview is a technical conversation that checks whether a candidate can build, debug, and upgrade an app on a specific Angular version. In 2026 the version matters more than it used to, because v21 and v22 changed defaults that older answers quietly assume.

The Angular release and support schedule does some of the thinking for you here. If your app is on anything older than v20, Google isn’t patching it at all, security fixes included, and if it’s on v20, patching ends on the 28th of this month. The six-month rhythm the framework kept for years also stopped at v22, with v23 penciled in for roughly June 2027, so whatever defaults you test for this winter should hold for a while.

Most of the managers I talk to can’t tell me their version off the top of their heads, which is fine, because it’s sitting in package.json and takes about ten seconds to look up. That one number should decide roughly half of your question list.

Three of those rows change how existing code behaves even if nobody on your team touches it, and that’s exactly the kind of thing a resume won’t tell you.

Questions for Teams Already on v21 or v22

If your app is current, these are the five I would want asked in the room. None of them is a trick question, but every one of them has a lazy answer, and once you know the lazy answer is coming it’s surprisingly easy to hear.

This component has no changeDetection property. What does it do on v22, and what did it do on v21?

On v21 it used the old default strategy and got checked whenever change detection reached it, and on v22 it’s OnPush. The Angular team also renamed the old default along the way, so the strategy that used to be called Default is now called Eager. InfoQ’s write-up of the v22 release described change detection as the change “with the widest blast radius,” and the ng update schematic adds ChangeDetectionStrategy.Eager to every component that hadn’t set a strategy, so nothing flips silently during the upgrade itself.

The strong candidates usually answer with a question of their own, which is whether the migration actually ran in your repo or someone hand-edited their way up to v22. Then they’ll tell you what tends to go wrong when a component really does move to OnPush, and nine times out of ten it’s a service that mutates an array in place and a view that stops updating because the reference never changed. Someone who has only read the headline about the new default won’t get that far.

When is writing an effect() a mistake?

Most of the time, if the effect is copying one signal into another. The Angular team’s own guidance on effects is pretty blunt about this. Effects are meant for syncing signal state out to things Angular doesn’t control, like a canvas, a charting library, or localStorage, and using them to push state around can cause circular updates and extra change detection cycles. The docs go as far as saying that if you catch yourself copying data from one signal to another with an effect, you should move the source of truth higher up and use computed() or linkedSignal() instead.

I like this question because it catches enthusiasm more than ignorance. People who have just discovered signals tend to reach for effect() everywhere, in pretty much the same way people who had just discovered RxJS used to call subscribe everywhere, and it’s the same habit wearing a new API.

Load this list with httpResource. Where does RxJS still belong in your code?

Getting the list on screen is the easy part now. The interview is in what comes next. Think of a typeahead that cancels stale requests with switchMap, a WebSocket feed, or retry with backoff against a flaky internal API. Those are streams over time, RxJS still handles them better than anything else that ships in the box, and that’s presumably why rxResource() exists as a bridge in the first place. Be wary of either extreme here. If a candidate tells you RxJS is basically dead, or that signals are a fad, they’ve picked a team instead of a tool, and neither one is the person you want reviewing pull requests.

We turned off Zone.js and a value set inside a setTimeout stopped showing up. Why?

Because nothing told Angular to look. Zone.js used to patch the browser’s async APIs so that pretty much any callback could kick off change detection, and without it the update has to come through a signal, markForCheck(), an event binding, or the async pipe. Zoneless has been the default since v21, and the zoneless migration guide also lists the less obvious casualties, including NgZone.onStable and onMicrotaskEmpty, which never emit in a zoneless app, and NgZone.isStable, which always returns true.

That last detail is where seniority tends to show up. A mid-level developer will fix the setTimeout and move on, while a senior one will ask which of your third-party libraries were quietly waiting on onStable, because that’s where the production bug report is going to come from. In my experience it’s a datepicker, an old grid component, or some homegrown analytics wrapper that somebody wrote in 2019 before they left the company.

Signal Forms went stable in June. Would you move our reactive forms this quarter?

There isn’t a wrong technical answer to this one, but there is a wrong planning answer, and it’s “yes, all of them.”

Signal Forms came out of experimental status in v22. According to the Ninja Squad release notes for 22.0, older custom form controls built on ControlValueAccessor work with Signal Forms, validation errors from those controls now flow into signal form fields, and the newer FormValueControl interface works with reactive and template-driven forms going the other way. That compatibility is really the whole point. A good candidate uses it to suggest building new forms on the new API, leaving old forms alone until someone has a reason to open them, and picking two or three of the gnarliest forms to migrate first because those are the ones generating the bugs. A great candidate asks how many forms you have before answering at all.

Questions for Teams Still on NgModules and Zone.js

This is the part most 2026 interview lists skip. A lot of the Angular intake calls I hear describe an app that’s two or three majors behind, sometimes more, still on NgModules and Zone.js and a test runner from another era. Those teams don’t need a signals evangelist on day one. They need somebody who can get them current without stopping the roadmap, and the questions ought to reflect that.

We’re on v16. Get us to v22. What’s the order of operations?

One major version at a time. Angular’s update path is built around moving one major per step, with ng update doing the mechanical work and the tests passing before the next hop, so v16 to v17, then v18, and so on up the line. When a candidate tells me they would jump straight to 22, they have either never done an upgrade like this or they got lucky the one time they did.

After that, listen for the details that eat real time. Version 22 requires TypeScript 6 and Node 22 and drops support for Node 20, which means the build agents and everyone’s local toolchain have to move as well, and in a lot of companies that’s a ticket for a different team entirely. According to InfoQ, the v22 schematic adds the Eager strategy to components that don’t specify one and sets strictTemplates to false where it wasn’t already on, which keeps the upgrade itself safe and leaves the cleanup for later. The control flow migration, ng generate @angular/core:control-flow, can run any time after v17 and doesn’t need to ride along with a version bump. People who have done this a few times know which steps to batch together and which ones to keep isolated, so that a bad merge is easy to back out.

The contractor we sent to Milwaukee said something on her intake screen that our engineer wrote down word for word, which was that she would rather every step be boring enough to revert than be clever on an upgrade. That was the hire.

Our tests run on Karma. What happens to them?

Short answer, nothing has to happen today. Vitest became the default test runner for new projects in v21, and Karma and Jasmine are still supported for existing ones. Version 22 added a migrate-karma-to-vitest migration for the setup, and it improved the refactor-jasmine-vitest migration that rewrites the tests themselves, including a flag that converts fakeAsync tests to Vitest fake timers.

What I’d want to hear is the approach. The Ninja Squad team described running both setups side by side on large projects, with ng test handling the remaining Karma tests and a separate Vitest task running the migrated ones, and moving files across one at a time. That’s the right instinct, because a test suite you can’t run halfway through a migration is worse than an old one you still can.

Which of our NgModules would you leave alone?

Everybody has a plan for what to change, but far fewer people can tell you what they wouldn’t touch, and on a large app that’s usually the more valuable answer. The candidate should want to know which features are actively changing, which ones are stable and rarely edited, and where the bugs cluster. A shared module that exports forty components and hasn’t changed since 2023 is a perfectly fine thing to leave exactly where it is, since converting it to standalone components buys you almost nothing and risks a regression in forty places at once. The feature area your team edits every sprint is where standalone components and signals pay off first.

An upgrade and a rewrite are different projects with different budgets, and a candidate who knows the difference can save you most of a quarter.

The Same Question, Answered in Two Eras

This is the device our screeners lean on most with Angular. You ask a plain question and then notice which era the answer comes from. Neither column below is wrong, and the only thing that matters is which one matches your repo.

A candidate answering from the left column isn’t behind if your app lives in the left column, and they might be exactly the right person. I’d hire for the column you’re in plus the one you’re moving toward, and pass on people who only know a column you’re never going to use.

Scoring the Answers When You Don’t Write Angular Yourself

Plenty of Angular panels include somebody who doesn’t write Angular, whether that’s a product director, an HR partner, or occasionally me. You can still score most of this if you know what to listen for, and some of it is actually easier to hear when you aren’t busy evaluating the code on the screen.

• They name a version number without being asked, which is a good sign nearly every time.
• “It depends which version you’re on.” That’s probably the most useful sentence you’ll hear all day, as long as they go on to explain what it depends on.
• They ask you something back about your tests, your toolchain, or how many forms you have.
• Absolute statements, like never use effects, RxJS is obsolete, or just rewrite it. Somebody who talks in absolutes about a framework that changed its defaults twice in about seven months hasn’t been paying attention.
• There’s no upgrade story at all, and your team is two majors behind. That’s the job, and they haven’t done it.

Our engineers run that conversation before anyone reaches your calendar, which is part of why our Angular searches average 17 days from intake to hire and why 92% of KORE1 placements are still in the seat a year later. You can absolutely run it yourself, though. Pick four to six questions from the two lists above, the ones that match your version, and leave real room for the candidate to interrogate your codebase. CSS, accessibility, and performance questions for the rest of the loop are in our frontend developer interview questions.

It’s also worth not over-filtering. There are a lot fewer Angular engineers out there than React ones, and a loop that turns away every strong v15 engineer for not knowing what shipped in June makes a small pool even smaller. For a team that’s still on v15, it turns away exactly the people you needed. Pay is its own conversation, and our Angular developer salary guide covers it in depth. The place to start is a real number for your metro from the KORE1 salary benchmark tool, pulled before the offer stage rather than after a candidate turns you down.

The engagement model tends to follow from the version question as well. A defined upgrade, say v16 to v22 with an end date, fits contract staffing naturally, while someone who’s going to own the front-end architecture and the next three upgrades is a direct hire. The hospital in Milwaukee ended up with both, in that order.

Questions I Get Before an Angular Loop

Is it fair to ask about features that only went stable in June?

Fair to ask, unfair to require, unless your app is already on v22.

Signal Forms and the resource APIs went stable with v22 on June 3, 2026, and plenty of excellent engineers work at companies that won’t touch v22 until sometime next year. Ask what they know, and give real credit for how they reason about something they haven’t used yet.

We’re moving to signals. Do we still need RxJS questions?

Yes, because signals and resources handle state well, while RxJS still runs the event streams most enterprise Angular apps depend on.

Typeahead search, WebSockets, polling, and retries don’t go away when you adopt signals, and the code that bridges the two, toSignal() or rxResource(), is where a lot of the subtle bugs live. One RxJS question is plenty, but zero leaves a gap.

Do we need questions about SSR and hydration?

Only if you render on the server, and then you really do.

In v22, incremental hydration became the default hydration strategy for server-side rendering. If your app uses SSR, ask the candidate what hydrates first on your heaviest page and what happens when a user clicks before it does. If you’re a client-side app sitting behind a login, skip it and spend the time on upgrades instead.

How many Angular questions fit in one interview?

Four to six, chosen for your version, with at least ten minutes left over for the candidate to question you.

Past that point you’re grading recall instead of judgment. The strongest loops I’ve watched get debriefed spent forty minutes on three questions and went deep on every one.

Can a strong Angular 15 developer handle a v22 codebase?

Usually within a few weeks, if they’ve upgraded an app before and they’re curious about what changed.

Dependency injection, routing, RxJS, and component design all carry over, and the new defaults take days to learn, not months. The one thing that doesn’t carry over is indifference to release notes, and you’ll usually hear that within the first ten minutes of the version question.

Write the Version at the Top of the Interview Sheet

It sounds too simple to matter, but it isn’t. Put your Angular version, your test runner, and whether you render on the server at the top of the interview guide, and pick your questions from there. The hospital system in Milwaukee does that now, and their most recent Angular hire took three weeks and is running the v22 upgrade.

If you’d rather hand the screen to people who run it every week, talk to our Angular recruiting team and tell us your version number first, since it’s the first thing we’ll ask.