Drills for the page: the six-second test, bullet rewrites and "so what?"

Reading about resumes does not improve one. This section is six exercises, each with an output you can check, and together they are where your draft actually gets better.

This lesson has the three drills that work on the page itself: a fast diagnostic of the top third, a calibration drill for bullets, and a mechanical pass that finds the bullets which look fine and say nothing. The next lesson has the three checks you run before you send it.

The six-second test

The fastest and most brutal diagnostic in the course. Run it before anything else.

The protocol

1. Print your resume, or open it full-screen.
2. Hand it to someone — anyone, technical or not — face down.
3. Say: "I'm going to turn this over for six seconds. Then I'll ask you three questions."
4. Turn it over. Count six seconds. Take it away.
5. Ask the three questions below.

The three questions:

• What role does this person want?
• How senior are they?
• Name one thing they did.

Reading the result

The third question is the one most resumes fail. People remember a role and a company, and nothing about what the person actually did.

Why six seconds

It is deliberately unfair. The lesson on reading speed was honest that the exact figure is indicative rather than precise — real first passes may be somewhat longer.

But testing at six seconds gives you margin. A resume that survives six seconds definitely survives ten. A resume that needs fifteen is at the mercy of a reader having a patient day.

Running it without a person

If nobody is available: open your resume, look away, then look back for a count of six and close it immediately. Write down what you remember.

Weaker than a real reader, because you know what is there. Still catches a buried headline.

The bullet rewrite drill

If your top third passes, the next weakness is almost always the bullets. This drill is calibration practice. Rewrite these ten bullets before reading the model answers, then compare.

The drill

For each bullet, apply the impact-first structure: what changed, by doing what, which mattered because. Invent plausible specifics where the original gives you nothing — the point is the shape, not the facts.

1. Responsible for maintaining the user authentication service.
2. Worked with the product team to deliver new features on schedule.
3. Improved application performance.
4. Migrated the database.
5. Wrote unit tests to improve code coverage.
6. Participated in on-call rotation.
7. Helped onboard new team members.
8. Used Docker and Kubernetes for deployment.
9. Fixed critical bugs in production.
10. Led the frontend redesign project.

Write all ten before continuing.

Model answers

1. Cut auth service p99 from 300 ms to 45 ms by replacing per-request database lookups with a signed-token check, removing the login timeouts that were affecting ~1% of sign-ins.

2. Shipped the saved-carts feature in six weeks against an eight-week estimate by cutting the two lowest-value requirements after walking the product team through the cost of each.

3. Cut homepage time-to-interactive from 4.1 s to 1.3 s by deferring three non-essential scripts and lazy-loading below-the-fold images. → "Improved performance" is a category, not a claim. Name the metric, the numbers, and the change.

4. Migrated 400 GB and 60 services from MySQL to Postgres over three months with no downtime, using dual-writes and a read-shadow period to verify parity before cutover. → The interesting part of any migration is how you avoided breaking things.

5. Raised coverage on the billing module from 34% to 81%, catching a rounding error in proration that had been mis-charging annual upgrades. → Coverage is an input. The bug you found is the outcome.

6. Cut inventory service pages from ~12 to 2 per month by fixing three sources of unbounded queue growth found during on-call. → Being on call is not an achievement. What you changed because of it is.

7. Wrote the backend onboarding guide and ran the first-week pairing sessions; new engineers' first merged PR moved from ~9 days to ~3.

8. Containerised 12 services and moved them to Kubernetes, taking deploys from a manual 40-minute process to a 4-minute pipeline run. → Naming a tool is not an achievement. What the tool let you do is.

9. Traced intermittent checkout failures to connection-pool exhaustion under burst traffic; fixed the pool sizing and added a saturation alert, ending a recurring incident that had been open for five months.

10. Led a four-person frontend redesign that cut the signup drop-off rate from 38% to 22%; sequenced it as six incremental releases so we could measure each change. → For a lead role, add how you organised it, not just what shipped.

What to notice

Across all ten:

• The metric is named, not implied.
• The method appears, so an engineer can tell what you actually did.
• The consequence is stated where one exists.
• Nothing gets longer than about two lines.

Compare your ten against the models. The gap you find is the gap across your whole resume.

The "so what?" pass

The rewrite drill trains the shape. This pass applies it to your own page. It is a short, mechanical exercise that finds the bullets which look fine and say nothing.

The procedure

Go through your resume one bullet at a time. After each, ask "so what?" — and keep asking until you reach something a business or a user would care about, or until you run out of answers.

Worked example:

Migrated the deployment pipeline to GitHub Actions.

So what? — Deploys became faster.

So what? — 40 minutes to 4 minutes.

So what? — The team could deploy several times a day instead of once.

So what? — Fixes reached users the same day instead of the next.

The chain terminated at something real. That is your bullet:

Cut deploy time from 40 minutes to 4 by moving the pipeline to GitHub Actions, taking the team from one release a day to several and same-day fixes for users.

When the chain does not terminate

Refactored the utilities module.

So what? — The code was cleaner.

So what? — It was easier to read.

So what? — …

There is no third answer. Two possibilities:

1. The work had value you have not identified. Did it make a later feature possible? Did it remove a class of bug? Did it cut build time? Look harder before deleting.
2. The work genuinely does not belong on your resume. Real work, correctly done, that changed nothing a reader would care about. Cut it.

Both outcomes are useful.

Running it efficiently

Do the whole resume in one sitting, marking each bullet:

• T — terminated in a real outcome. Rewrite to lead with that outcome.
• P — partially terminated. There is an outcome but it is weak. Keep, low priority.
• X — no termination. Cut, or find the outcome you have missed.

A typical first pass on an unedited resume produces two or three X marks. Cutting those is usually the single biggest improvement available.