Guide · Self-reviews

Self-review examples for backend engineers.

Backend work is easy to undersell. When it goes well, nothing happens: the migration finishes, the endpoint holds, nobody gets paged. Your self-review has to make that quiet visible, with the before, the after, and who it helped.

What reviewers look for in a backend engineer

Reliability of what you own. Error rates, latency, incidents and how quickly you recovered. "Nothing broke" counts when you can show it was at risk.
Interfaces other people build on. APIs, schemas and contracts. Mobile and web teams live with a good or bad contract for years.
Safe change to data. Migrations, backfills and deletions done without data loss or downtime.
Operational ownership. On-call, runbooks, alerts you tuned and toil you removed.
Judgement on trade-offs. When you chose the boring option, or argued against a rewrite, and why.

Example: impact

The projects, people and numbers in these examples are made up. Keep the shape and use your own facts.

Impact • Designed and shipped the v2 sync endpoint for the Sync SDK (SYNC-201). Clients now upload only changed fields; the median payload went from about 40 KB to 6 KB per sync in staging tests. • Led the sessions table migration (about 30M rows) behind a dual-write flag. Cut-over took one evening with no user-facing errors, and a tested rollback plan we didn't need. • Brought p95 latency of the recipe search API from 820 ms to 310 ms with a covering index and by removing an N+1 query (APP-418). Recipe App 2.0 launched on the faster version.

Each line has the change, the evidence and the effect. Round any number you can't defend to the decimal, because a reviewer may ask.

Example: collaboration

Collaboration • Wrote the conflict-resolution API contract with Neha (iOS) before any server code. Mobile built against a mock and started two weeks earlier than planned. • Reviewed about 120 pull requests, mostly in sync and search. After the duplicate-save bug, ran a 30-minute session on idempotency keys; two teams now use the pattern. • Took six on-call weeks. Wrote runbooks for the four alerts that paged most, so the next person can act without waking me.

Example: growth

Growth • Learned our tracing setup well enough to own the Sync SDK dashboards. I find slow queries from traces now instead of guessing. • Asked Ravi for feedback on my design docs: shorter, decision first, alternatives in an appendix. My last two docs were approved in one review. • Next half: own capacity planning for sync traffic before the Recipe App 2.0 launch campaign.

Phrases that land

"p95 went from 820 ms to 310 ms": a before and an after, with the percentile named.
"with no user-facing errors": names the failure that didn't happen, which is most of backend work.
"mobile started two weeks earlier": your work, measured in another team's calendar.
"I chose X over Y because Z": shows judgement, the thing senior reviews look for.

Phrases that don't

"Worked on the backend." It says where you sat. Say what changed.
"Helped with performance." Helped how, and which number moved?
"Fixed a lot of bugs." The count is noise. Pick the two that mattered and say why.
"Was involved in the migration." Did you lead it, or watch the channel? Say which.

Gather your evidence

Your commits are the backbone. This lists every commit you made in the last six months, oldest first, with dates:

git log --all --since="6 months ago" --author="$(git config user.email)" \ --no-merges --reverse --date=short --format='%ad %s'

This pulls out every ticket ID in your commit messages and counts them, so you can see which projects took your time:

git log --all --since="6 months ago" --author="$(git config user.email)" \ --no-merges --format='%s' | grep -oE '[A-Z][A-Z0-9]+-[0-9]+' | sort | uniq -c | sort -rn

Commits show what changed. To show what it did, add latency and error graphs from before and after (screenshot them now, before the retention window drops them), incident timelines you were part of, and the design docs where decisions were made.

Let Sill keep the record

The hardest part of a backend self-review is remembering the quiet wins from five months ago. Sill keeps the record while you work. On the Mac it reads your local git history (commit messages and times, never code). On every device it records the tasks you finish, the releases you ship and the follow-ups you send, with receipts like day 6, asked 3×.

At review time, Sill Pro's Review generator turns months of that into a draft per project: what shipped, commit counts and ticket IDs, and every dependency you waited on. Where Apple Intelligence is available it writes a first-person draft on the device, and nothing leaves it. Commits come only from the Mac app. The last 7 days are free; longer periods need Sill Pro, an optional paid upgrade.

Get Sill on the App Store — for Mac, iPhone, iPad and Apple Watch. The daily standup and its set-time reminder are free.

More self-review examples: frontend engineers · iOS engineers · Android engineers · QA engineers · SRE and DevOps engineers · data engineers · engineering managers · product designers · product managers. Or start with how to write a self-review.