How to Use the STAR Method on a Resume
STAR was built for interview answers. Here is how to shrink it into one-line resume bullets, with 23 before-and-after examples for software engineers.
Reviewed by Markus Fink
Senior Technical Recruiter · Formerly Google & Airbnb
What You'll Learn
What is the STAR method on a resume?
A STAR method resume uses the four parts of a STAR interview answer (Situation, Task, Action, Result) to write experience bullets that show what changed because of your work. On a resume you don't write four parts or four bullets. You compress the story into one line: a few words of context, the specific thing you did, and the result, usually with the result first.
- Situation: the system, team or problem you walked into.
- Task: what you were responsible for.
- Action: what you did, including the technical choices.
- Result: what was different afterward, ideally measured.
STAR started as a way to answer behavioral interview questions like "Tell me about a time you dealt with a production incident." Amazon, for example, calls it the cornerstone of its behavioral interviews in its official interview guide. That is where a lot of the confusion comes from: people search for a "STAR format resume" expecting a resume template, when STAR is really a way of thinking through each accomplishment before you write it down.
A STAR resume bullet, decoded
Reduced p95 latency on the search API from 900 ms to 180 ms by replacing N+1 ORM queries with batched SQL and a Redis cache for facet counts.
- Situation: "on the search API" (slow endpoint)
- Task: implied by the verb (you owned the fix)
- Action: batched SQL, Redis cache
- Result: 900 ms to 180 ms, placed first
The rest of this page shows how to do that compression, when STAR is the right tool, and 23 before-and-after examples from backend, frontend, mobile, infrastructure, data, security and new grad resumes.
How to turn STAR into a one-line bullet
Each STAR part gets a very different amount of space on the page than it does out loud. This is the whole trick:
| Part | In an interview answer | In a resume bullet |
|---|---|---|
| Situation | A few sentences of background so the interviewer understands the stakes | A few words at most: the system, the scale or the problem ("for the checkout service", "across 40 microservices"). Often dropped. |
| Task | What you specifically owned | Usually implied by the verb. State it only when ownership is the point ("as the only backend engineer"). |
| Action | Most of the answer: steps, tradeoffs, who you worked with | One or two concrete technical decisions, with the tools named. |
| Result | The ending, plus what you learned | Often the first words of the bullet. A number, a before and after, or a concrete outcome. |
From interview story to one line
Here is a story the way you would tell it in an interview:
- Situation: Our product search endpoint was timing out during evening traffic. Support was getting complaints and the mobile team had added a client-side retry that made it worse.
- Task: I was asked to get p95 latency under 300 ms before a marketing launch three weeks out.
- Action: I profiled it and found the ORM was issuing one query per facet. I rewrote it as two batched queries, added a Redis cache for facet counts with a 60-second TTL, and load tested it with k6 at twice our peak.
- Result: p95 went from about 900 ms to 180 ms and the timeouts stopped. We removed the client retry.
Now cut it down. Keep the number, keep the two decisions that show engineering judgment, and squeeze the situation into a noun phrase:
Reduced p95 latency on the search API from 900 ms to 180 ms before a product launch by replacing N+1 ORM queries with batched SQL and a Redis cache for facet counts.
The k6 load test, the mobile retry and the three-week deadline didn't make it. That's fine. They are what you talk about when the interviewer asks about this bullet.
Bullet shapes that work
- Result first (best when you have a clear number): [Changed metric from A to B] by [action], [context if needed].
Example: Cut median CI time from 28 to 9 minutes by sharding tests across parallel runners and caching Docker layers. - Action first (best for things you built): [Built X] for [who or what], [result or scale].
Example: Built a typed React component library adopted by 5 product teams, replacing 3 separate form implementations. - Problem first (use sparingly, for debugging and incidents): [Fixed or traced problem] in [system], [result].
Example: Traced a Core Data threading bug behind 60% of iOS crashes and moved writes to a background context, raising crash-free sessions to 99.6%.
Mix the shapes. If every bullet on your resume reads "Reduced X by Y% by doing Z", it starts to look generated, even when every number is real.
When to use STAR on your resume
STAR is worth the effort for the bullets a reader will actually spend time on:
- The top 2 to 4 bullets of your most recent one or two roles.
- Internships and co-ops, where the result proves you shipped something real.
- Projects, especially if you're a new grad or switching careers. The Situation is often "for a course" or "for my own use", and the Result is users, test coverage, performance or what you learned to build.
- Open source contributions, where the result can be a merged PR, adoption or a closed issue.
- Leadership and mentoring, where the result is what the team could do afterward.
Skip it for:
- The skills section. A list of languages and tools doesn't need a story.
- Older roles. One or two shorter bullets per job from five or more years ago is plenty.
- Small supporting bullets. "Wrote design docs and reviewed PRs for a 6-person team" can stay simple if the bullets above it carry the weight.
Most people get more out of rewriting their three best bullets with STAR than forcing it onto all fifteen. For more on writing the rest, see our guide to software engineer resume bullet points.
23 STAR method resume examples for software engineers
Every example below is made up for illustration, but each is the kind of work real engineers do. Under each one is the STAR breakdown so you can see where each part went. Use the structure, not the numbers. Your bullet should only contain figures you can explain in an interview.
Backend and platform
Before
Worked on the payments service.
After
Cut failed card payments from 2.1% to 0.6% by adding idempotency keys and exponential-backoff retries to the Stripe integration in our Go payments service.
- S: payments failing on network blips and duplicate retries
- T: make charges reliable without double-charging
- A: idempotency keys, backoff retries
- R: 2.1% to 0.6% failure rate
Before
Improved API performance.
After
Reduced p95 latency on the search API from 900 ms to 180 ms by replacing N+1 ORM queries with batched SQL and a Redis cache for facet counts.
- S: search endpoint timing out at peak
- T: get latency under target
- A: batched queries, Redis cache
- R: 900 ms to 180 ms
Before
Responsible for migrating to microservices.
After
Moved order management out of a Rails monolith into 3 Kotlin services behind a strangler proxy, shipping in 4 phases with no customer-facing downtime.
- S: a monolith slowing down every deploy
- T: split out order management
- A: strangler proxy, phased rollout
- R: zero customer-facing downtime
Before
Built internal tools for developers.
After
Built a CLI that scaffolds new services with CI, Dockerfile and default alerts, cutting new-service setup from about 2 days to 1 hour for 40 engineers.
- S: every new service set up by hand
- T: standardize setup
- A: scaffolding CLI
- R: 2 days to 1 hour, 40 engineers
Frontend
Before
Worked on frontend performance.
After
Cut checkout page LCP from 4.2 s to 1.9 s on mid-range Android phones by code-splitting the React bundle and lazy-loading third-party scripts.
- S: slow checkout on lower-end phones
- T: improve load time
- A: code splitting, lazy loading
- R: LCP 4.2 s to 1.9 s
Before
Created reusable components.
After
Built a typed React component library (34 components, Storybook docs) adopted by 5 product teams, replacing 3 separate button and form implementations.
- S: inconsistent UI across teams
- T: create shared components
- A: TypeScript library, Storybook
- R: 5 teams adopted, 3 duplicates removed
Before
Fixed accessibility issues.
After
Brought the account settings flow to WCAG 2.1 AA by fixing focus order, labels and contrast across 22 screens, which cleared an accessibility requirement in a public-sector contract.
- S: a contract required accessibility compliance
- T: fix the settings flow
- A: focus order, labels, contrast on 22 screens
- R: requirement cleared
Mobile
Before
Fixed crashes in the iOS app.
After
Raised iOS crash-free sessions from 97.8% to 99.6% by tracing a Core Data threading bug from Crashlytics reports and moving writes to a background context.
- S: crash rate hurting reviews
- T: find the main cause
- A: Crashlytics triage, background context
- R: 97.8% to 99.6% crash-free
Before
Worked on app startup time.
After
Cut Android cold start from 3.1 s to 1.4 s by deferring SDK initialization and replacing a blocking config fetch with a cached value.
- S: slow launch
- T: speed up startup
- A: deferred init, cached config
- R: 3.1 s to 1.4 s
Infrastructure, DevOps and SRE
Before
Managed CI/CD pipelines.
After
Cut median CI time from 28 to 9 minutes by sharding the test suite across parallel GitHub Actions runners and caching Docker layers.
- S: slow CI blocking merges
- T: speed up the pipeline
- A: test sharding, layer caching
- R: 28 to 9 minutes
Before
Participated in on-call rotation.
After
Reduced pages per on-call week from about 35 to 8 by deleting noisy alerts, adding SLO burn-rate alerts and writing runbooks for the 10 most common incident types.
- S: alert fatigue
- T: make on-call sustainable
- A: alert cleanup, SLO alerts, runbooks
- R: about 35 to 8 pages a week
Before
Migrated infrastructure to Kubernetes.
After
Migrated 18 services from hand-managed EC2 instances to EKS using Terraform and Argo CD, cutting monthly compute spend by 31%.
- S: snowflake servers, rising cost
- T: move services to Kubernetes
- A: Terraform, Argo CD, EKS
- R: 31% lower compute spend
Before
Handled production incidents.
After
Led the response to a 40-minute checkout outage caused by database connection pool exhaustion, then added pool limits and a load-shedding fallback that held through the next holiday peak.
- S: checkout down
- T: lead the incident and prevent a repeat
- A: pool limits, load shedding
- R: no repeat at the next peak
Data and machine learning
Before
Maintained ETL jobs.
After
Rewrote nightly Spark ETL as incremental dbt models on Snowflake, cutting runtime from 6 hours to 40 minutes so finance dashboards were ready before 8 a.m.
- S: overnight jobs finishing late
- T: make data ready on time
- A: incremental dbt models
- R: 6 hours to 40 minutes
Before
Worked on the recommendation model.
After
Shipped a two-tower retrieval model for product recommendations that raised click-through by 7% in a 4-week A/B test against the rules-based baseline.
- S: rules-based recommendations
- T: replace with a learned model
- A: two-tower retrieval
- R: 7% CTR lift in an A/B test
Before
Built a RAG chatbot.
After
Built a RAG support assistant over 12k help-center articles with pgvector, plus an eval set of 300 real tickets that caught 2 answer-quality regressions before release.
- S: support team answering repeat questions
- T: build an assistant that can be trusted
- A: pgvector retrieval, ticket-based evals
- R: 2 regressions caught pre-release
Security
Before
Improved security.
After
Removed long-lived AWS keys from 60+ CI jobs by switching to OIDC role assumption, closing the highest-severity finding from the annual pentest.
- S: static credentials in CI
- T: remove the risk
- A: OIDC role assumption
- R: top pentest finding closed
Internships, new grads and projects
Before
Interned on the growth team and wrote code.
After
Built a feature-flagged onboarding checklist in Next.js during a 12-week internship; it rolled out to all new users after an A/B test showed a 4-point lift in week-one activation.
- S: new users dropping off
- T: own one onboarding improvement
- A: feature-flagged checklist, A/B test
- R: full rollout, 4-point lift
Before
Made a distributed key-value store for class.
After
Implemented a Raft-based key-value store in Go for a distributed systems course, passing all 60 fault-injection tests including leader crashes and network partitions.
- S: course project
- T: build a fault-tolerant store
- A: Raft in Go
- R: all 60 fault tests pass
Before
Created a web app for tracking habits.
After
Built and launched a habit tracker with React Native and Supabase that reached 1,200 sign-ups in its first 3 months, with push reminders that brought 30-day retention to 22%.
- S: personal project
- T: ship something people use
- A: React Native, Supabase, push reminders
- R: 1,200 sign-ups, 22% retention
Senior, staff and lead engineers
Before
Mentored junior engineers.
After
Mentored 4 engineers through their first design docs and on-call rotations; 2 now run the team's incident reviews.
- S: a team of mostly new hires
- T: help them ramp
- A: design doc and on-call mentoring
- R: 2 now lead incident reviews
Before
Led a database migration.
After
Led 6 engineers through a 9-month move from self-hosted Postgres to Aurora, writing the cutover plan and rollback drills that kept the final switch to under 5 minutes of read-only time.
- S: aging self-hosted database
- T: lead the migration
- A: cutover plan, rollback drills
- R: under 5 minutes read-only
Before
Worked with other teams on API standards.
After
Wrote the RFC for a company-wide API versioning policy, got sign-off from 7 teams and built the lint rule that now blocks breaking changes in CI.
- S: teams shipping breaking API changes
- T: set a standard
- A: RFC, CI lint rule
- R: 7 teams signed off, breaking changes blocked
For new grads, the new grad resume guide covers how many projects to include and how to order them.
Writing the Result when you don't have metrics
A lot of engineering work doesn't come with a clean percentage. That doesn't mean the bullet can't have a Result. It means the Result is a different kind of evidence:
- Before and after in time: "cut release prep from a half-day manual checklist to a 10-minute script".
- Scale: requests per second, number of services, rows per day, users, regions.
- Adoption: "used by 5 teams", "now the default template for new services".
- Risk removed: closed a pentest finding, met a compliance requirement, removed a single point of failure.
- What it unblocked: "which let the mobile team ship offline mode".
- Quality: fewer incidents, fewer rollbacks, flaky tests fixed, coverage on a module that had none.
Result with nothing in it
Refactored the notification service, resulting in improved maintainability.
Result without a percentage
Split a 4,000-line notification handler into channel-specific modules with contract tests, so adding SMS took one engineer a week instead of the quarter estimated before.
If you estimate, be able to say how you got the number. "About 35 pages a week" is fine if you counted a few weeks of PagerDuty history. A number you invented to fill the slot is the first thing a good interviewer will pull on.
STAR vs XYZ vs CAR for resume bullets
You'll see several acronyms for the same idea. They overlap a lot, and the differences matter less than people make them sound.
| Method | Parts | Built for | Use it to |
|---|---|---|---|
| STAR | Situation, Task, Action, Result | Behavioral interview answers | Gather the full story behind each bullet, then prepare to tell it |
| XYZ | Accomplished X, as measured by Y, by doing Z | Resume bullets | Write the final one-line bullet, result first |
| CAR / PAR | Challenge (or Problem), Action, Result | Both | Bullets where the problem is the interesting part, like debugging or incidents |
A STAR bullet that has been compressed properly, with the Task dropped and the Result moved to the front, looks almost exactly like an XYZ formula bullet with a little context added. So the practical workflow is: use STAR to think, and write in the XYZ shape.
The one place STAR still earns its extra letters on a resume is the Situation. A few words of context ("during a 3x traffic spike", "as the first backend hire") can make an ordinary result impressive. XYZ has no slot for that, so it tends to get left out.
Common STAR resume mistakes
- Writing the interview answer on the resume. "Situation: our API was slow. Task: I was asked to fix it." Labels and four-bullet stories waste space. One project, one bullet, maybe two if it was a large chunk of your year.
- Too much Situation. "Due to increasing customer complaints regarding slow page loads on our legacy e-commerce platform..." is 14 words before anything happens. Cut to "on the checkout page".
- A Result that isn't a result. "Resulting in improved performance" or "enhancing user experience" says nothing. Name what improved and by how much, or use one of the non-numeric results above.
- A tool list in place of an Action. "Used React, Redux, TypeScript, Jest and Webpack" is a skills section. The Action is the decision: what you changed and why it worked.
- Claiming team results as yours alone. If six people shipped it, say what you did ("designed the caching layer for") and let the result stand for the team. Interviewers ask, and the gap shows.
- Numbers you can't defend. "Improved efficiency by 300%" invites the question "measured how?". If you don't know, use scale or time instead.
- Burying the Result. In a 40-word bullet, a reader skimming may never reach the end. Lead with the result when it is the strongest part.
- Every bullet in the same mold. Fifteen "Reduced X by Y% by Z" lines read like a template. Vary the shape and keep some bullets short.
Checklist for a STAR bullet
Run each of your top bullets through these questions:
- Does it fit in one or two lines?
- Can someone outside your team tell what changed?
- Does the verb match what you actually owned (built, led, designed, contributed to)?
- Does it name at least one technical decision, beyond the tool names?
- Is the Result concrete: a number, a before and after, adoption, or risk removed?
- Could you talk about it for five minutes, including what went wrong?
- Does it use the words from the job posting where they are true (Kafka, Kubernetes, React Native)?
If a bullet fails more than two of these, rewrite it from the STAR notes rather than editing the wording.
Use the same stories in your interviews
Since STAR comes from interviews, every STAR bullet is the headline of an answer you should be ready to give. Behavioral rounds ask things like "Tell me about a time you disagreed with a technical decision" or "Describe an incident you handled." Your best bullets are where those answers come from.
For each of your top bullets, keep a short note with the parts that didn't fit on the page:
- The situation in two sentences, including why it mattered then.
- What you owned and who else was involved.
- The options you considered and why you picked one.
- Something that went wrong or that you would do differently.
- How the result was measured, and where the number came from.
Write the notes first and the bullet second. It is much easier to cut a full story down to one line than to invent a story behind a line that was written to sound good.