How to Write a Good Resume

Course Content

How to Write a Good Resume

15 sections · 30 lessons

Impact-first bullets and honest numbers

This is the most important technique in the course. Almost every resume improvement is some version of it.

The previous lesson gave each role its frame. This one fills the frame with bullets that a reader can care about. The first half is the structure of a strong bullet; the second half is the numbers that make it concrete, and the line between an honest estimate and an invented one.

The impact-first bullet

The problem with how most bullets are written

Most bullets describe activity:

• Responsible for maintaining and improving the payment integration service.

• Worked with the frontend team to implement the new checkout flow.

• Participated in code reviews and technical design discussions.

Every one is true. None tells the reader anything that distinguishes this engineer from anyone else holding the same job. They describe the job description, not the person.

The structure that fixes it

A strong bullet has three parts:

What changed — by doing what — which mattered because.

The order is deliberate. The outcome comes first, because the reader is skimming and the first few words of each bullet may be all they get.

Weak:

• Implemented a caching layer using Redis for the product catalogue API.

Better:

• Cut product catalogue API response time from 1.2 s to 90 ms by adding a Redis cache with event-driven invalidation.

Best:

• Cut product catalogue API response time from 1.2 s to 90 ms by adding a Redis cache with event-driven invalidation, removing the timeout errors that were costing ~3% of checkout sessions.

Each version is the same work. The third makes it possible for the reader to care.

WeakImplemented a new caching layer for the product cataloguestarts with activity — the reader learns nothing in the first three wordsStrongCut catalogue page load from 1.4 s to 380 msoutcomeby adding a read-through Redis cachemethodwhich held through Diwali peak trafficwhy it matteredSame work. The strong version answers "what changed", "how", and "why anyone cared" — in that order.
The first three words decide whether the rest of the bullet gets read.

The reordering drill

Take any activity bullet and ask three questions in order:

  1. What changed because of this? That becomes the opening.
  2. How did I do it? That becomes the middle. Keep it specific enough to be technical, short enough not to dominate.
  3. Why did anyone care? That becomes the end — the user, business, or team consequence.

If question 1 has no answer, the work may not belong on your resume. If question 3 has no answer, the work was probably real but the bullet will stay weak.

How much technical detail

Enough that an engineer can tell what you actually did. Not so much that it becomes a design document.

Used Redis. — too vague; says nothing about the work

Implemented a write-through Redis cache with a 15-minute TTL, cache-aside fallback, and Kafka-driven invalidation on catalogue update events, sharded across 3 nodes. — this is a paragraph wearing a bullet's clothes

Added a Redis cache with event-driven invalidation. — right

The detail you leave out is what you talk about in the interview. That is the correct place for it.

Quantification without fabrication

The "what changed" at the front of a bullet is strongest as a number. "Add numbers" is the most common resume advice there is. It is correct, and it is also where people either freeze or start inventing.

Where an honest number comes fromName thething changedFind thebefore and afterCheck whatyou can defendState it as arough figure"Roughly 40 percent" is honest; an invented 47 percent is not.
When no number exists, describe scope and consequence instead — a vague number you cannot defend is worse than none.

Where honest numbers come from

Most engineers think they have no numbers. They usually have several, in categories they have not thought to look in.

CategoryExamples
ScaleRequests per day, users served, rows processed, data volume, number of services
PerformanceLatency before and after, throughput, error rate, uptime
TimeHow long a thing used to take against how long it takes now; delivery timeline
CostInfrastructure spend, licence savings, engineer-hours saved
QualityIncidents per quarter, bug counts, test coverage, deployment frequency
TeamPeople led or mentored, teams coordinated, size of on-call rotation
AdoptionTeams using your tool, percentage migrated, internal users

Look through these categories against each project. Most people find two or three numbers per role they had forgotten were available.

What to do when you genuinely cannot get a number

Three honest options.

1. Express magnitude rather than precision. If exact figures are confidential:

• Reduced nightly batch runtime by roughly two-thirds, taking it out of the business-hours window.

2. Quantify the input instead of the output. If you cannot measure the result, measure the thing:

• Migrated 40 services off the deprecated auth library ahead of its end-of-support date.

3. Say what became possible. Sometimes the honest outcome is qualitative:

• Rebuilt the deploy pipeline so releases moved from fortnightly to daily.

All three are stronger than an invented percentage.

The rough-figure convention

You are allowed to round and estimate, as long as you signal it and can justify it.

• Cut cloud spend by ~$8k/month by rightsizing over-provisioned instances.

The tilde signals an estimate. If asked, you should be able to say where it came from — "the billing dashboard showed the instance line dropping from about $22k to about $14k after the change."

That is a defensible answer. "I don't know, it felt like a lot" is not.