JobHunter

1Introduction

A modern job search produces an information-flow problem at the wrong end of the funnel. Aggregators are good at surfacing roles and bad at filtering them; the cognitive load of triage falls entirely on the searcher, and the searcher is rarely operating at peak rationality during a search. The thesis behind JobHunter is that the only filter capable of doing useful work at this volume is one that has been told, in detail, what the searcher actually wants. That filter is then easy to delegate to an LLM with sufficient reasoning capability.

This is not a product attempt. It is a system built for one user, and the value derives almost entirely from the specificity of that user's encoded preferences.

2Method

2.1Six-dimension scoring framework

Each role is scored on six dimensions: role fit, compensation, growth potential, location and relocation, team quality, and mission alignment. Each dimension carries a weight set by hand and adjusted over time. The Claude API is given the role description, the framework definition, and the per-dimension weights, and is asked to return a calibrated score per dimension and an aggregate normalised to 0–100, with reasoning attached.

2.2Discovery

Four site-specific crawlers run in Playwright with BeautifulSoup as a fallback for static pages. Job boards are JavaScript-heavy in 2026 and increasingly hostile to scraping; Playwright handles dynamic content reliably at the cost of speed. Each crawler runs once per day and pushes new roles to the scoring queue.

2.3Notion as both database and UI

Scored roles are written to a Notion database with structured properties (title, company, score, dimension breakdowns, link, raw description). Notion provides a stable API and a familiar filterable interface without requiring a custom dashboard. The trade-off is limited customisation; the payoff is that triage happens in a tool the user already lives in.

2.4Outcome feedback

Application outcomes (rejected, screened, interviewed, offered) are recorded against each role and used to recalibrate dimension weights periodically. This is the quietest but most valuable part of the system: the framework that scored well at month one is almost certainly not the framework that scores well at month three.

3Implementation

Layer	Choice	Why
Discovery	Playwright + BeautifulSoup	JS-heavy boards need a real browser; static pages do not.
Scoring	Claude API	Reasoning quality at the edge cases; long context per role.
Database / UI	Notion API	Familiar UI; no custom dashboard required.
Schedule	GitHub Actions	Free cron, zero server maintenance.
Language	Python	Mature scraping and API ecosystems.

4Results

• 4 sources actively crawled, daily.
• 500–1,000 roles scored per day in steady state.
• Discovery latency: under 5 minutes from a job appearing on a board to it landing in Notion.
• Cost: roughly $5–10 per day in Claude API charges; GitHub Actions free.
• Active calibration: weights re-tuned against outcomes monthly.

5Discussion

The lesson generalises beyond job search: the right way to apply LLMs to a flood of low-signal information is to give the model a clear, hand-written scoring rubric and let it do the boring work consistently. It is not a triumph of model intelligence. It is a triumph of writing the rubric down.

Near-term work focuses on the calibration loop: refining dimension weights against actual interview outcomes, tracking application-to-interview conversion as a ground truth, and adding an interview prep module (company research, role-specific checklists, salary research). The architecture would generalise for anyone willing to encode their own goals; productisation is not the aim.

6References