Methodology
How every figure on this site is produced, and what we refuse to claim
Most of what we publish is an estimate built from public data. That is not a disclaimer to get past — it decides what the numbers can honestly be used for, so this page says plainly where each one comes from, what floor it has to clear before we show it, and which claims we will not make even when the data would let us.
Pay figures
The headline band on our wage pages is the US Department of Labor's Bureau of Labor Statistics wage series — payroll figures employers report from their own records, covering everyone working in the occupation rather than only those who answer a poll. Nobody self-reported them, and no salary we publish was submitted by the person earning it.
These are earnings of people already in the job, not the pay advertised on current openings, and advertised pay tends to run above them. It is a sample of employers rather than a census, so every figure is an estimate. BLS publishes no margin of error for the wage percentiles — only for the employment count — so we treat a median as a solid central figure and never as a precise one.
Some pages also show what employers formally attest they will pay a sponsored worker, from H-1B Labor Condition Application disclosures. Those are real, filed, public wages that legally bind the employer, but the population is only employers who sponsor work visas — neither everyone hiring for the role nor a random sample of them. Sponsorship concentrates in large well-paying technology employers and in IT staffing firms filing toward the lower end, and we have not measured which effect wins. So it sits beside the earnings band and is never averaged into it: there is no meaningful figure halfway between what a role pays and what a visa filing committed to.
The floor. We do not publish a wage band for an area with fewer than 100 people in the occupation, or where the employment estimate behind it is too thinly sampled to stand behind (a relative standard error above 30%). That floor is a sample-size proxy, not an error bar on the wage itself — BLS does not publish one, and we will not imply otherwise.
Job postings
Postings are collected from employer applicant-tracking systems and job boards. One requisition is frequently syndicated across many boards and many per-city copies, so we group them and treat one member as canonical; a posting page tells you when it is one of several copies, because applying eight times to one opening helps nobody.
We do not republish the employer's description. A signed-out visitor — including every search engine — sees the facts we extracted and the summary we wrote, never the employer's own text. That is a deliberate limit on what this site is: the employer wrote that description, and the place to read it is their posting, which we link to on every page.
Postings expire. When a liveness check finds a requisition gone we say so on the page and tell search engines the URL is gone, rather than leaving a dead listing to be discovered as a live one. We report the same status to a crawler as to a reader — varying what we say by who is asking is cloaking, and we do not do it.
What the AI reads, and what it can get wrong
A language model reads each posting and extracts its requirements — years, level, degree, clearance, skills, pay — plus a short written summary of what the role is. That is a reading of someone else's text, and readings can be wrong.
So we show the model's own reasoning on the page rather than only its conclusions. When it collapsed "Bachelor's + 5 years OR Master's + 3" into a single figure, or filed a hybrid role under one of two plausible occupations, or treated an either/or list as one requirement instead of three, it says so and says why. If you bounce off a requirement, the note is where you find out whether the posting offered a second path.
Market estimates
On many postings we estimate how many people plausibly meet what it asks for. That figure is a model, not a headcount: it takes the occupation's employment in the relevant area from BLS, then narrows it by how common each required skill is across our own corpus of postings and by the seniority the requisition asks for.
It is always shown as a range, never as a bare number, because a lone figure reads as something somebody counted. It is dated, because the inputs move. And where the estimate cannot honestly be made — no employment data for that occupation and area, no hard requirements to narrow by, a requirement stack we cannot price — we show nothing at all rather than a zero. A pool we declined to size is not a small pool, and rendering it as one would tell you nobody qualifies for a job we simply could not measure.
What we deliberately do not do
- We do not average our two pay sources. Earnings and attested visa wages describe different populations; the number between them describes nobody.
- We do not show a trend from a single data release. Drawing a line through one point is inventing a finding. When a second release lands, the comparison appears.
- We do not say a job requires no degree. A posting that never mentions one and a posting that says "Bachelor's or equivalent experience" are indistinguishable to us downstream, and telling you a degree is not required when the employer never said so could cost you an application. We name a degree only when one is genuinely required.
- We do not invent an application deadline. We do not know the employer's, and guessing one from our own retention window would put words in their mouth — and an early guess would drop a live job out of search results.
- We do not claim you can apply here when you cannot. Most postings are applied to on the employer's own site, and we tell search engines exactly that.
- We do not publish a figure we cannot source. Every number on this site traces to BLS, the Department of Labor's disclosure data, the Census gazetteer, O*NET, or our own corpus of postings — and the page says which.
Corrections
If a figure here looks wrong, it may be. Estimates built from public data carry real error, and we would rather hear about it than not: email melissa@lqlogicllc.com with the page URL and which number looks wrong. We will correct what is wrong and say what changed.
See also our Privacy Policy and Terms of Service.