Checks before you send: evidence audit, peer review and the job-description diff

The drills in the previous lesson improve how the page reads. The three checks here make sure it holds up: that you can defend every claim, that it reads the way you think it reads to someone else, and that it matches the job you are sending it to.

Run the first two once on your master resume. Run the third for every application you care about.

The evidence audit

The exercise that makes your resume defensible in an interview. Do this before you send anything.

The procedure

Make a table. One row per claim on your resume — every number, every technology, every "led", "owned", or "designed".

The three verdicts

Keep. You have evidence and you can discuss it in depth, including what went wrong.

Downgrade. The claim is true but overstated. Rewrite it accurately — Overclaiming, and what it costs has the honest phrasing ladder. Kubernetes becomes deployed services to Kubernetes or comes off the skills line.

Fix or cut. You cannot substantiate it. Either go and find the number now — check old dashboards, tickets, pull requests, or ask a former colleague — or remove the claim.

Where to find evidence you have forgotten

• Old pull requests and their descriptions
• Sprint tickets and their comments
• Incident write-ups and postmortems
• Performance-review self-assessments — often the richest source
• Old dashboards and monitoring, if you still have access
• Slack or email around a launch
• Former colleagues, who often remember numbers you do not

The output

Two things: a cleaner, defensible resume, and a document listing every claim with its evidence. That second document is your interview preparation. When someone asks "how did you measure that?", you have already answered it once.

The peer review protocol

Once you trust every claim, find out how the page reads to someone else. "Can you take a look at my resume?" produces useless feedback. A structured request produces useful feedback from the same person.

Why unstructured review fails

Asked to review generally, most people find typos and comment on formatting. Those are the easiest things to see and the least important things to fix.

They will not tell you your bullets describe duties, because they do not know that is a category of problem.

The script

Send this with your resume:

Thanks for looking. Four specific things, five minutes total:

1. Six seconds only, then close it. What role do I want, how senior am I, and name one thing I did?
2. Now read it properly. Which single bullet is strongest? Which is weakest?
3. Is there anything you'd want to ask me about? If yes, which line?
4. Is there anything that made you doubt something?

Please don't fix my grammar — I want these four answers.

Four questions, each targeting a real failure mode: the six-second test, signal density, interview-question quality, and credibility.

Choosing reviewers

Ask two or three people, ideally different kinds:

• Someone who hires engineers. The most valuable reviewer by a wide margin. Their answer to question 4 is worth more than everything else combined.
• An engineer at your target level. They will spot bullets that under-sell or overstate.
• A non-technical person. Perfect for the six-second test, and they will catch jargon you have stopped noticing.

Interpreting feedback

Not all feedback is equally weighted:

Where two reviewers disagree on a matter of taste, keep your version. Where two reviewers independently misread the same thing, that thing is wrong regardless of your intent.

The job-description diff

The last exercise, run per application. It converts tailoring from guesswork into a checkable procedure.

The procedure

Put a real job description beside your resume and build a table.

Acting on each status

Strong — verify it is visible in the top third. A strong match buried on page two is wasted.

Partial but buried — move it up. Reorder bullets within a role so this one comes first.

Weak — decide honestly. Either downgrade the claim (see Overclaiming, and what it costs) or leave it and be ready to describe your actual level accurately when asked.

Absent but fixable — this is the row that makes the exercise worth doing. You mentored four engineers and never put it on your resume. Add it.

Absent and unfixable — accept it. Nobody meets every requirement, and job descriptions are wish-lists.

The apply-or-not decision

The table also tells you whether to apply.

The most common mistake in a job search is a high volume of applications to roles in the bottom two rows. Twenty applications at three-of-five convert far better than sixty at one-of-five, and take less time.