How long should a resume be? The rule changed, and most engineers missed it

Ask ten people how long a resume should be and you'll get the same answer nine times: one page. It's the most repeated piece of career advice in tech, and in 2026 it is quietly costing good engineers interviews.

Our talent solutions teams — staff augmentation, direct hire, RPO, and MSP/VMS staffing — sit on both sides of that decision every week. We read the resumes. We also sit in the calibration calls where hiring managers at Fortune 500 and high-growth enterprises decide, in about eight seconds, whether a profile moves forward. What we see there does not match the one-page folklore.

The short answer

One page if you have under three years of experience. Two pages once you don't. Three pages only if you're a principal architect, an academic, or someone whose publications and patents are the point.

That's the whole rule. Everything below is why it works, and how to hit it without padding.

The one-page rule is a leftover from a paper era

The one-page convention comes from a time when resumes were printed, stapled, and stacked on a desk. Page two got separated from page one. Recruiters were physically flipping paper.

That world is gone. Resumes are now parsed by an ATS, skimmed on a laptop, and forwarded as PDFs in Slack threads. Scrolling costs nothing. And the market has moved with it: recent surveys of recruiters and HR professionals now show a clear majority favoring two pages over one for candidates with real experience — a near-inversion of the advice most people are still repeating.

The reason is simple. When you compress twelve years of enterprise engineering onto one page, you don't remove fluff. You remove evidence. The Kubernetes migration becomes "cloud experience." The four-year Salesforce–SAP integration becomes a logo and a date range. The hiring manager can no longer tell whether you led it or watched it.

What actually gets cut when you force one page

We've reviewed thousands of profiles for enterprise engagements. The casualties of over-compression are always the same four things — and they are always the four things the hiring manager wanted:

• Scale context. "Built a payments service" versus "Built a payments service processing 40M transactions/month across three regions." One is a task. The other is a qualification.
• Your actual role. Team of four or team of forty? Did you own the architecture or implement a spec? Compression flattens ownership into ambiguity, and ambiguity reads as junior.
• Outcomes. Latency cut, cost saved, incidents reduced, release cadence changed. Numbers are the first thing dropped for space and the first thing a manager looks for.
• The compliance and domain layer. In healthcare, banking, and insurance work, HIPAA, SOC 2, PCI-DSS, and regulatory context aren't decoration — they're often the screening criteria.

If a second page buys those back, take the second page.

But length is a symptom, not the goal

Here's the trap on the other side. The answer is never "longer, therefore better." Recruiters spot padding immediately, and a bloated resume signals something worse than inexperience: poor judgment about what matters.

Two pages of substance beats one page of vagueness. One page of substance beats two pages of filler. Every time.

A useful test before you add a line: would a hiring manager make a different decision because of it? If not, it's taking up space that a real result could occupy.

Things that almost never earn their space in 2026:

• An objective statement describing what you want
• "References available upon request"
• A skills matrix rating yourself 4/5 stars in eight languages
• Every course, badge, and webinar you've ever completed
• Roles older than 15 years, listed with full bullet detail
• Full mailing address, date of birth, marital status, photo (in the North American market, these can actively hurt you)

The allocation that works

Once you've accepted two pages, the question becomes where the space goes. What we consistently see perform well:

• Page one, top third — the only real estate you're guaranteed to get read. Name, title, location and work authorization, and a three-line summary that states what you build, at what scale, in which domain. No adjectives. "Senior backend engineer, 9 years, distributed payment systems in regulated banking environments, AWS + Kubernetes."
• Page one, remainder — your two most recent roles, in depth. Five to seven bullets each, every one shaped as action → technical decision → measurable outcome.
• Page two — earlier roles in decreasing detail, then education, certifications, and anything genuinely differentiating: patents, open-source maintainership, published talks.
• Anything before 2011 — a single "Earlier experience" line. Titles and companies, no bullets.

A word on ATS, and on AI screening

Two mechanical points that override style preferences.

Length itself does not hurt ATS parsing. Formatting does. Multi-column layouts, text inside graphics, headers and footers carrying critical information, and creative section names ("My Journey" instead of "Experience") are what break parsers. A clean, single-column, two-page PDF parses better than a dense one-page design with sidebars.

And as AI-assisted screening becomes standard in enterprise hiring, specificity is compounding in value. Models — like humans — reward concrete, verifiable, well-structured claims and discount generic ones. The resume that says what system, what scale, what result is now advantaged twice over.

The honest version of the rule

So — how long should a resume be? Long enough to prove you can do the job. Short enough to prove you know what matters.

That is a judgment call, and it's the same judgment we look for when we place engineers into enterprise delivery pods: can this person separate signal from noise? A resume is the first artifact where a candidate demonstrates it. Sprawl says no. Over-compression says no. Two well-edited pages that make a hiring manager say "I want to talk to this person" say yes.