Kjel Halsey Schlemmer Contact
← Back

Telescope

A hiring-history database tracking 15,000 companies across 16+ ATS platforms. It ingests open roles weekly and scores hiring velocity, so the signal is who started hiring hard three weeks ago, not who is hiring today.

In production Python Flask PostgreSQL Railway No LLM, by design

Results

15,000
Companies tracked, refreshed weekly
250,000+
Open technical roles under observation
16+
ATS platforms ingested through one scraper registry
18
Platforms recognized by the detection fingerprints

Thousands of new roles surface each week as the signal. Feeds Quiver, the prospecting platform, through an internal API.

Problem

Job boards show current postings only. There was no history: no way to distinguish a company ramping its hiring from one that froze last month, and no record of the week a push began. For a sales team whose buying signal is hiring velocity, the useful fact is the trend, and nobody stores the trend.

How it works

1

Detect the ATS

Six layers run cheap to expensive: DNS records, careers-URL probes, site fingerprints, slug-variant API probes, a Workday multi-instance sweep, and a headless-browser fallback. A bare domain goes in; the platform and board token come out.

2

Ingest weekly

Postings pull from 16+ ATS platforms with bounded concurrency and per-platform delay floors; the slowest platform gets three seconds between requests.

3

Keep the history

Each role is tracked from first sighting to removal. Weekly snapshots roll into a hiring-velocity score by region and department.

4

Serve the signal

The history drives a team dashboard and feeds Quiver through an API-key-gated internal API, so the action layer reuses persisted data instead of re-scraping.

What the history shows

New roles per week, six tracked accounts
representative series

One account started ramping in week 7 and is still accelerating. A job board shows week 12 only; the history shows the ramp.

Fig. 1 · Velocity scores roll up from this grid, per company, by region and department

Key decisions

No model in the pipeline

Classification is rule-based: reproducible week over week, auditable line by line, free to compute. The spec records the trade-off.

Idempotent ingestion

Upserts on a unique company-and-job key mean re-running a batch cannot corrupt history. For longitudinal data, this is the load-bearing property.

Crash recovery as a requirement

A durable Postgres-backed work queue commits per domain and resumes a crashed batch where it stopped. A weekly pipeline that silently loses a week destroys its own signal.

Technical details

Services
Web, scraper, and scheduler in separate containers with independent deploys
Migrations
Alembic
Testing
129 tests with transactional rollback against a real Postgres instance, not mocks
Hard parts
Workday required reverse-engineering its internal paginated XHR; Ashby reads through GraphQL
Status
In production; designed and built by me. Serves as the signal layer behind Quiver.