These are the checks I ran on my own resume this month, written down so they are easy to reuse. It is for data engineers and analytics engineers, but most of it carries to any engineering role.
Each section ends with the check itself. The full checklist is at the bottom.
1. Pass the six-second read first#
The first reader is skimming. In TheLadders' 2012 eye-tracking study, recruiters spent about six seconds on the first pass, and about 80% of that time went to six fields: your name, current title and company, previous title and company, dates, and education (TheLadders). It was a small study (thirty recruiters) by a company that sells resume rewrites, so do not build a religion on the exact number. The point stands: the top third of page one decides whether anyone reads the rest.
That has three consequences.
- Use your title on record. If HR has you as "Data Engineer", write that. A creative title ("Technical Staff, Analytics") makes the skimmer guess your level, and they will guess low.
- Keep company names and dates easy to find. Left-aligned or right-aligned, but always in the same place.
- Put the strongest bullet first in each role. Many readers stop after one or two.
Check: Cover everything below the top third. Can a stranger still say what you do, at what level, and where?
2. Write bullets as X-Y-Z#
Laszlo Bock, then head of people operations at Google, gave the most useful bullet formula I know: "Accomplished [X] as measured by [Y] by doing [Z]" (Bock, 2014). His gloss is the part people skip: start with an active verb, measure what you accomplished, give a baseline for comparison, and say what you did.
The baseline is what makes a number mean anything. "Cut runtime 40%" is a claim. A made-up example of the full shape: "Cut nightly runtime 40% (5 h to 3 h) by moving the joins into incremental dbt models". That is a claim with a lineage.
For data engineering, these are good measures:
| What you changed | Measure it as |
|---|---|
| Reliability | time-to-detect, time-to-recover, failed runs per month |
| Cost | compute spend, cluster hours, storage |
| Speed | runtime, data freshness, query latency at a stated percentile |
| Adoption | teams or engineers onboarded, models migrated |
| Toil | hours of manual work removed, pages per week |
Check: Every number has a baseline, a window, or both.
3. Show scope, not a tool list#
The most common problem I see is a resume that reads as a list of tools. "Built pipelines with Airflow, Spark, dbt, Kafka and Snowflake" tells me what you touched. It does not tell me what you were trusted with.
Senior roles are defined by scope and ownership. Dropbox's public career framework says level expectations "define the scope, collaborative reach, and levers for impact at every level" (Dropbox), and its 2023 update asks for "ownership over code, processes, and operational systems" (Dropbox, 2023). None of that is visible in a tool list.
The fix is in the verb and in one clause of context:
- Own / run / am on call for says the system answers to you.
- Set the standard and enforced it in CI says you had the authority to block a merge.
- Drove adoption across N engineers says you got other people to change how they work.
Put the tools in a skills section. In bullets, name a tool only when it carries meaning, and let the rest of the bullet say what you were responsible for.
Check: At least a third of your bullets say what you owned, decided or got others to adopt.
4. One claim per number, and only yours#
Two rules here.
Do not repeat a number. If "cut review cycles 20%" appears under two employers, a reader assumes both are estimates. Vary them or give each its own baseline.
Only claim the part you owned. The most dangerous bullet on a resume is a real, impressive number for a system you worked in, written as if the whole of it was yours. It is the bullet an interviewer will pick, and the answer ("well, the platform did that") ends the conversation. I wrote about finding two of these on my own resume in Every number on my resume has to survive one follow-up question.
When you cannot share a figure, do not invent a softer one. Google's interns put it well: "use metrics and tangible facts (but respect confidentiality)", and "a safe bet is to use percentages rather than absolute numbers" (Google Students blog, 2015). A bullet with no number is better than a bullet with a made-up one.
Check: For each number, can you say in one sentence how it was measured and what part was yours?
5. Name the ordinary mechanism#
"Improved query performance using advanced optimisation techniques" sounds bigger than "cut p95 latency by redesigning partitions and Z-ordering the largest tables". It is weaker. The second one names a mechanism the interviewer can ask about, and you can answer every question.
Use the field's own words where they are accurate: idempotent, exactly-once, backfill, SLO, RPO and RTO, data contract, lineage, reconciliation. Each one tells a technical reader that you have dealt with the problem it names. Do not use one you cannot explain for five minutes.
Check: Every technical term on the page is one you can defend under questions.
6. Do not write for a robot that does not exist#
You have probably heard that "75% of resumes are rejected by an ATS before a human sees them". I have never found a study behind it. The most careful trace I have read follows it back to a 2012 sales pitch from a resume-optimisation company that published no method (The Interview Guys), and I treat it as a myth.
What an applicant tracking system does is store applications and apply filters that people set: knockout questions, required fields, sometimes keyword searches. That is a reason to keep the document easy to parse. It is not a reason to stuff it with keywords.
- One column, real text (not text in images), standard section headings.
- Your skills section uses the names in the job posting where they are true: "dbt", not only "SQL transformation framework".
- Export a PDF and copy-paste all of it into a plain text editor. If the order is garbled there, it is garbled for the parser.
Check: The PDF's text pastes cleanly, in reading order.
7. Change vocabulary per audience, never the facts#
The same work reads differently to different teams. A fintech platform team listens for reconciliation, idempotency and audit trails. A platform team at a large company listens for adoption, migration, on-call and blast radius. An ML team listens for training-data pipelines, freshness and evaluation.
Keep one master resume with every fact you can defend, then make a variant per audience that leads with the most relevant work and uses that audience's words. The facts in every variant are a subset of the master. Nothing new appears in a variant that is not in the master.
Check: Every variant is a subset of the master, reworded, with nothing added.
The checklist#
- Title, company and dates are on record and easy to find in the top third.
- The strongest bullet is first in each role.
- Bullets follow X-Y-Z, and every number has a baseline or a window.
- At least a third of bullets show ownership, a decision, or adoption.
- Tools live in the skills section, not in every bullet.
- No number appears twice, and each one is yours.
- Confidential figures are left out or given as percentages, never invented.
- Every technical term is one you can defend for five minutes.
- The PDF's text pastes cleanly, in reading order.
- Each variant is a reworded subset of the master resume.
If you want to see these checks applied, my own resume is the result of running them on myself.