How we count

457,191 live US postings, read directly from 64,697 employers’ own careers pages as they stood in August 2026. Nothing is scraped from a jobs aggregator, so a single role reposted across five sites is counted once rather than five times. Duplicate inflation is most of why job-market numbers from different sources disagree.

22,362 of those fall into the technical roles we report on (4.9%). The rest of the corpus is every other kind of job — the board is a general US job board, and healthcare and sales postings outnumber engineering ones — and is not analysed here.

Counts, seniority, locations, employers and sponsorship cover every posting. They are derived from the job title and from fields the employer already publishes, so no posting is excluded and nothing is sampled.

Skills, pay and years of experience cover a subset — 127,154 postings, 27.8% of the corpus — because they require reading the full description, which costs a model call per posting.

That subset is not a random sample. It was assembled by the system that matches jobs to candidates, which favours the roles our users search for. We know this skews it: technical roles are roughly three times denser in that subset than in the rest of the corpus. Counts are unaffected — they come from the full corpus — but treat every skill and pay figure as describing the subset rather than the market, until we replace it with a sample drawn at random for the report.

This is the limitation most likely to mislead. Our extraction returns a single list of skills per posting and does not separate a hard requirement from a nice-to-have. “67% of postings name Python” counts both “5+ years of Python required” and “Python a plus”.

Read every skill percentage as how often something is asked about, never as how often it is mandatory. Making the stronger claim would need a different extraction, and until we have one we will not make it.

Percentages use the postings that produced any skill as the denominator (94–99% of the subset, depending on role), because measuring against all postings would understate every skill by our own extraction-miss rate — a fact about our pipeline, not about hiring. The extraction caps at 25 skills per posting, which truncates about 3% of descriptions and slightly under-counts skills that appear in long technology lists.

Only a minority of postings state a salary, and that minority is not a random sample: it leans toward states with pay-transparency laws and toward employers who pay well enough to advertise it. The corpus also skews senior.

We publish the midpoint of an advertised range. That is not a wage. The US Bureau of Labor Statistics puts the median software developer wage at $133,080 (May 2024); our figure for the same role is about 45% higher, and both are correct about different things. If you want to know what the job pays, believe BLS. If you want to know what a well-funded employer will advertise for a senior role, that is ours.

Where a cut has fewer than 30 disclosed salaries we publish no band at all, and the page says so rather than leaving a blank that reads as zero.

Two different strengths of evidence, kept apart. Verified means the employer appears in US government H-1B approval records for the last three fiscal years — a public filing you can check. States it sponsors means only that a job description said so, with nothing behind it.

We previously added the two together and described the total as verifiable, which overstated the checkable figure by up to six points on some roles. Both are facts about the employer, never a promise about a specific posting: a company that sponsored last year can decline to sponsor this role.

A posting counts as live if it was still on the employer’s careers page the last time we read it. That is the best available signal and it is not proof the role is genuinely open — some postings outlive the vacancy. Counts measure what employers are advertising, not how many seats are unfilled.

An LLM reads each full job description once and returns the facts it states: skills named, minimum years of experience, seniority, pay range, work arrangement. We store those derived facts and never the description text.

Seniority is read from the job title rather than the description, so it covers every posting rather than the enriched subset. That is also the figure with the strongest external corroboration — see below.