Problem
Many resumes compress secondary roles/projects into a single dense line to save space, e.g.:
Also: MERN Stack Developer, NullClass (Jul–Sep 2024) — Stripe subscriptions, 93.9% auth uptime;
Web Developer, Solar Secure Solutions (Feb–Apr 2024) — Node.js, MySQL, REST APIs.
Also: DevSecOps Anomaly Detection Dashboard (Kafka, 10K+ events/min) | Stripe Subscription Engine
(Node.js, webhooks) | Solar IoT Dashboard (Node.js, MySQL, REST APIs).
work.jinja and projects.jinja have no instructions for this pattern, and neither the local Ollama models nor Gemini reliably pick these apart on their own — the LLM only extracts the entries that already have their own dedicated multi-line block, and silently skips everything packed into the condensed line.
Impact
On a real resume with 4 work entries and 5 projects (2 of each written in the condensed style above), extraction only produced 2 of 4 work entries and 2 of 5 projects. Since production and self_projects scores are derived entirely from what's in the extracted JSON, this understates a candidate's real history — through no fault of the resume's actual content, just its formatting.
Repro
Run score.py against a resume containing an "Also: ..." style condensed line for either work or projects, and check cache/resumecache_<name>.json — the condensed entries are absent from the work/projects arrays.
Fix that worked
Added explicit instructions + a concrete example to both work.jinja and projects.jinja telling the model that each semicolon/pipe-separated clause inside a dense summary line is its own separate entry with its own dates/description, not to be skipped just because it lacks a dedicated block. After this change, all 4 work entries and all 5 projects extracted correctly on the same resume, with no changes to the resume itself.
Problem
Many resumes compress secondary roles/projects into a single dense line to save space, e.g.:
work.jinjaandprojects.jinjahave no instructions for this pattern, and neither the local Ollama models nor Gemini reliably pick these apart on their own — the LLM only extracts the entries that already have their own dedicated multi-line block, and silently skips everything packed into the condensed line.Impact
On a real resume with 4 work entries and 5 projects (2 of each written in the condensed style above), extraction only produced 2 of 4 work entries and 2 of 5 projects. Since
productionandself_projectsscores are derived entirely from what's in the extracted JSON, this understates a candidate's real history — through no fault of the resume's actual content, just its formatting.Repro
Run
score.pyagainst a resume containing an "Also: ..." style condensed line for either work or projects, and checkcache/resumecache_<name>.json— the condensed entries are absent from thework/projectsarrays.Fix that worked
Added explicit instructions + a concrete example to both
work.jinjaandprojects.jinjatelling the model that each semicolon/pipe-separated clause inside a dense summary line is its own separate entry with its own dates/description, not to be skipped just because it lacks a dedicated block. After this change, all 4 work entries and all 5 projects extracted correctly on the same resume, with no changes to the resume itself.