Self assessment examples for software engineers — STAR + real numbers
Short answer
Write each accomplishment in STAR (Situation, Task, Action, Result) and quantify the result. For engineers, the four metrics that always land are: latency, error rate, deploy frequency, and headcount-leverage (e.g., "reduced on-call load by N hours/week"). Tie each item to the next-level rubric on your ladder. Three to five strong items beat ten weak ones.
You're here because
- Your review is in 24–72 hours and you have a blank doc
- You've done the work but can't recall what you did all year
- You don't know how to frame "impact" for an engineer
- Your manager hints at promotion but the rating depends on this doc
- You don't want to sound braggy — or vague
The exact email to send
Item 1 — Reliability
Situation: The checkout service was the team's #1 source of P1 incidents (4 in Q1).
Task: Drive incident rate to zero before Q4.
Action: Designed and shipped a circuit-breaker + retry-budget pattern across 3 services. Wrote a runbook used by 2 other teams.
Result: P1 incidents went from 4/quarter to 0 over Q2–Q4. p99 latency dropped 38%. Team on-call hours dropped ~6 hrs/week.
Item 2 — Leverage
Situation: Three services shared a flaky CI pipeline costing the team ~5 dev-hours/day.
Task: Cut CI flake & runtime.
Action: Replaced legacy test runner, parallelized integration suites, removed 14 redundant fixtures.
Result: CI runtime −62%. Dev-hours saved: ~25/week across the team. Adopted by 2 other teams in Q3.
Item 3 — Cross-team / mentorship
Situation: Two new engineers ramping; no formal onboarding.
Task: Cut their first-PR time from 4 weeks → 2.
Action: Wrote onboarding doc; weekly 1:1s; reviewed first 6 PRs.
Result: Both shipped their first PR in week 2. Doc reused for 2 subsequent hires.
(The kit includes 6 more STAR items across performance, design quality, recruiting, and incident leadership.)
- Built for the moment a written offer or deadline lands — not casual browsing.
- Written for the 24–72 hour decision window.
- Designed for people who don't negotiate often.
- Real workplace register — not internet bravado.
What NOT to say
- "Worked hard" / "contributed to" / "helped with" — invisible to a calibration committee.
- Listing tasks without outcomes. Tasks aren't impact.
- Inflating numbers you can't defend. Calibration committees verify.
- Crediting only yourself for team work — credit the team, name your specific contribution.
- Using internal jargon a skip-level can't parse. Write for a stranger.
An illustrative example
A Senior engineer wrote 5 STAR items using the format above. The manager copy-pasted three of them verbatim into the calibration committee deck. The skip-level later told the engineer the STAR doc was the deciding factor in landing Exceeds. Exceeds rating + accelerated promo track to Staff, both flowing from the same doc.
Why this works
Calibration committees compare engineers across teams in 5–10 minutes per person. They lean on whatever bullet points the manager presents. STAR + numbers gives the manager exactly what to paste.
What to do next
Block 90 minutes today. List your top 5 wins. Convert each to STAR. Quantify every Result line. The Performance Review Kit includes 12 STAR examples across IC, lead, and staff levels — plus the "areas for growth" framing that doesn't tank your rating.
Before you send — quick check
- Have you listed 3 outcomes in STAR format with numbers?
- Have you mapped them to the next level's scope?
- Have you removed every adjective ("great", "strong") and replaced with metrics?
If you answered "not sure" to any of these, the Performance Review Kit walks you through all three.
Related reads
FAQ
How many items should I include?
3 to 5 strong STAR items. More than 7 dilutes the message — calibration committees skim.
What if I don't have hard numbers?
Use leverage metrics: hours saved, on-call reduction, ramp-up time, incident count. If nothing is quantifiable, you're describing a task — not impact.
Should I include 'areas for growth'?
Yes, but only 1–2 items, framed as forward-looking goals ("deepening systems-design fluency at the cross-service level"). Never weaknesses without a plan.