The Overengineered Resume with Zola, JSON Resume, Weasyprint, and Nix (2023)

Original Article ↗ Hacker News Discussion ↗

An experiment in generating a résumé via a complex toolchain (JSON-based data, static site generators, PDF renderers, Nix, CI/CD) has prompted debate over whether such “overengineering” is worthwhile or simply a fun learning exercise. Many commenters argue that résumé content and clarity matter far more than elaborate pipelines or visual flourishes, criticizing the showcased PDF as underwhelming and poorly laid out. Others share alternative approaches—from LaTeX, Typst, and HTML/CSS-to-PDF to JSON Resume and centralized CV platforms—and note practical constraints like ATS parsers, recruiter workflows, and the need to tailor résumés for each application.

Overall reaction to the “overengineered” resume

  • Many readers like the idea of automating a resume and separating data from presentation; several call this a classic engineering “rite of passage.”
  • However, multiple comments say that in this case the end product looks bad: visually underwhelming, cluttered, poor spacing, odd bullets, misaligned dates, and layout glitches (e.g., contact line wrapping).
  • Several note UX issues in the blog itself (e.g., the final PDF being easy to miss under “The Result”).
  • Some argue that despite flaws, getting the resume and project on the HN front page is itself effective self-promotion.

Design, readability, and what matters in a resume

  • Many insist content > aesthetics; a plain, black‑and‑white PDF from Word/LibreOffice/Google Docs is seen as sufficient and often preferable.
  • Others value good typography and layout, but still say the showcased resume fails on both attractiveness and readability.
  • There’s broad skepticism toward highly stylized or multi-page resumes, especially for candidates with modest experience.
  • Academic CVs are mentioned as an extreme of very plain, list-like layouts.

Automation, tooling, and workflows

  • A wide range of stacks are discussed: LaTeX, Typst, HTML+CSS + browser/Chrome-to-PDF, JSON Resume, Markdown → HTML/PDF via pandoc or similar, Quarto, Zola, React/Next.js, Dhall → JSON/LaTeX, Nix-based builds, GitHub Actions/CI pipelines, and mobile-based termux + jinja2 setups.
  • Some praise reproducibility, versioning, templating, and “data in JSON/YAML, layout in templates.”
  • Others report that strict data/presentation separation breaks down as soon as content length changes and layout must be hand-tuned.
  • Several note that heavy pipelines become so complex they discourage future edits.

Standardization and ATS / parsing concerns

  • Multiple people wish for a universal standard; cited examples include JSON Resume, MAC schema, EU Europass, Brazil’s Lattes, and LinkedIn as de facto profiles.
  • Frustration is common with ATS parsing: systems misread PDFs, force manual correction, or hard-filter on years of experience.
  • Some say ATS prefer .docx and even reject PDFs; others argue ATS impact is overstated and humans still read the original file.
  • A few explicitly test their PDFs against common ATS, or add hidden/structured text for keyword scanning.

Job search strategy and customization

  • Several commenters tailor resumes per job, shifting emphasis (e.g., frontend vs data focus) while keeping facts constant.
  • Career coaching, keyword tools, and LLM-based resume customizers are mentioned as practical aids.
  • There’s discussion of recruiters applying rigid heuristics (e.g., strict years-of-experience cutoffs), often misaligned with hiring managers’ priorities.