Applying Platform Thinking to the Job Hunt

Most job appli­ca­tions today are screened by AI-​driven appli­cant track­ing sys­tems (ATS) before a human ever sees them. That means for­mat­ting con­sis­ten­cy, key­word align­ment, and clar­i­ty aren’t just nice to have — they’re sur­vival traits. Manually tai­lor­ing each ver­sion is slow and error-prone.

I’ve been build­ing pro­duc­tion sys­tems for thir­ty years, from back­end ser­vices to release automa­tion. When I saw myself main­tain­ing mul­ti­ple Word doc­u­ments for dif­fer­ent job con­texts, I did what any soft­ware engi­neer would do: I built a sys­tem instead.

The problem and solution

Job hunt­ing requires mul­ti­ple résumé ver­sions for dif­fer­ent roles like plat­form vs back­end. It also demands mul­ti­ple for­mats like PDF, HTML, and plain text for ATS fil­ters. Additionally, you need to man­age the con­tent selec­tive­ly by hid­ing old projects, lim­it­ing bul­lets, and empha­siz­ing dif­fer­ent skills. Manually main­tain­ing these vari­a­tions leads to copy-​paste errors, out­dat­ed infor­ma­tion, and hours spent reformatting.

Instead of man­ag­ing vari­ants man­u­al­ly, I treat my résumé as data flow­ing through a con­fig­urable trans­for­ma­tion pipeline. One YAML file adher­ing to the JSON Resume schema serves as the source of truth. Pandoc with cus­tom Lua fil­ters trans­forms it based on YAML con­fig files.

The fil­ters hide entries marked x-hidden: true, fil­ter by date ranges, lim­it bul­let points, and for­mat dates con­sis­tent­ly. They also adjust sec­tion titles auto­mat­i­cal­ly. The sys­tem out­puts PDF (via WeasyPrint), HTML, Markdown, or plain text. Git branch­es track ver­sions per company/​role.

The archi­tec­ture sep­a­rates con­tent (YAML), pre­sen­ta­tion (tem­plates), and trans­for­ma­tion log­ic (Lua fil­ters). Configuration over dupli­ca­tion. Infrastructure as code.

Example: Platform engineering résumé

Here’s how that think­ing plays out in prac­tice. For a plat­form engi­neer­ing role, I want to:

1. Hide CPAN projects old­er than 10 years (too Perl-focused)
2. Limit work high­lights to 3 per job (keep it concise)
3. Emphasize con­tainer­iza­tion and automa­tion experience

Example commands

# Adjust configuration
vim share/pandoc/metadata/date_past.yaml        # Set project age limit
vim share/pandoc/metadata/highlights_limit.yaml # Set bullet limits

# Generate
./scripts/save_pdf.sh eg/mjgardner_resume.yaml

# Or with Docker
docker compose run --rm resume-remixer \
  ./scripts/save_pdf.sh eg/mjgardner_resume.yaml

The pipeline automatically:

• Filters out old projects
• Trims bul­let points to the first 3 per job
• Updates sec­tion titles (“Projects” → ​“Selected Recent Projects”)
• Generates clean, pro­fes­sion­al PDF output

No man­u­al edit­ing. No copy-​paste. Reproducible every time.

Infrastructure thinking in practice

Platform engi­neer­ing isn’t just spe­cif­ic tools — it’s an approach. When you see a repet­i­tive man­u­al process, you auto­mate. When data needs mul­ti­ple rep­re­sen­ta­tions, you build trans­for­ma­tion pipelines. When repro­ducibil­i­ty mat­ters, you containerize.

This résumé gen­er­a­tor uses the same prin­ci­ples I apply to release pipelines and build automa­tion. One source of truth, con­fig­urable trans­for­ma­tions, repro­ducible out­put. The tools here are Pandoc, Lua, and Docker, but the approach works regard­less of stack.

Using JSON Resume schema makes the data portable. Dockerizing the pipeline ensures repro­ducibil­i­ty across plat­forms. Version con­trol enables branch­ing per appli­ca­tion. The right abstrac­tions (YAML con­fig files instead of code) make it usable.

The code

Full source, doc­u­men­ta­tion, and exam­ples: codeberg.org/mjgardner/resume-remixer

Licensed open source. If you’re main­tain­ing mul­ti­ple résumé ver­sions man­u­al­ly, give it a try. Let me know how you adapt it for your own workflow.