Typography, section order and resume language

With the length, file and contact block settled, the rest of the basics are about the inside of the page: how it looks, what order it is in, and how each line is written.

These three look like separate topics, but they serve one reader. Typography lets a skimmer find the structure, order puts the strongest evidence where the skimmer looks first, and the language conventions stop an otherwise good page from feeling amateurish.

Typography, spacing, and margins

Typography is not decoration here. It is what makes a fast skim possible, and the lesson on reading speed showed that the first pass is a fast skim.

Readable defaults

On font choice: any well-made, widely available font is fine. Arguments about serif versus sans-serif are not worth your time. What is worth avoiding is anything decorative, anything condensed, and anything that might not exist on the reader's machine if you send a Word file.

Building hierarchy

A skimming reader needs to see the structure without reading it. Three levels are enough:

1. Section headings — Experience, Education, Skills. Bold, slightly larger, optionally with a thin rule beneath.
2. Role titles and companies — bold, on their own line, with dates aligned right.
3. Bullets — plain body text.

Build the hierarchy from size and weight. Not colour, and not boxes.

Whitespace is doing work

The instinct when a page is too full is to reduce spacing. This is backwards: the space between sections is what lets a skimmer find where things begin.

If you are out of space, cut a bullet rather than the space between two sections. One fewer bullet costs you one weak line. Collapsed spacing costs you the reader's ability to navigate at all.

Order: reverse chronology and sections

A clear hierarchy only helps if the right things sit at the top of it. There are two decisions: the order of jobs within a section, and the order of the sections themselves.

Reverse chronological order

List your most recent role first, then work backwards. This is the expected convention for engineering roles, and readers navigate by it.

You will see advice for a "functional" or "skills-based" resume that groups by capability instead of by job. Avoid it. Recruiters know it is most often used to obscure gaps or a thin history, so it invites the scrutiny it is trying to deflect.

If you have a gap or a career change, address it directly with a line of explanation. That is far more effective than restructuring the whole document around hiding it.

Section order by career stage

The rule: whatever is your strongest evidence goes highest.

Two things move as you gain experience: education slides down, and projects fade out as real work replaces them.

Optional sections, and when to include them

• Summary — only in the specific cases in Summary or objective: when to include one.
• Projects — for students, career switchers, or when a side project is genuinely more impressive than your day job.
• Publications, patents, talks — include when relevant to the role.
• Open source — include when your contributions are substantial and verifiable.
• Certifications — include for cloud and security roles where they are genuinely valued; otherwise they add little.
• Interests — usually not. It rarely helps, and it costs a line.

Language: tense, person, and jargon

The last layer is the writing itself. The conventions are narrow, they are consistent across the industry, and breaking them makes an otherwise good resume feel amateurish.

Tense

• Past roles: past tense. Built, led, reduced, migrated.
• Current role: present tense for ongoing duties, past tense for completed work. Mixing these within one role is normal and correct: Lead a team of four alongside Migrated the billing service to Postgres.

Be consistent inside each role. Inconsistency reads as carelessness.

Person

No pronouns. Not "I", not "we", not "my".

I built a service that reduced latency by 40%. Built a service that cut p99 latency 40%.

Dropping the pronoun is the standard convention and it saves a word on every line.

The "we" version has a second problem: it hides your contribution. A reader cannot tell whether you led the work or attended the meetings. Scope, ownership, and ambiguity covers how to claim your part of a team effort accurately.

Jargon and acronyms

The test: would the recruiter recognise it, and would the engineer respect it?

• Industry-standard terms — Kubernetes, gRPC, CI/CD, p99 latency — are fine. Both readers know them.
• Internal names are not. Migrated Falcon to Meridian means nothing outside your former company. Write Migrated the internal deployment pipeline to a new orchestration platform.
• Expand an acronym on first use unless it is universally known. SLO (service level objective), but not API (application programming interface) — that one is safe.

Words to delete

These add length and subtract credibility: