How it works
The hard part of applying at volume is not filling forms. It is knowing which 50 of 4,000 postings are worth the hour, keeping one identity consistent across six portals, and noticing a reply before it goes cold.
- 1
Ingest
Postings come from Greenhouse, Lever and Ashby job boards, Handshake, Workday tenants and Indeed. The first three publish structured JSON per company, which is why they are cheap to poll and why a posting from them arrives with its real requirements rather than a scraped blob. Everything is normalised to one shape before it is stored.
- 2
Score, and keep the reason
Every posting is scored 0–100 against one profile: title match, skill overlap, location against a hard commute filter, a pay floor, staleness, and the friction of the portal itself. The scorer returns its reasons with the number. A ranking you cannot explain is a ranking you cannot fix, so the why is a first-class output, not a log line.
- 3
Deduplicate
The same job is posted to four boards under three titles. Matching on company plus normalised title plus location collapses them, so the queue holds roles rather than postings — and nobody gets two applications from the same person.
- 4
Apply
Accounts are created once per portal and reused, with credentials held in a vault outside the repo. High-friction portals — Workday wants a fresh account and your whole history per employer — are scored down rather than skipped, because sometimes the role is worth the twenty minutes.
- 5
Watch the inbox
A reply is the only real signal in this system. Incoming mail is classified as rejection, scheduling request, recruiter question or noise, and matched back to the application by company and thread. Scheduling requests are checked against a calendar before anything is confirmed. Status moves because something happened, never on a guess.
- 6
Measure the funnel
Reply rate per source and per score band is the only way to find out whether the scorer is any good. If roles scoring 80 do not reply more often than roles scoring 60, the weights are wrong and the board says so.
Design notes
Scores are computed, never stored. Persisting a score would mean every weight change needed a backfill, and old rows would quietly disagree with new ones. Storing the inputs and deriving the score keeps one source of truth.
Stages move on evidence. There is no timer that promotes an application to “probably reviewed”. A stage changes when an email arrives or a portal status flips, which means the funnel numbers are worth trusting.
This page ships demo data. A public portfolio build has no business exposing a real application history — which companies rejected whom is nobody else’s business. The live run writes to a private Postgres; this build is seeded with representative postings so the logic is still inspectable.
Weights are blunt on purpose. A learned model over a few hundred applications would overfit and could not be explained in an interview. Linear weights with stated reasons beat an unexplainable improvement at this data volume.