XYZ Method Resume Guide: Google's Formula With Examples
The resume format Laszlo Bock described while running People Operations at Google: Accomplished [X] as measured by [Y] by doing [Z]. Template, rewrites and 30+ software engineering examples.
Reviewed by Markus Fink
Senior Technical Recruiter · Formerly Google & Airbnb
What You'll Learn
What is the XYZ method on a resume?
The XYZ method is a way to write resume bullet points so each one states a result, proves it with a number, and says how you got it. Google's former SVP of People Operations, Laszlo Bock, laid it out in a 2014 LinkedIn post called "My Personal Formula for a Winning Resume", which is why people also call it the Google XYZ formula. His wording:
Accomplished [X] as measured by [Y] by doing [Z]
- X, the accomplishment: what got better. Faster checkout, fewer incidents, a feature customers paid for.
- Y, the measurement: the number that proves it, ideally with a baseline. "From 780ms to 410ms" says more than "by 47%".
- Z, the method: what you built, changed or decided. For engineers this is where the stack and the technical call go.
Bock's own advice was to start with an active verb, measure the result numerically, give a baseline for comparison, and explain what you did. In his example, a 12% portfolio gain became far more convincing once he added the dollar figure ($1.2M), because it answers the reviewer's next question: is 12% a lot?
One thing that trips people up: the "XYZ resume format" describes how you write bullet points. It says nothing about page layout. You can use it in any clean, single-column resume, such as an ATS-friendly template or Jake's resume.
XYZ resume format template
Here are fill-in versions of the XYZ template. Copy one, then fill in the brackets with your own work.
Strict order
[Verb] [what improved] from [A] to [B] by [what you built or changed] using [tools].
Scale first
[Handled / Served / Processed] [volume] at [quality metric] by [design decision].
Business impact first
[Saved / Recovered / Grew] [$ or %] [per period] by [technical change] in [system].
One bullet, broken down
Cut checkout API p95 latency from 780ms to 410ms by adding compound PostgreSQL indexes and removing N+1 queries in the order service.
Blue is X, green is Y, purple is Z. The order moved (X and Y up front, Z last) and the words "as measured by" are gone. That is normal.
How to write one in four steps
- Start from the outcome. Ask what was different after your work shipped. If the honest answer is "nothing measurable", the bullet may be a task, and it might belong lower or nowhere.
- Pick one number and a baseline. Latency, error rate, cost, build time, users, revenue, hours saved. Before and after beats a bare percentage.
- Write Z as the specific thing you did. Name the technique and the tool: "replaced polling with webhooks", "added a Redis read-through cache". Skip "used best practices".
- Cut to one or two lines. Drop "successfully", "various" and "in order to". Keep the verb, the number and the method.
You do not have to keep the literal X, then Y, then Z order. Lead with whichever part is most impressive. What matters is that all three are there.
Before and after: duties rewritten as XYZ bullets
Most weak bullets read like a copy of the job description. These rewrites show the same work turned into XYZ bullets. The numbers are examples; use your own.
| Before (a duty) | After (XYZ) |
|---|---|
| Worked on the search service. | Cut search p95 latency from 1.2s to 380ms by precomputing ranking signals into an Elasticsearch field and caching popular queries in Redis. |
| Responsible for CI/CD pipelines. | Cut median CI time from 22 to 8 minutes for a 40-engineer monorepo by adding Bazel remote caching and sharding tests across 6 runners. |
| Helped migrate services to Kubernetes. | Moved 14 of 31 services from EC2 to EKS with no customer-facing downtime by writing the shared Helm chart and the blue-green cutover runbook the team reused. |
| Built features in React. | Raised free-to-paid conversion from 2.1% to 2.6% by shipping a usage-based upgrade prompt in React, A/B tested on 50K accounts. |
| Fixed bugs and handled on-call. | Reduced pages per on-call week from 19 to 6 by deleting 40 noisy alerts and replacing them with SLO burn-rate alerts in Datadog. |
| Wrote data pipelines with Airflow. | Had daily revenue reports ready by 6 a.m. instead of noon by rewriting 12 Airflow DAGs as incremental dbt models on Snowflake. |
| Mentored junior engineers. | Got 3 new-grad hires onto the on-call rotation within 10 weeks by running weekly incident drills and pairing on their first production changes. |
| Interned on the payments team. | Shipped refund webhooks used by 300+ merchants in their first month by building the Python event handler with retries and signature verification. |
Notice the Kubernetes one. It says "14 of 31 services" and names the piece you owned. That is how you write about team projects without claiming the whole thing.
30+ XYZ resume examples for software engineers
Treat these XYZ resume examples as patterns to adapt. Swap in your own metrics and stack, and keep only what you could explain in an interview.
Backend engineering
- Cut checkout API p95 latency from 780ms to 410ms by adding compound PostgreSQL indexes and removing N+1 queries.
- Reduced payment-related support tickets by 31% by implementing idempotency keys, structured retry handling, and clearer failure states.
- Supported a 4x traffic increase without additional instances by introducing request coalescing and Redis caching for read-heavy endpoints.
Frontend and full-stack
- Improved checkout conversion by 8.6% by reducing JavaScript bundle size 42% and moving noncritical scripts off the initial render path.
- Cut median page load time from 3.1s to 1.8s by adding route-level code splitting, responsive images, and server-rendered product data.
- Reduced accessibility defects by 67% by building tested form primitives and adding automated axe checks to CI.
- Lowered signup drop-off from 41% to 29% by rebuilding the onboarding flow in Next.js with inline validation and a save-progress API.
Mobile engineering
- Raised crash-free sessions from 98.1% to 99.7% by tracing startup failures and replacing an unsafe local-storage migration.
- Reduced cold-start time by 39% by deferring analytics initialization and parallelizing independent network requests.
- Increased seven-day retention by 5.2% by shipping an offline-first onboarding flow backed by local caching and sync recovery.
Data and machine learning
- Improved recommendation click-through rate by 12% by retraining the ranking model with freshness features and better negative sampling.
- Cut warehouse spend by $9,400 per month by clustering high-volume tables and replacing full refreshes with incremental dbt models.
- Reduced pipeline recovery time from 3 hours to 25 minutes by adding checkpointed backfills, data-quality alerts, and idempotent jobs.
Infrastructure, DevOps, and SRE
- Improved service availability from 99.90% to 99.97% by redesigning health checks and automating failover for two critical services.
- Cut deployment time from 28 minutes to 9 minutes by parallelizing CI jobs and caching unchanged Docker layers.
- Reduced monthly AWS spend by 18% by right-sizing Kubernetes requests and scheduling nonproduction workloads outside business hours.
Security and QA
- Closed 140 open dependency alerts across 22 repositories in one quarter by setting up Renovate auto-merge for patch updates and a weekly triage rotation.
- Removed long-lived AWS access keys from 9 services by moving them to IAM roles for service accounts and adding a CI check that blocks new static credentials.
- Cut flaky test reruns from about 30 a week to 4 by quarantining unstable Playwright specs and fixing shared state between fixtures.
Senior and staff scope
- Let 6 teams deploy independently of the monolith release train by designing module boundaries and adding contract tests between them.
- Reduced breaking API changes between teams from 11 in a quarter to 1 by introducing schema review and automated breaking-change checks for all gRPC protos.
- Saved about $210K a year in licensing by leading the move from a commercial APM vendor to OpenTelemetry and Grafana Tempo.
Leadership and collaboration
- Reduced new-engineer ramp time from six weeks to four by creating an ownership map, local setup automation, and a reviewed onboarding project.
- Increased quarterly delivery predictability from 62% to 87% by introducing dependency reviews and smaller milestone-based release plans.
- Cut recurring production incidents by 35% by leading postmortem follow-through and assigning measurable owners to reliability work.
Intern and new-grad experience
- Saved the support team 6 hours per week by building an internal React dashboard that consolidated customer-account diagnostics.
- Reduced test-suite runtime by 24% by identifying slow integration fixtures and replacing repeated setup with shared factories.
- Improved documentation search success by 15% by analyzing zero-result queries and adding synonyms for common developer terms.
Personal and open-source projects
- Grew an open-source CLI to 1,200 GitHub stars and 40 outside contributors by writing plugin docs and answering new issues within 48 hours.
- Served about 3,000 monthly users on a $12/month VPS by building the API in Go with SQLite and aggressive HTTP caching.
- Placed 2nd of 85 teams at a university hackathon by building a speech-to-SQL prototype with Whisper and Postgres in 36 hours.
For more by role, see our software engineer resume bullet points. If you have a draft bullet and want a rewrite, the resume bullet generator turns it into XYZ form.
How to use XYZ when you do not have exact metrics
Do not invent numbers. A made-up "37% improvement" falls apart the first time an interviewer asks how you measured it. Bock's post makes a related point: even work that looks hard to measure usually has something you can point to.
Where engineers usually find their Y
- Monitoring dashboards (Datadog, Grafana, New Relic) for latency, error rates and uptime before and after a change
- CI history in GitHub Actions or CircleCI for build and deploy times
- Cloud billing, such as AWS Cost Explorer, for spend
- Postmortems and the incident tracker for incident counts and recovery time
- Jira or Linear for ticket volume, and old PR descriptions, which often state the problem and the result
- Your performance review or promo packet, and a message to your old manager
If there is truly no number
- Scope: services owned, repositories migrated, endpoints shipped, teams supported, or regions launched.
- Frequency: daily jobs, weekly releases, monthly incidents, or recurring hours saved.
- Before and after: manual to automated, nightly to near real time, days to hours, or several steps to one.
- Reliability: fewer alerts, safer rollbacks, an eliminated failure mode, or clearer operational ownership.
- Adoption: used by the support team, adopted across engineering, or rolled out to all customer accounts.
Rounded numbers are fine if they are honest. "About 30 a week" or "~2,000 users" reads better than false precision.
Example without a percentage
Replaced a manual weekly access review with an automated audit workflow used by security and engineering, reducing the process from two days to under an hour.
Where XYZ bullets go and how many to write
XYZ bullets go under each role in your experience section and under each entry in projects. They do not belong in your skills list. A summary, if you have one, can borrow a single number. Keep it short.
- How many per role: 3 to 5 for recent roles, 1 or 2 for older ones. Put the strongest bullet first, since a reader skimming the page may stop after one or two.
- Not every bullet needs a hard metric. One bullet per role about scope or ownership ("Owned the billing service, 4 engineers") is fine if the rest carry numbers.
- Length: one line is ideal, two is the limit. If it runs to three, you are describing two accomplishments.
- Tense: past tense for past roles and finished work, present tense only for things you still do in your current job.
- New grads: internships, projects, TA work, and hackathons all work. Users, stars, response time, grade or ranking can all serve as Y.
On applicant tracking systems: an ATS reads text, and nothing about the XYZ pattern itself is scored. What helps is the Z part. When it names the tools you used (Kafka, Terraform, React Native) and those match the job posting, a recruiter searching for them can find you.
Common XYZ bullet mistakes
- A percentage with no baseline. "Improved performance by 40%" leaves the reader guessing: performance of what, measured how? Give the before and after, or the absolute number.
- False precision. "Increased throughput by 37.42%" looks invented. Round it.
- Claiming the team's result as your own. If six people shipped it, say which part was yours: "built the ingestion layer for", "led the rollout of".
- A vague Z. "By using best practices" or "by using modern tools" tells the reader nothing. Name the change.
- Tool soup. Listing eight technologies in one bullet buries the decision that mattered. Two or three is plenty.
- Every bullet starts with "Increased". Vary the verbs: cut, shipped, migrated, replaced, designed, scaled.
XYZ resume bullet checklist
Before keeping a bullet, check that a reviewer can answer each question in one pass:
- What changed? Name the product, system, workflow, or customer outcome.
- How much did it matter? Add a metric, scale marker, or concrete before-and-after result.
- What did you personally do? Include the technical decision, tool, or leadership action.
- Is the claim credible? Keep only details you can defend and explain.
- Is it concise? Remove filler such as responsible for, helped with, and worked on.
If your bullet names only a task, it is missing X. If it has no evidence, it is missing Y. If it hides your contribution, it is missing Z.
XYZ vs STAR vs CAR
XYZ, STAR and CAR all push you toward results. They differ in where you use them.
| XYZ | STAR | CAR | |
|---|---|---|---|
| Stands for | Accomplishment, measurement, method | Situation, Task, Action, Result | Challenge, Action, Result |
| Best for | Resume bullets | Behavioral interview answers | Resume bullets when the problem needs context |
| Length | 1 to 2 lines | 1 to 3 minutes spoken | 1 to 2 lines |
| Forces you to include | A number | The story and your reasoning | The problem you solved |
In practice: write your resume in XYZ, then prepare a STAR story for each of your top bullets, because interviewers will ask about them. Our STAR method guide covers the interview side.