CareerSignal
CareerSignal started as a tool for my own targeted search across AI-infrastructure and data-layer companies. It monitors career pages, detects genuinely new or changed postings, and turns each meaningful diff into a structured opportunity signal: what opened, where, at what seniority, and why it may matter. Firecrawl is the live-web layer; the agent decides whether the change is worth attention.
Built first for the candidate side — reducing the noise of manual job discovery across fragmented ATS systems, repost churn, and cosmetic edits so I spend time on the postings that actually matter. The same architecture can extend into recruiter benchmarking, GTM/vendor-motion tracking, and customer-side vendor intelligence, but the candidate use case is the starting point. The panel below runs a bounded live scan — a few pages per click, deterministic scoring, no cron.
Run a bounded scan
Hits live career pages for three AI-infrastructure companies via Firecrawl map, filters down to posting-level URLs, and ranks role signals with deterministic scoring. Low limits, short timeout, no cron. The API key lives in Vercel env vars and never reaches the browser.
The interesting problem isn't scraping.
A targeted search across AI-infrastructure and data-layer companies has a noisy discovery loop. Career pages are fragmented across Greenhouse, Lever, Ashby, Workday, and a long tail of custom React apps. Any one of them is a weekend scrape. Most “new” postings are not actually new — reposts, title normalizations, and cosmetic edits crowd the feed. The real work starts after collection: deciding which changes are genuinely new, what they imply about the company, how a role stacks up against comparable postings, and whether it is worth surfacing today.
CareerSignal treats scraping as a primitive and puts the agent on top. Firecrawl handles the live web — JS rendering, anti-bot handling, and structured extraction — so the agent can focus on judgment: is this diff meaningful, what does it signal, and is the role a fit against a stated profile? The candidate instance is mine. The same judgment layer is what makes broader market-intelligence extensions possible.
Target → Firecrawl → schema → diff → signal → brief
The pipeline runs every few hours. Most ticks are cheap: map to check whether anything changed, crawl and extract only on the subset that moved, and generate structured intelligence only for diffs that clear the signal threshold.
Watchlist + routing
Each target has an ATS hint (Greenhouse, Lever, Ashby, Workday, custom). That hint tells Firecrawl which primitive to use — map for list pages, crawl for nested postings, interact for JS-gated Workday boards.
Firecrawl as the live-web layer
map enumerates posting URLs; crawl walks role pages; scrape + extract pulls structured fields via LLM schema. JS rendering and anti-bot handling are handled by the primitive.
Normalized posting schema
Every ATS collapses into the same shape: company, title, location, team, job_url, posted_at, detected_at, requirements, raw_markdown. One agent interface, not five.
Diff against saved state
Last-seen hash per posting. New postings and substantive edits trigger downstream work. Reposts, title normalizations, and cosmetic churn are suppressed — that judgment is the agent's job, not the scraper's.
Role-signal scoring
The bounded demo uses deterministic scoring. The full pipeline can layer in LLM-assisted fit scoring over a configurable profile: role family, seniority band, tech overlap, location, and signal keywords such as agents, evals, and forward-deployed. Output includes a fit score and a short rationale.
Company + role brief
For high-signal diffs: a structured brief with company context, role intelligence, comparable postings, and an opportunity angle. Candidate-side prioritization comes first; recruiter, GTM, and vendor-intel use cases are natural extensions of the same signal.
A single posting, enriched
This is the shape the agent consumes and the brief generator reads from. It is intentionally boring — the interesting part is that every ATS collapses into the same structure.
{
"company": "Firecrawl",
"title": "Forward Deployed Engineer",
"location": "San Francisco / Remote",
"team": "Go-to-market engineering",
"posted_at": "2026-04-19T08:14:00Z",
"detected_at": "2026-04-19T10:47:00Z",
"job_url": "https://jobs.ashbyhq.com/firecrawl/cce0c787-3f5c-4f1a-8a60-3c3d8f7a5c2a",
"ats": "ashby",
"requirements": [
"Experience shipping agentic workflows in production",
"Comfort with TypeScript and Python",
"Customer-facing technical work"
],
"signals": {
"mentions_agents": true,
"mentions_evals": false,
"seniority": "senior",
"hiring_velocity": "accelerating"
},
"fit_score": 0.87,
"why_it_matches": [
"Forward-deployed scope — customer-facing agent work",
"Role explicitly references live-web extraction for agents",
"Seniority and role family aligned to the target profile"
],
"opportunity_angle": "Net-new FDE role at an infra-layer vendor — signals GTM motion shifting toward hands-on integration support."
}Structured opportunity intelligence
The agent produces one of these for each high-signal posting: company context, role intelligence, talking points, and audience-specific use cases. No generic advice, no firehose.
## Firecrawl — Forward Deployed Engineer
**Company signal.** Firecrawl sits at the live-web extraction layer for LLM
agents: map, crawl, scrape, and interact primitives across one API. The wedge
is reliability — JS rendering, anti-bot handling, and structured extraction
without gluing four scrapers together.
**Role intelligence.** Forward-deployed engineering sits between the customer's
agent stack and Firecrawl's primitives. The work is reading an unfamiliar
system, picking the right primitive, and turning a fragile notebook demo into
a production pipeline. Net-new FDE headcount is a GTM-motion signal: the
vendor is moving from self-serve toward hands-on integration support.
**Talking points for an evaluator.**
- The posting references agentic workflows and live-web extraction — aligned
with the stated product wedge, not a generic engineering hire.
- Forward-deployed roles at infra-layer vendors are a leading indicator of
customer concentration in specific verticals.
- Cost/latency architecture: map first, crawl only on change, extract only on
match — the pattern the customer is likely buying.
**Use cases for this brief.**
- The candidate — deciding whether to prioritize this role over the next three in the queue.
- Prospective employers evaluating the method behind the work sample.
- Recruiting teams tracking competitor hiring patterns in AI infrastructure.
- Founders and GTM leaders watching peer vendors for go-to-market shifts.
- Customers tracking whether a vendor is investing in integration support.The live-web layer for agents
The first version of this pipeline was four scrapers taped together. Greenhouse was manageable. Lever was manageable. Ashby needed careful pagination. Workday broke constantly and was never the same twice. The agent layer above it was strong; the foundation was not.
Firecrawl collapses that foundation into a cleaner primitive set: map for enumeration, crawl for traversal, scrape and extract for structured output, interact for JS-heavy boards. The agent on top stops caring about ATS quirks and starts spending its effort on the part that actually needs judgment.
CareerSignal is the candidate-side instance of that pattern. The scraper finds changes on the open web; the agent decides whether those changes matter and turns them into actionable context.
The candidate tool is the first surface, not the only one.
CareerSignal runs today on a single-candidate profile — mine. The diff engine, signal scoring, and brief generator do not depend on that audience. Change the watchlist and scoring profile, and the same pipeline supports adjacent workflows without a rewrite.
Peer-hiring intelligence
Swap the watchlist for a competitor set. The same diff engine surfaces new headcount, role-family shifts, and seniority moves as structured alerts instead of spreadsheet work.
Peer-vendor signal
Net-new forward-deployed, solutions-engineering, or integration hires at an infra vendor often signal a go-to-market shift. The same pipeline turns those postings into real-time competitive context.
Is my vendor investing in support?
Hiring patterns often reveal vendor priorities earlier than roadmap language does. Watch whether a vendor is staffing integration engineering, solutions architecture, or platform reliability.
Target-account movement
Reframe the watchlist as a target-account list. The same system becomes a sales-intelligence layer for buyer hiring, team expansion, or leadership gaps.
Stack & setup
Deliberately boring infrastructure. The interesting layer is the agent reasoning over structured postings, not the plumbing underneath.
# Firecrawl CLI — installs primitives and sets up the browser runtime
npx -y firecrawl-cli@latest init --all --browser
# Env (placeholders — real values live in .env.local, never committed)
export FIRECRAWL_API_KEY="fc_..."
export ANTHROPIC_API_KEY="sk-ant-..."
# Tick the pipeline (cron runs this every few hours)
pnpm run careersignal:tickBuilt for my own search. Designed like a reusable intelligence system.
The live scan above is intentionally small — a few pages, deterministic scoring, safe for a portfolio link. The full pipeline scales to diff-on-change, richer fit scoring, company and role briefs, and digest delivery on a cron. Personal use case first; productized architecture underneath.