Finding Companies Hiring AI Engineers (or Using Salesforce): Hiring Signals as Data

Two searches that look unrelated — “companies hiring AI engineers” and “list of companies using Salesforce” — have the same best answer: job postings. A company with three open ML roles is building an AI team, today, with budget. A company hiring a “Salesforce Administrator” runs Salesforce; one hiring a “HubSpot Marketing Manager” pays for HubSpot. Postings are public, first-party, and expensive to fake. This guide shows how to extract these signals yourself, why naive keyword matching produces embarrassing lead lists, and what an evidence-backed signals dataset looks like.

Why postings beat technographics vendors

The traditional way to get “companies using X” lists is technographics vendors (BuiltWith, HG Insights, ZoomInfo intent). They’re useful but have known weaknesses: website-tech detection only sees front-end tools, install-base data ages badly, and intent data is inferred from opaque panels. Job postings are different in kind:

• First-party. The company itself wrote “experience with Salesforce CPQ required”.
• Timestamped. You know when the need existed — recency you can filter on.
• Rich. The same posting tells you team size hints, seniority, location, and often salary.
• Auditable. Every claim links to a posting URL a salesperson can read before the call.

The weakness: postings only show hiring-related adoption. A company running Salesforce with a fully staffed team emits no signal. Postings-based lists are high-precision, moderate-recall — exactly what outbound teams want (they’d rather have 500 companies that certainly use X than 5,000 maybes).

Do it yourself: from postings to signals

Assume you have a postings table (see our job postings guide for collection from public ATS endpoints). A first-cut “companies building AI teams”:

SELECT company_name,
       COUNT(*)                          AS ai_openings,
       MIN(collected_at)                 AS first_seen,
       ARRAY_AGG(DISTINCT location)      AS locations
FROM postings
WHERE collected_at >= CURRENT_DATE - INTERVAL '180 days'
  AND (title ILIKE '%machine learning%'
       OR title ILIKE '%ml engineer%'
       OR title ILIKE '%ai engineer%'
       OR 'pytorch' = ANY(tech_stack))
GROUP BY company_name
HAVING COUNT(*) >= 3
ORDER BY ai_openings DESC;

This works — and then you discover the failure modes:

False positives from requirement soup. “Nice to have: exposure to AI tools” does not mean the company builds AI. Keyword hits in a wish-list section are noise; you need to distinguish required skills from mentioned ones, and role-defining titles from buzzword titles.

Company name chaos. “Datadog”, “Datadog, Inc.” and three subsidiary board slugs must resolve to one company or your counts fragment.

Taxonomy drift. Is “LLM engineer” an AI role? Is “Airflow” data-engineering or infrastructure? Useful signals need a maintained technology taxonomy, not an ad-hoc keyword list.

Signal thresholds. One posting is an experiment; three in 180 days is a team. Thresholds and windows need to be explicit and consistent, or downstream users can’t compare signals.

This is exactly the derivation work in our hiring-signals dataset: 394,300 live ATS postings distilled into 115,976 evidence-backed signals across 6,295 companies, using a 126-technology taxonomy and four signal types — technology adoption, team building (e.g. companies with 3+ AI openings in 180 days), geographic expansion (first postings in a new city), and leadership hires (first Head-of/VP roles). Every signal row carries the posting URLs it was derived from.

Using signals: examples

Python, building a targeted outreach list with evidence:

import pandas as pd

signals = pd.read_parquet("hiring_signals.parquet")

# Mid-size companies that started building AI teams recently,
# and also hire for HubSpot -> martech-friendly AI adopters
ai = signals.query("signal_type == 'team_building' and topic == 'ai_ml' and openings >= 3")[
    ["company_id", "company_name", "openings", "evidence_urls"]
]

hubspot = signals.query("signal_type == 'tech_adoption' and technology == 'hubspot'")["company_id"]

leads = ai[ai.company_id.isin(hubspot)]
print(leads.head(10))  # each row links to the actual postings

Common applications:

• Outbound prospecting. “You’re hiring three ML engineers — here’s how we cut model-serving costs” outperforms generic sequences because the trigger is real and recent.
• Recruiting intelligence. Agencies spot companies ramping teams before they engage search firms.
• Competitive/market analysis. Adoption curves per technology, by company size and geography, from live demand rather than surveys.
• Investment research. Hiring velocity and seniority mix as leading indicators for private companies with no other public financials.

Timing: why recency windows make or break signal value

A hiring signal is perishable in a way most datasets aren’t. “Company X is building an AI team” is a sales trigger precisely while the team is being built — once the roles are filled, your email lands on a manager who already picked their vendors. This has three practical consequences for how you should consume signals. First, prefer state changes over states: “first AI posting ever, 45 days ago” beats “has AI postings” every time, because the former marks the beginning of a buying cycle. Second, decay your lists: a signal older than one hiring cycle (roughly 90–120 days for tech roles) should drop out of active sequences automatically, or reply rates degrade and your domain reputation with them. Third, watch velocity rather than volume for account prioritization — a company going from zero to four open ML roles in a quarter is a stronger trigger than one that has carried six open roles for a year (the latter often signals hiring difficulty, which is its own signal, useful to recruiters rather than vendors).

This is also the honest argument for refreshed editions over one-off exports: the derivation logic is stable, but the rows age like produce. Whichever source you use — DIY or ours — build your workflow around first-seen/last-seen dates, not around the existence of a row.

Free DIY vs. the derived dataset

	DIY from postings	DataForge hiring signals
Cost	Your pipeline + taxonomy time	From $99
Input	Postings you collect	394,300 live ATS postings (maintained upstream)
Signal quality	Keyword matching, your thresholds	126-tech taxonomy, explicit thresholds, 4 signal types
Entities	DIY name resolution	6,295 resolved companies
Auditability	—	Evidence posting URLs on every signal
Maintenance	Continuous	Refreshed editions

Honest guidance: if you track five technologies at fifty companies, the SQL above plus direct ATS polling is genuinely enough. The dataset matters at scale — full taxonomy, resolved entities, and evidence trails your sales team can trust. Start with the free sample to see the signal schema.

FAQ

Is this just scraped LinkedIn data? No. Signals derive exclusively from public ATS endpoints (Greenhouse, Lever, Ashby, Workable, SmartRecruiters) that companies use to publish jobs. Every signal carries its source posting URLs.

How current are signals? Signals are computed over rolling windows (e.g. 180 days) from monthly posting snapshots; each signal row carries first/last-seen dates.

Can a company appear by mistake? Requirement-soup filtering reduces this sharply, but no classifier is perfect — which is why evidence URLs ship on every row: verify before you act.

How does this compare to intent-data vendors like Bombora or 6sense? Different signal physics. Intent data infers interest from anonymized content-consumption panels — “someone at company X read three articles about data warehouses” — which is broad, early-funnel, and unverifiable by design. Hiring signals are narrow, mid-funnel, and verifiable: the company committed budget to a role. In practice teams stack them: intent data for account scoring breadth, hiring signals for trigger-based sequencing where the message can cite the evidence. The citable evidence is the underrated part — an SDR who can write “saw you’re hiring three ML engineers” earns a reply that “your company showed intent on our topic cluster” never will.

What about companies that hire through agencies or don’t post publicly? Genuinely invisible to this method, and worth being honest about: executive hires via search firms, confidential replacements, and contractor-heavy staffing all bypass public ATS boards. This biases coverage toward companies that hire in the open — which correlates with growth-stage tech, our covered slice. For enterprise accounts that post on Workday-style career sites, posting-derived signals exist but require different (messier) collection; the datasheet states exactly which ATS platforms our corpus covers.

Can I build alerts instead of pulling snapshots? The dataset ships as editions, but the practical alerting pattern is cheap: diff consecutive editions on (company_id, signal_type, technology) keys and route new rows to Slack or your CRM via a ten-line script. First-seen dates make the diff trivial. Teams that operationalize signals this way — new signal → enriched account → sequenced within a week — capture most of the timing value that continuous monitoring would add.

“Companies using Salesforce” — users or partners? Both hire for Salesforce skills. Consultancies/SIs are flagged where detectable via posting patterns; the datasheet documents the heuristic and its limits.