Req RadarSoCal tech, EE, healthcare and SaaS job boardsFetched Oct 10, 2:15 AM · 264 boards

How it works, and the line it holds

Two small tools for a recruiting desk that places software and tech professionals, electrical engineers, healthcare clinicians, supply chain and logistics leaders, sales engineers and product managers. Public data in, drafts out, a human sends.

No LinkedIn automationNo scraping, no session cookies, no browser bots, no enrichment vendors. The builder writes boolean strings a recruiter pastes into Recruiter by hand. LinkedIn has been restricting automation vendors' accounts; this keeps the firm's seats safe.
Nothing sendsNo email, InMail or SMS integration anywhere. Outreach comes out as three editable drafts labeled "review before sending." There is no send button to find.
No candidate dataInputs are job descriptions and intake notes, never résumés or profiles. Nothing ranks or scores a person, so California's automated-decision rules for hiring (in effect since October 2025) are sidestepped on purpose.
No hidden mathCompanies rank by plain counts you can click into: open target reqs, stuck 45+ days, under 30 days, reopens, new in 14 days. Every age carries a basis tag: posted date, first seen, or reopen chain.

Req Radar

Every night it reads the public job-board endpoints of 264 target companies: Southern California tech, aerospace, defense and EV employers, the region's hospital systems, clinics and digital-health companies, and the SaaS employers that hire product managers and sales engineers in LA and remotely. These endpoints exist so companies can embed their own listings on their own sites; they are meant to be read, and the fetch identifies itself with a contact address, caps concurrency at five, and backs off on errors.

Titles are classified by rules first (about 94% of open postings never touch a model), and only ambiguous titles like "Automation Engineer" or "Test Engineer" go to a small model with the first 600 characters of the description. Verdicts are cached by normalized title, and each row says which path classified it.

A failed fetch touches nothing. If a board errors, none of its postings can be marked closed that night. A posting has to be missing from two consecutive successful fetches before it closes, so a flaky board never fakes a reopen.

Workday boards are read through the same JSON their public careers pages load; those hosts' robots.txt files allow the career-site path and publish a sitemap of postings. Workday only states an exact posting date per posting, so those ages start as "first seen" and firm up as details are fetched over the first few nights, a capped number per company per night.

Oracle Recruiting Cloud sites (Cedars-Sinai, Loma Linda) and iCIMS career portals (UCLA, UC Irvine, Medpace) are read the same way, through the public JSON their own search pages call. Oracle lists an exact posting date but no job description, so those postings classify on title alone; an iCIMS portal never returns more than its 500 newest postings.

Coverage is honest: the 31 target companies on Taleo, Phenom, SuccessFactors or a custom careers site are listed on the Coverage tab as not covered, not silently dropped.

Search Plan Builder

Paste a public job description, or arrive from a Radar row with it pre-filled, add the hiring manager's intake notes, and get back a structured plan: must-haves with the excerpt that supports each one, title variants and skill synonyms, LinkedIn Recruiter boolean strings for the Title and Keywords fields, a natural-language query, off-LinkedIn places to look (PE license lookups for power roles, patents and clearance for defense hardware, GitHub for software), five screening questions, open questions for the hiring manager, and three outreach drafts.

Before the model sees anything, a deterministic linter scans the JD and notes for bias proxies: "recent grad," "digital native," "native English speaker," "must be a US citizen" without a clearance basis, "no employment gaps," and so on. Each hit becomes a review item with a neutral, job-related rewrite. The model adds its own flags; code merges and dedupes them.

After the model answers, code checks what a model cannot be trusted with: exactly three drafts, each under 120 words, no client name when the confidentiality toggle is off, and no dollar figure that did not appear in the inputs. Anything it fixes is shown as a warning above the plan.

What v2 would add

Req Radar