Hire Angular developers

Angular is the opinionated enterprise front-end framework, and hiring for it means checking whether someone has kept pace with a platform that has changed substantially.

What Angular actually is

Angular is a front-end framework developed and maintained by Google, released on a predictable twice-yearly cadence with clearly dated support windows. Unlike React, it is a complete platform rather than a library: routing, forms, HTTP, dependency injection, testing and a build system all ship together and are designed to work as one thing.

That completeness is why it dominates in large organisations. When several teams work on the same product for years, having one official answer to each question is worth more than having the best possible answer to any of them. An Angular codebase written by a team in one company looks recognisably like an Angular codebase written anywhere else, and that consistency is the product.

The complication for hiring is that Angular has changed a great deal. The move to standalone components, the new reactivity model built on signals, and the shift in how change detection works are substantial changes to how the framework is used day to day. A developer whose Angular experience stopped several versions ago knows a framework that is recognisably related to the current one and meaningfully different from it.

The part that separates seniors from mid-levels

Change detection is the concept that separates Angular developers. The framework historically checked the whole component tree for changes after anything happened, using a library that patches browser APIs to know when that might be. Understanding this explains almost every Angular performance problem and most of the confusing ones. Developers who have optimised an Angular application talk about the OnPush strategy, about running work outside the change detection zone, and increasingly about signals, which make dependencies explicit and let the framework update only what actually changed.

RxJS is the second area, and the one that most divides opinion. Angular uses observables throughout: HTTP, routing, forms and events are all streams. Used well, this is powerful for coordinating asynchronous work. Used badly, it produces nested subscriptions, memory leaks from streams nobody unsubscribed from, and code that nobody on the team can follow. Asking how someone manages subscription lifetimes is one of the most reliable interview questions in front-end work.

Dependency injection is the third. Angular has a hierarchical injector, so where a service is provided determines whether it is shared application-wide or scoped to a component subtree. Getting this wrong produces state shared between components that should have been independent, or duplicated services where one was intended. It is also the mechanism that makes Angular applications genuinely testable, and developers who understand it write very different code from those who do not.

Where Angular is used

The label “Angular developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Enterprise applications

Large internal systems with many screens and several teams, where the framework's consistency is the main attraction.

Financial services interfaces

Trading, banking and insurance front ends where forms are complex and correctness matters more than novelty.

Healthcare and government systems

Regulated environments with long lifespans, strong accessibility requirements and slow upgrade cycles.

Admin and operations consoles

Data-dense interfaces with tables, filters and forms, which the framework and its component libraries handle well.

Multi-team product suites

Several applications sharing a component library and conventions across a large organisation.

Migration and modernisation

Moving applications off AngularJS or off very old Angular versions, a substantial share of available work.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Which Angular versions are still supported

Angular releases twice a year with published support windows for each version, so how far behind an application has drifted is a matter of record rather than judgement.

The table is generated from public release data rather than written by hand, so it states what is supported today rather than what was true when any given article was published. Of the 8 most recent release lines, 8 are still maintained and 0 have passed their published end-of-life date. That distinction is the practical one when you read a job specification: a requirement written against a line that is now out of support tells you the specification is older than the codebase it describes, and it is worth asking which of the two the new developer will actually work in.

Source: endoflife.date public release data, read 2026-09-25.

Two questions follow from this table in an interview. The first is which line the candidate has most recently shipped against, because someone whose last production work was on an unsupported line has not had to deal with the changes since. The second is how they have handled an upgrade. Version migrations are where you see whether a developer reads release notes, writes characterisation tests before changing anything, and knows how to stage a rollout, or whether they upgrade in place on a Friday and hope.

The toolchain around it

Nobody hires for Angular alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

TypeScript

Not optional. Angular is written in it and assumes it throughout.

RxJS

Observables across HTTP, routing, forms and events. The main thing to interview about.

Angular Material or PrimeNG

Component libraries, which do most of the interface work in enterprise applications.

NgRx or the signal store

State management where the application genuinely needs it, which is less often than it is used.

Jest or Karma with Testing Library

Testing. Angular's dependency injection makes this easier than most frameworks.

Angular CLI

Build, test, generation and upgrade tooling, including the automated update command.

Cypress or Playwright

End-to-end tests over the critical flows.

Nx

Monorepo tooling, common in the large organisations where Angular is used.

Related skills that frequently appear on the same specification: Node.js, Java, .NET, JavaScript, TypeScript.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

Change detection

Explains nearly every Angular performance problem and separates levels immediately.

• Strong answer: Explains the default strategy, uses OnPush deliberately, and can describe profiling an application that re-rendered too much.
• Warning sign: Has never considered how the framework decides what to update.

Subscription management

Memory leaks from unclosed observables are the most common Angular defect.

• Strong answer: Uses the async pipe or takeUntilDestroyed, and can explain what leaks and why it matters in a long-lived application.
• Warning sign: Subscribes in components and never unsubscribes, or has not thought about it.

Signals and the newer reactivity model

The clearest test of whether their knowledge is current.

• Strong answer: Can explain what signals change about change detection and where they replace observables and where they do not.
• Warning sign: Has not encountered them, which places their experience several versions back.

Dependency injection hierarchy

Where a service is provided has real consequences for shared state.

• Strong answer: Explains root versus component-level providers and can describe a bug caused by the wrong choice.
• Warning sign: Provides everything in root without being able to say why.

Reactive forms at scale

Enterprise Angular is largely forms, and complex ones are genuinely difficult.

• Strong answer: Builds dynamic forms, handles cross-field and asynchronous validation, and keeps validation logic testable.
• Warning sign: Only familiar with simple template-driven forms.

Upgrading across versions

Twice-yearly releases mean this recurs, and deferral compounds.

• Strong answer: Has used the official update tooling across several versions and knows what it does not handle.
• Warning sign: Has only worked on applications pinned to one old version.

When NgRx is not needed

Over-engineering with state management is the most common architectural mistake in Angular.

• Strong answer: Uses services with signals or simple subjects for most cases and reserves a store for genuinely complex shared state.
• Warning sign: Applies a full store pattern to every application by default.

Warning signs in a Angular codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

Subscriptions never closed

• What you see: Manual subscribe calls in components with no teardown.
• What it costs: Memory leaks and duplicated handlers that grow as users navigate, which in a long-lived enterprise application eventually degrades the browser session.
• The fix: Prefer the async pipe. Where manual subscription is necessary, tie it to the component lifecycle explicitly.

Nested subscriptions

• What you see: A subscribe inside another subscribe.
• What it costs: Unmanageable lifecycles, lost errors and race conditions that are very hard to reason about.
• The fix: Compose with switchMap, concatMap or forkJoin so the stream expresses the dependency.

Default change detection everywhere with heavy templates

• What you see: Function calls and getters invoked from templates in large component trees.
• What it costs: The function runs on every check, many times per interaction, producing an application that feels slow for no visible reason.
• The fix: Move computation out of templates into signals or precomputed values, and adopt OnPush.

A store for everything

• What you see: Full state management applied to an application with simple local state.
• What it costs: Large amounts of boilerplate per feature and a steep barrier for anyone joining.
• The fix: Start with services and signals. Introduce a store when shared state genuinely becomes hard to reason about.

Any as a TypeScript escape hatch

• What you see: HTTP responses typed as any throughout.
• What it costs: The framework's main safety advantage discarded, with errors surfacing at runtime in the browser.
• The fix: Type API responses and validate at the boundary. This is the highest-value discipline in an Angular codebase.

Pinned to an old major version

• What you see: An application several versions behind with upgrades repeatedly deferred.
• What it costs: No security support, incompatible libraries, and an upgrade that grows harder each release.
• The fix: Upgrade one major version at a time with the official tooling. Staying current is routine; catching up is a project.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a Angular developer.

Junior

Builds components and forms within an existing structure. Needs review on subscription management and change detection.

Mid-level

Owns a feature module including its forms, routing and tests. Understands OnPush and manages subscription lifetimes correctly.

Senior

Owns application architecture: module and standalone structure, state approach, performance strategy and the upgrade path. Can say when a store is unnecessary.

Staff

Owns the shared component library, cross-application conventions, the version policy across an estate, and migration strategy off legacy Angular.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

New enterprise application

• Usual team: Two to three developers with one senior setting patterns.
• What governs it: The module structure and state approach chosen early determine how the application ages.

AngularJS migration

• Usual team: Two developers, one who knows the legacy application.
• What governs it: A rewrite rather than an upgrade. Running both side by side during transition is normal and should be planned for.

Version catch-up

• Usual team: One senior developer.
• What governs it: Scoped by how many majors behind and by third-party library compatibility, which is the usual blocker.

Shared component library

• Usual team: One senior developer plus a designer.
• What governs it: Scoped by consumer count. Accessibility and API stability matter more than any individual component.

Performance remediation

• Usual team: One senior developer, time-boxed.
• What governs it: Starts with change detection profiling. Usually resolves to template work and a change of strategy.

Migration work you may actually be hiring for

A large share of Angular work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

AngularJS to Angular

• Why teams do it: AngularJS is no longer supported and the hiring pool for it has largely gone.
• What to watch: This is a rewrite, not an upgrade. The usual approach runs both frameworks together while routes move across one at a time, which works but adds real complexity; plan for that period to last longer than estimated.

NgModules to standalone components

• Why teams do it: Less ceremony, clearer dependencies and the direction the framework itself is going.
• What to watch: Both styles coexist, so migrate component by component. Shared modules with large export lists are the fiddly part and are best left until last.

RxJS for local state to signals

• Why teams do it: Simpler mental model for synchronous state and more precise change detection.
• What to watch: Signals do not replace observables for asynchronous streams and event handling. Converting everything is a mistake; convert local component state and leave HTTP and event streams alone.

A version several releases behind to current

• Why teams do it: Security support and library compatibility.
• What to watch: One major at a time using the official update command, with the test suite run between each. Skipping versions is where upgrades fail, because the tooling's migrations assume sequential steps.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a Angular developer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Which Angular version the application is on, and how many majors behind current that is.
• Whether the codebase uses NgModules, standalone components, or both.
• Whether signals are in use, since that indicates how current the codebase and the required experience are.
• What state management is in place, because NgRx experience is a distinct and not universal skill.
• How complex the forms are, since enterprise Angular is largely forms and that is where difficulty concentrates.
• Whether the work includes migrating from AngularJS, which is a different project entirely.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

Angular work is counted by the US Bureau of Labor Statistics under Software Developers. That classification is broader than the technology itself, so treat the figures as the shape of the market a Angular developer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 1,687,890 people in this occupation, with a median annual wage of $135,980.

The spread matters more than the midpoint. The 90th percentile is about 2.6 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a Angular developer can sit at $82,460 and $214,670 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for Angular frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Software Developers, the gap between the highest and lowest of the 28 metro areas covered here is a factor of about 1.7. San Jose sits at the top with a median of $213,110; Pittsburgh sits at the bottom with $124,500. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. San Jose, San Francisco, Seattle, Washington, D.C., Denver, Austin each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

Experience several versions out of date. Ask about standalone components and signals. This is the sharpest available test of currency in Angular.

AngularJS experience presented as Angular. They are different frameworks sharing a name. Ask which one, specifically, and when.

No RxJS depth. Ask them to describe composing dependent requests. Subscription handling is where Angular applications leak.

Over-engineering instinct. Ask when they would not use a store. Angular's culture can encourage ceremony that small applications do not need.

Hiring Angular developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of Angular developer who will be available.

• New York, NY $166,830 median
• Seattle, WA $167,280 median
• San Jose, CA $213,110 median
• Washington, D.C. $154,930 median
• San Francisco, CA $186,640 median
• Dallas-Fort Worth, TX $133,290 median
• Los Angeles, CA $160,920 median
• Boston, MA $166,090 median
• Chicago, IL $134,380 median
• Atlanta, GA $132,960 median
• Austin, TX $134,120 median
• Phoenix, AZ $131,750 median
• Philadelphia, PA $133,040 median
• Minneapolis-St. Paul, MN $130,920 median
• Denver, CO $137,610 median
• Detroit, MI $130,760 median
• Houston, TX $129,440 median
• Charlotte, NC $135,920 median
• San Diego, CA $163,270 median
• Salt Lake City, UT $129,600 median
• Miami, FL $132,650 median
• Portland, OR $156,000 median
• Baltimore, MD $138,900 median
• Tampa, FL $130,450 median
• Orlando, FL $129,620 median
• Raleigh, NC $132,770 median
• Kansas City, MO $124,990 median
• Pittsburgh, PA $124,500 median

Frequently asked questions

Angular or React for an enterprise application?

Angular when several teams will work on the same product for years and consistency matters more than flexibility, because the framework supplies one official answer to most questions. React when you want flexibility and the largest hiring pool. Both are defensible; the decision is more about organisational shape than about technical merit.

Is Angular declining?

Its share of new projects is smaller than React's, and its position in large enterprises is stable. There is a great deal of Angular in production that will be maintained for years, and the hiring pool reflects that. It is a reasonable choice for the kind of application it suits, and a poor choice made for fashion reasons either way.

How do we tell if someone's Angular knowledge is current?

Ask about standalone components and signals. Both are recent and central enough that a developer working in a current codebase will have an immediate answer, and someone whose experience stopped a few versions back will not. It is a cleaner test than asking how many years they have used it.

How painful are Angular upgrades?

Manageable if done on schedule, because the official update tooling handles much of the mechanical work and there are two releases a year. Painful if deferred, because you then cross several majors at once and third-party libraries become the blocker. Applications that upgrade each cycle rarely find it difficult; applications four versions behind need a dedicated project.

Do we need NgRx?

Less often than it is used. Most applications are served well by services with signals, and a full store adds a great deal of boilerplate per feature. The case for a store is genuinely complex shared state with many writers and a real need for time-travel debugging. If you cannot articulate that need, you probably do not have it yet.

Why does our Angular application feel slow?

Usually change detection doing far more work than necessary, often because templates call functions or getters that run on every check. The other common cause is a large component tree using the default strategy where OnPush would be correct. Both are diagnosable with the profiler and both are fixable without restructuring the application.

Can a React developer move to Angular?

Yes, and the component thinking transfers. What does not is RxJS, dependency injection and change detection, which are substantial and unfamiliar. Budget a meaningful ramp rather than assuming front-end experience is interchangeable, and be aware the reverse move is usually faster.

Is AngularJS experience relevant?

Only as context. AngularJS and Angular are different frameworks that share a name and a vendor. Someone whose experience is AngularJS is effectively new to Angular, and a job specification that does not distinguish them will produce a confusing shortlist.