Technologies, and the occupations they are counted under
There is no official wage figure for a framework. There is one for the occupation, and that is what a budget should be built from.
The same list as the hiring pages, organised by the Bureau of Labor Statistics occupation each technology is counted under. This matters more than it sounds: the occupation determines the published wage band you are hiring against, and several technologies that feel similar are counted differently.
Software Developers
US employment 1,687,890, median annual wage $135,980, middle half of the market $105,210 to $171,980. Technologies counted here:
- AI Engineering
- Node.js
- Python
- Java
- .NET
- PHP
- Laravel
- Django
- Go
- Spring Boot
- Rust
- Ruby on Rails
- JavaScript
- GraphQL
- Magento and Adobe Commerce
- Salesforce
- React
- Next.js
- TypeScript
- Angular
- Vue.js
- React Native
- Flutter
- iOS and Swift
- Android and Kotlin
Network and Computer Systems Administrators
US employment 314,340, median annual wage $99,130, middle half of the market $78,010 to $126,640. Technologies counted here:
Data Scientists
US employment 262,440, median annual wage $120,230, middle half of the market $85,660 to $158,880. Technologies counted here:
Software QA Analysts and Testers
US employment 186,740, median annual wage $104,300, middle half of the market $80,310 to $133,180. Technologies counted here:
Web Developers
US employment 70,190, median annual wage $92,650, middle half of the market $64,230 to $126,230. Technologies counted here:
Database Administrators
US employment 69,990, median annual wage $104,620, middle half of the market $79,610 to $135,460. Technologies counted here:
The US technical labour market in numbers
Software development is one of fourteen technical occupations the Bureau of Labor Statistics publishes separately. Together they account for about 4,860,150 people, of whom 1,687,890 are software developers, which is why that one occupation dominates most conversations about technical hiring. The other thirteen matter because they compete for the same people.
| Occupation | Employed | 25th percentile | Median | 75th percentile | 90th percentile |
|---|---|---|---|---|---|
| Software Developers | 1,687,890 | $105,210 | $135,980 | $171,980 | $214,670 |
| Web Developers | 70,190 | $64,230 | $92,650 | $126,230 | $162,290 |
| Web and Digital Interface Designers | 113,330 | $73,290 | $104,000 | $158,820 | $201,550 |
| Software QA Analysts and Testers | 186,740 | $80,310 | $104,300 | $133,180 | $167,010 |
| Data Scientists | 262,440 | $85,660 | $120,230 | $158,880 | $199,130 |
| Information Security Analysts | 190,650 | $97,810 | $129,180 | $163,500 | $199,850 |
| Computer Systems Analysts | 519,530 | $82,860 | $105,850 | $134,110 | $167,710 |
| Computer Programmers | 92,230 | $75,850 | $100,390 | $130,680 | $160,460 |
| Database Architects | 67,140 | $109,370 | $139,500 | $169,290 | $204,000 |
| Database Administrators | 69,990 | $79,610 | $104,620 | $135,460 | $163,320 |
| Computer Network Architects | 179,740 | $104,620 | $134,050 | $168,200 | $202,680 |
| Network and Computer Systems Administrators | 314,340 | $78,010 | $99,130 | $126,640 | $155,050 |
| Computer and Information Systems Managers | 670,570 | $138,060 | $175,140 | $220,730 | $297,510 |
| Computer Occupations, All Other | 435,370 | $79,370 | $116,580 | $157,500 | $188,470 |
Source: BLS Occupational Employment and Wage Statistics, May 2025 national file, read 25 September 2026. Figures cover all US employers.
The spread across these titles runs from $175,140 for computer and information systems managers down to $92,650 for web developers. That gap is the practical reason technical people move sideways between titles rather than upward within one: for many engineers the fastest available pay rise is a change of job title rather than a change of employer. If you are hiring at the lower end of that range, expect to lose some candidates to the upper end of it, and expect that to happen after they have accepted.
It is worth reading the employment column alongside the wage column. Occupations with small headcounts, such as database administrators and architects, are specialisms where a local search will frequently produce nobody, regardless of what you are prepared to pay. Occupations with large headcounts are where a well-run process matters more than a generous band, because the people exist and the competition is for their attention.
What changes by category
The questions worth asking differ by area. These are the ones we find separate candidates most reliably in each, and the mistakes that most often get made when hiring into them.
Front end
Front-end hiring is where the gap between a CV and a capability is widest, because frameworks are good enough that somebody can be productive for years without understanding what sits beneath them. The questions that separate candidates are about state: where it lives, when it changes, and what re-renders when it does. Almost every serious front-end performance problem and almost every hard-to-reproduce bug traces back to one of those three decisions.
The current dividing line across this whole category is the server. Work that renders on a server and work that renders in a browser demand different judgement, and a large number of otherwise strong candidates have only done the second. Ask which side of that boundary their last production work sat on; it is the single most informative question in front-end interviewing today.
Covered here: JavaScript, React, Next.js, TypeScript, Angular, Vue.js.
Back end
Back-end hiring rewards testing the things frameworks hide: data modelling, transactions, failure behaviour and what happens when the process is running on three instances instead of one. A developer who has only operated a single instance writes code that holds state in memory, and that code fails the moment it is scaled.
The other reliable divider is whether somebody has operated what they built. Design judgement about reliability is formed in incidents rather than in documentation, and the question that surfaces it is simply what broke after launch and what changed as a result. Candidates with no answer have shipped and not owned.
Covered here: Node.js, Python, Java, .NET, PHP, Laravel, Django, Go, Spring Boot, Rust, Ruby on Rails, GraphQL.
Mobile
Mobile hiring has a specific trap: building an application and shipping one are different jobs, and the second involves two app stores, two review processes, signing, platform release cycles and device fragmentation that no simulator reveals. Developers who have never submitted to a store are missing knowledge that is tedious to acquire and expensive to lack during a launch window.
The other question worth asking in every mobile interview is which physical devices somebody tests on. A large share of real users are on hardware several generations behind a developer's own phone, and performance problems that are imperceptible on a current flagship are severe there. It is a one-line question that predicts a great deal about the application somebody will produce.
Covered here: React Native, Flutter, iOS and Swift, Android and Kotlin.
Cloud and platform
Platform hiring is badly served by CVs, because service count tells you nothing. What matters is depth in the dozen services a workload actually touches, plus the judgement to refuse the rest. Somebody who has used forty services shallowly is usually a worse hire than somebody who has operated five and been on call for them.
Two questions do most of the work here. What has this person been woken up by, and what did the infrastructure they designed cost to run. The first tests operational judgement, which is the whole job. The second tests whether they understand that on a cloud platform, architecture decisions are financial decisions, and engineers who cannot read a cost report are making them blind.
Covered here: Microsoft Azure, Salesforce, AWS, DevOps, Kubernetes, Terraform.
Data, AI and machine learning
This category contains at least four different jobs that job specifications routinely blend: building pipelines, analysing data, putting models into production, and building products on foundation models. They attract different people and reward different skills, and a brief that implies all four produces a shortlist where nobody is quite right.
The unifying question across all of them is evaluation. How does this person know their work is correct, and what would change their mind. In data engineering that means testing what flows through a pipeline rather than only the code. In analysis it means experimental discipline. In machine learning and AI engineering it means an evaluation set built from real failures. Weak answers here predict confident work that quietly does not hold up.
Covered here: Machine Learning, AI Engineering, SQL, Data Engineering, Data Science, MySQL.
Content management
Content management hiring has the widest quality range of anything on this site, because the same job title covers configuring a site from existing components and building custom applications inside a platform. Both are legitimate; they are not interchangeable, and the distinction belongs in the brief rather than being discovered in month two.
Security deserves particular attention in this category, because these platforms are among the most probed surfaces on the internet and the vulnerabilities are overwhelmingly in plugins, themes and custom code rather than in the platforms themselves. A developer whose security practice was formed a decade ago is a genuine risk here in a way they would not be elsewhere.
Covered here: WordPress, Drupal.
E-commerce
Commerce hiring differs from content hiring in a way that is easy to underrate: correctness matters more and failure costs money directly. Order state, payment handling, inventory and tax are unforgiving, and caching a personalised page incorrectly is a data breach rather than a bug.
The platform decision shapes the hire more than in any other category. Hosted platforms mean working skilfully inside constraints, particularly around checkout. Self-hosted platforms mean owning hosting, security and PCI scope. A developer who arrives from one expecting the other will be frustrated and occasionally dangerous, so it is worth establishing which they have actually worked in.
Covered here: Shopify, WooCommerce, Magento and Adobe Commerce.
Quality engineering
Quality engineering is frequently framed as writing tests, which undersells it and produces poor hires. The valuable skill is judgement about what deserves a test, at which level, and what does not. A suite of three thousand tests that takes an hour and fails intermittently is worse than two hundred fast reliable ones, because the first teaches everyone to ignore failures.
The most informative question is what somebody has deleted. Volume is easy; discrimination is what you are paying for. The second is how they treat a flaky test, because tolerating intermittent failures is what destroys the value of a suite, and an answer that accepts it predicts a suite nobody trusts.
Covered here: QA Automation.
What the levels actually mean
Job titles are not comparable between companies, so it is more useful to describe levels by what somebody can be left to own without supervision. These are the boundaries we use, and every technology page states what each level looks like in that specific technology.
- Junior
- Delivers defined pieces of work inside an existing structure, with the approach decided for them. Reviews catch the things experience teaches. Valuable where there is strong direction and capacity to teach, and a poor investment where there is neither.
- Mid-level
- Owns a feature end to end, including its tests, its failure states and its data access. Can be given a problem rather than a solution. Still benefits from review on decisions that will be expensive to reverse.
- Senior
- Owns the shape of an area. Makes the decisions that are costly to change later and can justify them against the alternatives. Raises the level of the people reviewing alongside them, which is the part most often left out of the definition.
- Staff
- Owns cross-cutting concerns: the contracts between areas, the standards others build against, the migration path off whatever the system has outgrown. Measured by what other teams stop having to decide.
Years of experience correlate with these far less than people expect. Somebody who has spent six years maintaining one application carries less transferable judgement than somebody who has spent three across three very different ones. When a CV and a level disagree, the interview should settle it.
The most reliable seniority signal we know is what somebody has removed. Mid-level developers describe what they added. Senior ones describe a store they deleted, an abstraction they collapsed, a dependency they took out. The ability to make a system smaller is harder to fake than any amount of technical vocabulary.
One caution that applies to the whole page. The Bureau classifies by occupation, not by technology, so there is no official wage figure for any specific framework or language. Anyone quoting one has modelled it or invented it. The occupation band is the honest available baseline and the technology adjusts where inside it a given person sits.