Half the market still means AngularJS. That is a different job.
AngularJS 1.x and Angular are different frameworks that share a name, and a great many AngularJS applications are still running the business. Confusing the two is the single most common failure in this hiring category.
Two frameworks, one name.
If a job advert says “Angular” and the codebase is AngularJS, every candidate who applies will be wrong for it and nobody will find out until week two.
What the work involves
- Scopes, the digest cycle, and watchers
- Directives and the link function
- Controllers and
$scopeinheritance - No official support, you are on your own
- A shrinking pool who remember how it behaves
- Usually a maintenance or migration brief
What the work involves
- Components, standalone APIs, and signals
- TypeScript throughout, dependency injection
- RxJS, the steepest part of the learning curve
- A predictable release cadence to keep up with
- A healthy hiring pool
- Usually new build or ongoing product work
What we ask an Angular engineer.
Weighted towards RxJS and change detection, because that is where Angular codebases go wrong.
When does change detection run?
And what OnPush changes about it. The most common source of both performance problems and mysterious stale-view bugs.
Show us where you would use a subject.
And where you would not. Subjects used as a general-purpose event bus are the most common RxJS anti-pattern in enterprise Angular.
How do you avoid a subscription leak?
takeUntilDestroyed, the async pipe, or a discipline. An engineer with no answer has shipped leaks.
Do you need NgRx here?
Usually not, and a candidate who says so unprompted has judgement. NgRx applied to a small application is a large amount of ceremony for nothing.
Standalone components or modules?
Tests whether they have kept current. Modules-only answers indicate practice that stopped developing a few versions ago.
How would you migrate an AngularJS application?
Only asked where relevant. The good answer involves running both behind one shell instead of a rewrite with a date on it.
How we move an AngularJS application without stopping it.
This is the brief we are called about most in this category, and the sequence matters more than the destination.
-
Weeks 1–2
Read it and inventory the surface
Routes, directives, services, and the integrations. AngularJS applications accumulate a great deal of behaviour in directives that no component inventory will find.
-
Week 2
Decide the destination honestly
Angular is not automatically the answer. If your team is React-shaped, moving to React is a shorter trip than moving to a framework that shares a name with what you have.
-
Weeks 3–4
Put a shell around it
One application shell hosting both old and new, so screens can move individually and every URL keeps working.
-
Ongoing
Move screens, highest value first
Usually the screens users complain about, which pays for the programme politically as well as commercially.
-
Eventually
Remove the shell
Or do not. Some AngularJS screens are stable, rarely touched and not worth the regression risk of moving, and stopping is a legitimate outcome.
Rates, notice and how we interview, on one page.
The commercial mechanics are the same whichever role you are hiring, so they live in one place, not being restated on every page.
Hiring Angular engineers.
Weighted towards the AngularJS question, because that is what we get asked.
We are still on AngularJS. Is that urgent?
It is a real risk and it is rarely an emergency, which is a useful distinction when you are deciding what to fund this year. AngularJS receives no official support, so security issues in the framework will not be fixed for you, and the pool of engineers who genuinely remember the digest cycle keeps shrinking. Both of those get worse over time instead of suddenly. What would make it urgent is a specific trigger: a security assessment that flags it, a dependency you can no longer build, or losing the one person who understands it. Absent those, plan the migration properly over a year rather than reacting, and in the meantime make sure the application is documented and somebody other than one individual can maintain it.
Should we migrate to Angular or to React?
Ask which one your organisation can hire for, because that is what the decision comes down to. Angular is the technically shorter conceptual trip in some respects, dependency injection and structured architecture will feel familiar, particularly to teams with a .NET or Java background, but it does not reuse a line of your AngularJS code, so the “same framework” intuition is misleading. React has a larger hiring pool in most markets and a gentler learning curve for a small team. We deliver both and would ask about your team and your local market before recommending either. What we would push back on is choosing Angular purely because the current application is called AngularJS.
Is Angular a good choice for a new application?
For a large application with several teams, yes, and its reputation as heavyweight is the reason. The opinionated structure, built-in dependency injection, routing and forms mean that fifteen engineers across three teams write code that looks broadly the same, which matters enormously at that scale and is exactly what unopinionated libraries fail to give you. For a small team building a small product it is a lot of ceremony, RxJS is a genuine learning curve, and React or Vue will get you further faster. The threshold is roughly where more than one team touches the front end.