Scoring a Competitor Hiring Spike: Real Acceleration or Noise

A competitor's open-role count jumps 60% in a month. Before you brief anyone or move budget, you have one upstream question to answer: is that jump real hiring acceleration or an artifact of reposts, duplicates, and the January calendar. This guide is for strategy, talent-intelligence, and research analysts who need to turn a raw posting count for one company into a defensible verdict: real acceleration, ambiguous, or noise. It gives you the deflators to apply, the baseline math that survives contamination, and the specific false positives that make a spike lie.

Most competitor-intelligence guides read a rival's intent once you trust the count. This is the missing step before that one. It decides whether the count is trustworthy at all, scored against the company's own baseline rather than an industry average that does not exist.

What "velocity" means, and why raw count is the wrong unit

Hiring velocity is open roles divided by current headcount, not the raw number of postings. A 500-person company with 75 open roles has higher velocity than a 10,000-person company with 200, because velocity measures proportional urgency, not absolute volume.

Raw count fails the moment you compare two companies of different sizes, and it fails again when you compare one company to its own past after it has grown. The normalizer that survives both is the ratio to headcount, tracked as a percentage change over 7, 30, and 90-day windows. One vendor computes exactly this across more than 21 million companies, spanning 23 department categories, which tells you the unit is settled even if the thresholds are not.

There is no public "high versus low" velocity cutoff that holds as an industry standard. It is company-relative and size-relative. That is the whole reason this guide scores against a per-company baseline instead of handing you a universal number: no universal number exists.

If you want to convert a de-noised posting count into an implied hiring rate, Little's Law gives you the bridge:

Monthly Hires = Open Positions / Time-to-Fill (months)

Worked example:
  30 de-noised open engineering roles
  Time-to-fill = 2.5 months
  Monthly Hires = 30 / 2.5 = 12 hires/month implied

Treat the output as a ceiling, not a forecast. It assumes every open role converts, which the next section shows is a bad assumption.

The four inflators that turn a flat quarter into a fake spike

Four documented artifacts inflate a raw count: cross-board duplicates, ghost or unfilled repostings, evergreen roles, and reposting for visibility. Each one reads as new demand and none of them is.

Raw job-posting feeds often contain 30 to 45% duplicates, because the same req is republished across multiple boards and each copy is counted once. Ghost postings - listings kept open with no genuine intent to fill soon - run 18 to 22% of postings per quarter on one large hiring platform, and roughly 70% of companies on that platform posted at least one ghost job in a single quarter of 2024. Evergreen roles stay open indefinitely so the employer can collect resumes for a future pool. And employers repost the same ad on a cadence purely to appear higher in search results.

These deflators stack multiplicatively, not additively. Apply them in sequence and a raw count can overstate real net-new demand by roughly half before you have normalized anything.

The deeper problem is that intent itself has decayed. Revelio Labs data shows fewer than 4 hires per 10 listings in 2024, down from 8 per 10 in January 2020. A spike today implies far less committed hiring than the same spike five years ago, and 85% of hiring managers who posted a ghost job still interviewed candidates - so even the interview signal is contaminated. If you carry over a threshold set before this decay, you will over-read every spike.

Each row is an independent haircut on the raw number, not additive. Take them in order.

Building a baseline that a real spike cannot hide inside

You cannot call anything a spike without a normal range, so the baseline is the whole standard. Track weekly or monthly posting volume across 6 to 12 months, segmented by department and location, and compute the center and spread of that history per function.

The naive move is to use the mean and standard deviation, then flag any point more than two or three standard deviations out - a Z-score above 2 or 3. This breaks in a specific and dangerous way: a spike inflates its own standard deviation. The anomaly you are hunting contaminates the very spread you measure it against, so it can hide below your own threshold. A genuine event that should be obvious scores 2.9 and gets filed as noise.

Median Absolute Deviation fixes this. It uses the median as the baseline, and the median does not move when a single large anomaly appears. The same real event that scores 2.9 on a standard Z-score can score far higher on a MAD-based modified Z-score, because the baseline was never inflated. Use MAD.

Once the baseline exists, three thresholds tell you when something structural is changing:

• A 50% or greater month-over-month increase in total postings.
• A 3x increase in engineering roles over the function baseline.
• A MAD-based modified Z-score above 2 to 3 for the segment in question.

The engineering rule matters more than it looks. A company can hold total headcount flat while one function doubles, and a total-count threshold will report nothing. Score by department, because a concentrated engineering or security spike is the signal, and a flat total is exactly where it hides.

The procedure: from raw count to scored verdict

Run these eight steps in order. Each removes one class of noise, so the numeric score at the end rests on a count you have already cleaned. Budget most of your time on the baseline; that is where the judgement lives.

On ordering: some workflows segment the competitor set by size and region first, then build the normal range. That is fine when you are scoring a portfolio of competitors. For a single company in front of you, the order above works - segment inside the baseline step rather than before it.

The careers page is your source of truth. Most companies maintain a careers section listing all open positions, and it is the most complete and up-to-date source because the hiring company controls it directly. Board aggregation adds breadth but introduces lag: by the time a posting appears on a major board, it has already been live elsewhere. Anchor every timestamp to the earliest place you saw the req.

Supply scarcity as a built-in de-noiser

Before you trust a spike in a specialized role, check whether the talent to fill it even exists in that market. A senior-specialist spike in a thin supply market is more likely aspirational or evergreen than a real, fillable ramp.

Refolk's index makes the point concrete for Rust engineers. The US pool dwarfs the German one, and the senior end of the US pool is effectively empty.

Counts come from Refolk's index; the share and multiple are derived from those counts. Now the seniority cut, same index:

A Director or VP-level Rust posting spike has effectively no local senior supply to draw on. That is a de-noising red flag: the req may be real intent, but if it cannot be filled, it will sit open, get reposted, and inflate the very count you are scoring. Treat a spike in roles with near-zero supply as ambiguous at best until you see actual joins.

This is the point where a raw board scrape stops helping and a people-level index takes over. Deduped postings tell you what a company wants; the supply check tells you whether it can get it.

Running the supply query is faster than debating whether a spike is real. If Refolk returns a handful of profiles for a role a competitor is suddenly posting five of, the spike is aspirational and you can say so with a number attached. If it returns a deep bench, the ramp is plausible and the posting deserves the real-acceleration branch.

How this goes wrong: the false positives that survive a naive count

The failure modes below are where a raw or half-cleaned count lies. Each has a signature and a check. This is the most valuable section to keep open while you score, because most bad verdicts come from one of these, not from arithmetic.

• Counting duplicates as growth. A cross-board republish reads as a new req, so one posting on five boards looks like a spike. Check: dedupe by job ID and description hash before any count.
• Evergreen roles inflating both baseline and spike. High-turnover sales and support reqs stay perpetually open, and a stable listing gets counted as new demand. Check: flag reqs open beyond a normal cycle or reposted on a fixed cadence.
• Internal-candidate reqs. A req with an internal candidate already picked is genuine, fresh, specific, and complete - it passes every detector. No metadata test works. Check: discount by base rate and corroborate with actual joins.
• Seasonal January and February surge mistaken for strategy. BLS data shows more jobs added in January and February than any other months, so a calendar bump reads as acceleration. Check: compare the same window year-over-year, not just month-over-month.
• Contaminated Z-score baseline. The spike inflates its own standard deviation and hides below threshold, so a real event scores as noise. Check: use MAD or a modified Z-score.
• Board-of-origin lag double-counting. Aggregator lag makes an old careers-page role look new when it later surfaces on a board. Check: anchor timing to the earliest-seen source.
• Total-count blindness to function. Flat total headcount hides a function doubling, producing a false negative. Check: score by department, since concentrated engineering or security spikes are the real signal.

The seasonal trap deserves a number. The historical January posting rebound runs around 60%; one recent January it came in near 13%. If you only knew the historical figure, you would have called a normal-for-the-calendar quarter a slump, and a normal spike an acceleration. Year-over-year comparison against the same calendar window is the only defense.

Reading the verdict onto a timeline

Two lead-time horizons mean two different verdicts, and conflating them mistimes your response. A spike tells you when to act only once you know which horizon it sits on.

Velocity signals typically surface 20 to 30 days before active recruitment begins, because posting acceleration reflects internal budget approvals and hiring-manager briefings already in motion. That is the tactical horizon: enough runway to prepare a counter-move, not a product bet.

The strategic horizon is longer. Competitors start hiring 6 to 18 months before they announce a product, so monitoring postings lets you catch a move at the job-posting stage rather than the announcement stage. One documented case ran nine months between a posting surge and the announcement of a US headquarters with localized pricing. A real-acceleration verdict on a new function - a first-ever RevOps hire, a new security team, a cluster in a new metro - usually points at this horizon.

A spike without a horizon is a number without a decision attached to it.

Name the horizon in the verdict. "Real acceleration, tactical, 20-30 day window" and "Real acceleration, strategic, likely a 6-18 month launch ramp" send you to completely different responses.

Keep the score honest: what to verify before you ship the verdict

Run this before the verdict leaves your desk. Every item is a check you can fail, not a topic to think about.

Keeping the standard current

The thresholds in this guide are anchored to a moving baseline, so re-anchor them on a schedule rather than trusting the numbers forever. The single most important thing to re-check is the intent-to-hire rate.

Postings-as-intent lost half its signal in four years, falling from 8 hires per 10 listings to under 4 per 10. If that decay continues, a spike will imply even less committed hiring, and the 50% month-over-month and 3x-engineering thresholds will need to move up to keep the same false-positive rate. Re-check the published hire-per-posting figure roughly once a year and adjust your thresholds if it has shifted materially.

Refresh two other inputs on the same cadence. First, each competitor's baseline: rebuild the 6-to-12-month normal range every quarter so growth does not silently reset what "normal" means. Second, the supply picture for the roles you watch most - a spike in a role that was thin last year may be fillable this year if the talent pool has grown, which changes an ambiguous verdict to a real one. Pulling the current supply for a specific role, market, and seniority in one query is where an index like Refolk saves the hour you would otherwise spend reconstructing it by hand.

The method does not expire. The numbers inside it do. Write the date of your last threshold re-anchor next to the verdict, so the next analyst knows how stale the standard behind it is.