The LaTeX Resume Problem: Why Engineers Spend More Time on Formatting Than Content
The origin story of a frustration every engineer knows: fighting compilation errors at midnight instead of writing bullet points that get interviews.
Thejus Sunny
Engineering + hiring perspective
The Ritual Every Engineer Knows
It's Sunday night. You just found a job posting that actually excites you — the stack is right, the team seems great, the company is doing something you care about. The application deadline is tomorrow. You open your resume to update it and... you realize you haven't touched your LaTeX source in eight months.
What follows is a ritual that thousands of software engineers perform every job search cycle. You clone your resume repo (or dig through Overleaf projects named 'resume_final_v3_ACTUAL_FINAL'). You try to compile. It doesn't compile. You spend the next two hours not writing about your accomplishments, but fighting with package versions, margin calculations, and mysterious vertical spacing that appeared out of nowhere.
By the time it compiles cleanly, you're too exhausted to think critically about whether the content actually sells your experience. You submit something 'good enough' and move on. The formatting won, again.
The Time Audit: How Long Engineers Actually Spend on Formatting
We started paying attention to this problem after noticing a pattern in Reddit threads, Hacker News discussions, and conversations with engineering friends. The numbers were staggering — not because anyone tracked them intentionally, but because the frustration was so universal that people couldn't stop talking about it.
I spent an entire Saturday getting my LaTeX resume to compile after upgrading TeX Live. Six hours. I changed maybe two bullet points of actual content.
A recurring thread on r/cscareerquestions asked engineers to estimate time spent on resume formatting versus content. The median answer was eye-opening: for every hour spent improving content, engineers reported spending roughly three to four hours on formatting and layout. Some reported ratios as high as 10:1 during major resume overhauls.
3-4 hours
Average time spent fixing formatting per resume update, based on self-reported estimates from engineering forums
45 minutes
Average time spent on actual content improvements — the words that hiring managers and ATS systems actually read
8+ months
Average gap between resume updates for employed engineers, making each update a painful relearning exercise
These aren't rigorous survey numbers — they're self-reported estimates from people venting online. But the consistency of the frustration across hundreds of threads tells a clear story. Engineers are spending the majority of their resume time on everything except the content that actually matters.
The LaTeX Tax: A Catalog of Familiar Pain
If you've maintained a LaTeX resume, you've paid the LaTeX tax. It comes in many forms, and it compounds every time you need to make a change. Here's a tour of the greatest hits.
The Compilation Error Spiral
You added one line to your experience section. Now the document won't compile. The error message references line 847 of a style file you didn't write. You bisect the problem for twenty minutes and discover a missing brace three sections away from your change.
% You just want to add a new job entry. Simple, right?
\resumeSubheading
{Senior Software Engineer}{Jan 2024 -- Present}
{Acme Corp}{San Francisco, CA}
\resumeItemListStart
\resumeItem{Led migration of monolithic API to microservices,
reducing p99 latency by 40\%} % <-- forgot to escape %
\resumeItem{Mentored 3 junior engineers through promotion cycles}
\resumeItemListEnd
% Output:
! Missing $ inserted.
<inserted text>
$
l.47 ...reducing p99 latency by 40%}
% Cool. Super helpful error message.The Spacing and Margin Rabbit Hole
Your resume is one line too long for a single page. You don't want to cut content — you worked hard on those bullet points. So begins the grand tradition of \vspace micro-adjustments, where you shave fractions of a point off every gap until the document barely fits, and any future edit risks breaking the entire layout.
% The "make it fit on one page" ritual
\usepackage[top=0.4in, bottom=0.3in, left=0.45in, right=0.45in]{geometry}
% Still too long. Time for the vspace hacks.
\vspace{-7pt} % after name
\vspace{-5pt} % before experience
\vspace{-3pt} % between jobs
\vspace{-2pt} % before education
\vspace{-4pt} % after skills
% Three weeks later you add one bullet point.
% Everything overflows. All the vspace values
% need recalibrating. You question your life choices.
% You try \smallskip, \medskip, \vfill.
% Nothing works predictably. You start using
% negative values that feel like dark magic:
\vspace{-0.35\baselineskip} % why does this work?
% nobody knows.Package Conflicts and Font Nightmares
You found a nice resume template on GitHub. It uses fontawesome5 for icons, a custom font package for headings, and hyperref for links. You try to add enumitem for better list control. Suddenly nothing works because two packages are redefining the same internal command, and the error log is 200 lines of inscrutable TeX internals.
\usepackage{fontawesome5}
\usepackage{enumitem}
\usepackage[hidelinks]{hyperref}
\usepackage{fontspec} % wait, now I need XeLaTeX
\usepackage[T1]{fontenc} % conflicts with fontspec
\usepackage{titlesec} % redefines \section
\usepackage{multicol}
% Compilation output:
! LaTeX Error: Option clash for package fontenc.
! Package fontspec Error: The fontspec package requires
! either XeTeX or LuaTeX.
%
% You switch to XeLaTeX. Now fontawesome5 breaks.
% You switch to LuaLaTeX. Now your build takes 14 seconds.
% You go back to pdfLaTeX. Now your custom font doesn't load.
%
% It's 1 AM. You still haven't updated your job title.I'm a staff engineer at a FAANG company. I build distributed systems that handle millions of requests per second. I cannot, for the life of me, get my LaTeX resume to stop putting an extra 3pt of space before my education section.
The Overleaf Dependency
Many engineers moved to Overleaf to escape local TeX installation hell, and for good reason — it handles compilation, packages, and collaboration in the browser. But this created a new kind of dependency.
When Overleaf changed their pricing model and restricted free-tier compile times, a wave of panic swept through engineering communities. Suddenly, the tool people relied on for their professional livelihood had a paywall between them and their own resume. Engineers who had years of resume history in Overleaf had to decide: pay up, export and set up a local TeX environment (back to square one), or find an alternative.
- Free-tier compile timeouts mean your complex resume template might not build without a paid plan
- Overleaf outages during peak job-search season (January and September) leave you unable to update your resume when it matters most
- Your resume source is locked inside a proprietary platform — exporting means rebuilding your local toolchain
- Collaboration features you don't need for a single-page resume are subsidizing the infrastructure you depend on
The core issue isn't that Overleaf is bad — it's a great tool for academic papers. The issue is that a single-page resume shouldn't require a full typesetting platform with cloud compilation infrastructure. We've normalized an absurd amount of complexity for what is fundamentally a simple document.
The ATS Problem Nobody Talks About
Here's the part that stings the most. After all that time perfecting your LaTeX resume's visual layout — the precise spacing, the custom fonts, the carefully aligned columns — there's a very real chance the ATS (Applicant Tracking System) at the company you're applying to can't read it properly.
LaTeX generates PDFs through a fundamentally different process than tools like Word or HTML-to-PDF converters. The text in a LaTeX PDF is often fragmented, reordered, or embedded in ways that confuse automated text extraction. Custom fonts may not include proper Unicode mappings. Multi-column layouts get linearized in unpredictable ways. Ligatures can turn 'fi' into an unrecognizable glyph.
A Common ATS Failure Mode
- You write: 'Proficient in Python, JavaScript, and TypeScript'
- ATS extracts: 'Pro cient in Python, JavaScr ipt, and TypeScr ipt'
- The keyword matching algorithm doesn't find 'JavaScript' in your resume. Your application is filtered out before a human ever sees it.
This isn't hypothetical. Engineers have reported applying to dozens of companies, getting no responses, and then discovering through ATS score-checking tools that their beautifully typeset LaTeX resume was being parsed as garbled text. The irony is brutal: the tool chosen to make the resume look professional is actively hurting its chances of being read.
I switched from my custom LaTeX resume to a plain Google Docs template and my response rate tripled. Three years of tweaking that LaTeX template and it was literally working against me the entire time.
The Real Cost: Formatting vs. Content
Let's be honest about what actually gets you interviews. It's not your margin widths. It's not your font choice. It's not the pixel-perfect alignment of your dates. It's the content — the way you describe your impact, quantify your contributions, and present your experience as a coherent narrative.
Every hour you spend debugging a LaTeX compilation error is an hour you didn't spend researching the company you're applying to, tailoring your bullet points to the job description, or quantifying the impact of your last project. The opportunity cost is enormous and invisible, because the formatting work feels productive — you can see the output changing on screen.
What Engineers Spend Time On
Fixing compilation errors, adjusting spacing, resolving package conflicts, making content fit on one page, choosing fonts, aligning columns, tweaking margins
What Actually Gets Interviews
Quantified impact statements, relevant keywords for ATS matching, clear job progression narrative, tailored content per application, strong action verbs, concise descriptions of technical decisions
The formatting trap is particularly insidious for engineers because we're problem-solvers by nature. A LaTeX error is a puzzle, and puzzles are satisfying to solve. But optimizing your \vspace values is a local maximum. The global maximum is spending that time on content strategy — and that requires stepping away from the typesetting entirely.
What a Modern Resume Workflow Should Look Like
If we designed a resume workflow from first principles — knowing what we know about ATS systems, hiring processes, and how engineers actually work — it would look nothing like the LaTeX workflow. Here's what we think the bar should be:
- Formatting should be a solved problem. You pick a template, your content fills it, and it looks professional. No compilation, no spacing hacks, no package conflicts. Done.
- ATS compatibility should be guaranteed, not hoped for. The output format should be engineered for machine readability from the start, not reverse-engineered from a typesetting system designed for academic papers.
- Your time should go to content, not layout. The tool should actively help you improve what you're saying — flagging weak bullet points, missing quantification, or content that won't survive ATS keyword matching.
- Updates should be instant. You should be able to add a new role, tweak a bullet point, and have a ready-to-submit PDF in under five minutes — not two hours.
- Your resume should be portable. No vendor lock-in, no cloud dependency for compilation. Your content is yours.
This isn't a radical vision. It's what every other professional document workflow already looks like. Resumes are the strange exception where we've accepted a level of friction that would be laughed out of any other software domain.
Why We Built Rejectless
Rejectless started because we were the engineers in those Reddit threads. We'd spent years maintaining LaTeX resumes, debugging compilation errors at midnight before application deadlines, and wondering why the resume workflow for the people who literally build software was so fundamentally broken.
The breaking point came during a job search where one of us realized they'd spent an entire weekend — not writing better content, not preparing for interviews — but migrating a resume from one LaTeX template to another because the original used a deprecated package. The new template looked almost identical. Two days, zero improvement to the actual content.
Rejectless Eliminates the Formatting Tax
We built Rejectless so you never fight with LaTeX again. Your resume renders perfectly every time — clean, ATS-compatible, professionally formatted. No compilation errors, no spacing hacks, no package conflicts. You focus entirely on what you're saying, and our ATS lint engine tells you exactly how to say it better. The formatting is solved. Your content is what matters.
We didn't build another generic resume builder. We built a tool specifically for software engineers who are tired of the LaTeX tax. The resume builder handles layout so you don't have to. The ATS lint tool analyzes your content the way an applicant tracking system would — flagging parsing issues, weak phrasing, and missing keywords before you submit. It's the workflow we wished existed every time we opened a .tex file at midnight.
LaTeX is a remarkable piece of software. It's the right tool for typesetting academic papers, books, and mathematical documents. But a one-page resume for a software engineering job application? That deserves a tool built for purpose — one that respects your time and actually helps you land interviews.
Your Resume Deserves Better Than a Typesetting System
The next time you find yourself adjusting \vspace values at midnight, ask yourself: is this making my resume more likely to get me an interview? Or am I just solving a puzzle that shouldn't exist? Your time is worth more than debugging compilation errors. Spend it on the content that actually opens doors.