A résumé that compiles

Jun 11, 2026 · 6 min read

Treating a one-page résumé like a software artifact: content as data, layout as code, a renderer, and a linter that measures how well every line is used. Built iteratively with a render → screenshot feedback loop.

The premise

A résumé is usually a fragile Word document you nudge by hand until it looks right. I wanted the opposite: a source of truth in data, a deterministic renderer, and an automated check that the output is actually good — the same way you'd treat any small program. The result is a pipeline where the content lives in JSON, a Python script renders it to a pixel-faithful PDF, and a custom linter scores how much of every line the text actually fills.

1 · Forensics on the original

It started from a 1.2 MB .docx. The first job was understanding how it was built. The file was a ZIP of XML, and the metadata told a story: created in Word, run through a 3-Heights PDF tool, with four weights of Carlito (a Calibri clone) embedded.The embedded fonts are nearly all of that 1.2 MB. The actual words on a one-page résumé barely register. In other words, it was a PDF that had been converted back into a DOCX.

That diagnosis mattered. A reconstructed DOCX has no real structure — no tables, just 54 paragraphs positioned with tabs and runs of manual spaces, plus converter noise like explicit strike=0 toggles on every run and words split mid-token ("Post"+"g"+"reS"+"QL").

2 · Content as data (in Markdown)

Content and layout are separated. Everything a human edits lives in resume.json; all positioning lives in build_resume.py. The early version encoded bold/italic/links as nested arrays — ugly and hard to write. So inline formatting became Markdown, parsed by the renderer.

{ "header": "**Production Engineer** at **Meta**  *Menlo Park, CA*",
  "date": "May 2025 - Present",
  "bullets": [
    "Owned a CI pipeline processing 100K+ diffs/day ... gated on Meta's
     [Diff Risk Score](https://engineering.fb.com/...) so each changeset ran
     only the checks likely to catch its regressions."
  ] }

3 · The render pipeline & the screenshot loop

The renderer uses python-docx. To see the result, the document is converted with headless LibreOffice and rasterized — so every change can be inspected visually, not just asserted in code.

One command (./build.sh) runs the whole chain. The PNG is the feedback signal: catch a left-aligned title, a two-page spill, or a stray underline by looking, then fix the data and re-run.

4 · The interesting part: a line-utilization linter

A bullet with five words stranded on its own line wastes space. I wanted a number for it: 100% = the line is full, 0% = blank. And a rule — never split a bullet to fix it; if it wraps to two lines, report both lines so the wording can be adjusted.

The naïve approach is "average character width." That's wrong — proportional fonts vary widely.In Carlito a "W" is roughly three times the width of an "i". An average tells you nothing about either. Instead the linter reads Carlito's real per-glyph advance widths from the embedded TTF, sums them, and greedily wraps words exactly the way Word/LibreOffice does. Utilization is then natural_text_width / available_width.

A spot-check against the renderer's own word coordinates confirmed the model is accurate to within a percentage point:

5 · Using the linter to optimize

With a trustworthy number, rewriting bullets becomes a loop instead of guesswork: write a draft, read its last-line utilization, add a concrete detail or trim to one line, repeat. The verdict keys on the last line — earlier lines justify to 100% in the render, so only the trailing line can waste space.

6 · From one résumé to a directory of them

One résumé became a reusable Claude Code skill. The insight: you apply to many jobs, but you shouldn't rebuild from scratch each time. The skill keeps a directory of versions, each tagged with the job it was used for, and exposes three flows:

What it adds up to

The throughline is treating a document like code: a single data source, a deterministic build, a visual feedback loop, and an objective quality gate. The line-utilization linter is the part I'm most happy with — it turns a vague "this looks empty" into a calibrated number that's accurate to the renderer within a point, and that number is what makes automated rewriting and résumé-matching trustworthy.

Tags: Python, Tooling, LLM, Claude, Résumé