Late last year, a senior engineer in our network had been sending out a resume for six months and getting roughly nothing back. Zero frontier-lab callbacks. Three from frontier-adjacent companies. None from anywhere she actually wanted to be. Her work was strong; her resume was not. After one focused rewrite session, the same person sent essentially the same set of applications to essentially the same set of labs. She got 11 callbacks in three weeks. Same engineer. Same shipped work. Different first eight lines.
The diff is below — names changed, scope intact, anchored to a real cohort of one. Then the three structural shifts that did the work. If you take one thing away, take the framing that a frontier-lab reader spends about 12 seconds on the top of your resume before deciding whether to keep reading. The job of the first eight lines is to make those 12 seconds easy to spend.
You’re meant to look at this and think: of course. The right side is not cleverer than the left side. It is not more impressive. It is just legible.The reader on the left side has to assemble Jane’s identity from raw materials — “ML projects using PyTorch” is data, not a story. The reader on the right side knows after eight lines that Jane ships reward models, that one of them got measurable lift on a frontier-lab eval, that the harness behind it is open-source and someone other than Jane likes it, and that she has the stack to back it up. Twelve seconds. Done.
Three structural shifts did most of that work.
// Shift 01From titles to artifacts.
Lead with the work that shipped, not the role that paid for it.
The “before” leads with a title (“Senior Software Engineer”) and a generic summary. The “after” leads with three specific artifacts — a 7B reward model, an open-source eval harness, a proposal that consolidated two teams. Titles are negotiable; artifacts are not.Frontier-lab readers know that a “Senior Software Engineer” at one company is a “Staff Engineer” at another and an “MTS” at a third. The title carries almost no signal across companies. The artifact carries it cleanly.
The mechanical version of this shift: replace your “Summary” section with a “Recent shipped” section, and put three of your strongest concrete deliverables there. If you can’t fill that section with three things you’d be proud to defend in a panel, you have a different problem — and rewriting the resume is the wrong first move.
// Shift 02Verb-result-number, every bullet.
Every bullet should lead with a verb and end with a measurable result.
“Built scalable systems handling millions of requests” is structurally weak. It leads with a passive verb, contains no specific scale number, and ends without a result. The “after” version of the same bullet — “Built the eval harness behind 4 RLHF releases; regression detection days →90 min” — leads with the verb (built), names the scope (4 RLHF releases), and ends with a measurable result (days → 90 minutes).
The hard part isn’t the format. The hard part is that most engineers don’t actually know the numbers behind their work. Spend an evening before you rewrite, with your work log open, and recover the numbers. What did this thing measure before you touched it? What does it measure now? What scale did it run at? How many seconds, minutes, dollars, regressions did your change displace? If the number genuinely doesn’t exist, name the qualitative result with precision — “consolidated reward design across two teams” — but don’t fall back on adjectives like “significantly,” “drastically,” or “meaningfully.” Those are tell-tales for engineers who didn’t have a number.
// Shift 03Skills as proof, not declaration.
The skills section should name only the tools you used in the bullets above it.
The “before” lists 18 technologies, including some — Docker, K8s, GraphQL, MongoDB — that have nothing to do with the kind of frontier-lab work Jane was applying for. The “after” lists five: PyTorch, FSDP, vLLM, TRL, DPO. Each of those appears in or is necessary to the artifacts named above. The skills section is no longer a declaration; it is evidence supporting the claims above.
This is the shift most engineers resist hardest. The instinct is that more skills equals more options — if you include MongoDB, maybe a backend role somewhere will see it and call. That is empirically false at the senior IC frontier-lab level. The 18-skill list signals breadth-without-depth; the five-skill list signals “this is the engineer who works in this stack.” Panels read the five-skill list as confidence. They read the 18-skill list as the candidate’s anxiety.
// 04What we kept the same.
It’s worth being explicit about what didn’t change. We didn’t add personality. We didn’t add a creative section. We didn’t try to make Jane sound exciting. Frontier-lab readers do not want exciting. They want legible. The engineers who try to differentiate by being more interesting on the page almost always end up looking less serious; the engineers who differentiate by being more specific almost always end up looking more so.
We also didn’t touch the rest of the resume. Past roles, education, projects, publications — all unchanged from the before-version. The 11 callbacks came from the first eight lines. The rest of the document is read by the panel after the lab has already decided to talk to you, and it is graded on a much more forgiving rubric. If your first eight lines aren’t working, fixing the next eighty doesn’t help.
// 05If you’re rewriting yours this weekend.
Three steps. (1) Open your current resume next to a blank page. (2) On the blank page, write the three strongest shipped artifacts of your last 18 months — verb-led, with numbers — and the five-tool stack that touches them. (3) That’s the top of your new resume. The rest is the existing document with the bullets reformatted to the verb-result-number pattern.
If you’re a network member, Resume AI handles much of this mechanically — most importantly, it scans your connected GitHub and project notes to recover the numbers you’ve forgotten. The diff above is the kind of output it produces. The structural shifts are the same whether you do it by hand or with the tool.
Next week’s piece will be on the 2026 post-training canon — the twelve papers we hand to engineers ramping into a post-training role at a frontier lab, in order, with what to actually take from each. Subscribe at the bottom of the blog page if you want it.
// Read next
Resume AI
The resume rewriter that produces the diff above. Network-calibrated, tailored per match.
READ →// SCREENINGFour mistakes engineers make on the 13-day project
Structurally similar — most of the failure is in scope and write-up, not execution.
READ →// SCREENINGThe one question we ask every senior IC panel
What happens after the resume gets the callback. The Stage-04 question that locks the offer in.
READ →Send the version that gets callbacks.
Resume AI rewrites yours the way frontier labs actually read them. Free for OpenTalent network members.