Self-evaluation examples for software engineers

Why so many self-evaluations sound the same

Read a few self-reviews from any team and you’ll find the same sentences. “Consistently delivered high-quality work.” “Strong team player.” “Successfully completed all assigned tasks.”

None of that is false, it just doesn’t help anyone. Your manager has to take your review into a calibration meeting and argue for your rating next to a dozen other engineers, and a sentence they can’t back up with anything concrete won’t carry much weight in that room.

What helps is specifics: what you did, what changed because of it, and ideally a number.

The pattern behind a good answer

Most strong answers hit the same beats. What you did, what happened as a result, and why the team or the business cared. The number usually lives in the middle part.

If you don’t have an exact number, a rough one is fine as long as you say it’s rough. “About 30% fewer pages” beats “significantly fewer pages”.

Sample answers to the questions you’ll actually get

Every company’s form is a little different, but the questions are almost always some version of these. The sample answers are written for a mid-level backend engineer. Borrow the structure and use your own words, because reviewers notice when three people pasted the same template.

“What were your key accomplishments this period?”

My biggest project this half was moving billing out of the monolith into its own service. I wrote the design doc, split the work into four milestones, and shipped it in May with zero downtime. That unblocked the pricing team, who launched annual plans three weeks after the cutover.

I also took over our flaky CI suite. After quarantining and fixing the worst 40 tests, the main pipeline’s failure rate dropped from about 18% to 3%, which saves everyone a few re-runs a day.

Pick two or three things and put the most important one first. Some reviewers stop reading after the first paragraph.

“What are you most proud of?”

This one can be smaller or more personal. It doesn’t have to be your biggest project.

The on-call runbook, even though nobody asked for it. After my second rough night on call, I spent a few afternoons writing down how to diagnose our five most common alerts. Two newer engineers have told me it’s the first thing they open when they get paged, and our median time to resolve went from about 50 minutes to 20.

“Where did you fall short, or what would you do differently?”

People dread this question, but a good answer here earns you a lot of trust. Name something real, say what you learned, and say what you’re already doing about it.

I underestimated the search reindexing work in Q2. I scoped it at two weeks, it took five, and I flagged the slip later than I should have. Since then I do a short spike before estimating anything in a system I haven’t worked in, and on longer projects I post a status update every Friday, even when there’s nothing new to report.

Skip the fake weaknesses like “I care too much” or “I work too hard”. Reviewers see through them, and they make the rest of your review look less honest.

“How have you helped your team or worked with others?”

I reviewed about 120 PRs this half and turned the comments I kept repeating into lint rules, so we stopped debating the same things in review. I paired with the mobile team for two weeks to get their offline sync working against our new API, which let them ship a release early. I also ran our interview loop for backend hires and helped close two of them.

“How have you grown technically?”

Before this half I’d never run Kafka in production. I took over the consumer for our events pipeline, learned to read the lag dashboards, and handled two incidents on it myself. Next I’d like to get better at capacity planning, since that’s where I still lean on other people.

“What are your goals for the next period?”

A good goal is specific enough that six months from now you could say whether you hit it.

1. Lead the design of the notifications rewrite, from the RFC to its first production release.
2. Mentor one of our newer engineers through their first on-call rotation.
3. Get our core API’s p99 latency under 300ms. It’s at 450ms today.

“How would you rate yourself?”

If your form asks for a score, pick the honest one and back it with a sentence or two of evidence. Most scales look roughly like this:

I’d put myself at a 4. The billing migration, my main goal, shipped on time, and the CI work went beyond what was planned. I’m not going for a 5 because the reindexing project slipped by three weeks.

Rating yourself a notch below where you think you landed shows judgment. Rating yourself far below it just leaves your manager less room to argue for you.

Examples by level

The questions stay the same as you get more senior, but the scope of a good answer grows with you.

Junior engineer

In your first year or two, reviewers want to see that you ship reliably, learn fast, and need a little less help each quarter. Small things count as long as they’re finished.

Accomplishments: I shipped 14 tickets this half, including the CSV export for the admin dashboard that support had been asking for since last year. It now gets used about 200 times a week. I also tracked the timezone bug in scheduled emails through three services and fixed it, which was the first time I’d debugged something end to end on my own.

Growth: When I started I needed a pairing session for most tickets. By the end of the half I was taking medium-sized tickets on my own and only asking for input at the design stage. Next I’d like to own a small feature from spec to release.

Senior engineer

At senior level you’re judged on whether projects land because of you, and whether the people around you got better.

Accomplishments: I led the notifications rewrite from RFC to launch with two other engineers. Delivery failures dropped from 4% to under 0.5%, and we retired a vendor that was costing about $3k a month. I also set up our team’s design review. Five RFCs have gone through it since, and two changed direction because of what came up there.

Mentoring: I was the onboarding buddy for both of our new hires this half. Each shipped to production within their first two weeks, and one of them now maintains our on-call handbook.

Staff engineer or tech lead

Here the question shifts from what you built to what’s different about the org because you were around.

Accomplishments: I wrote the proposal to consolidate our three job queues into one platform and got four teams to agree on a migration plan. Two teams have moved so far, and queue-related pages for those teams are down about 60%. I also defined the reliability bar for tier-1 services, which is now part of every launch checklist.

Areas to improve: I stayed in the weeds on the queue migration for too long and was slow to hand off the second team’s cutover. Next half I want to stay at the design and unblocking level and let the team leads own execution.

Examples by role

The structure doesn’t change between specialties, but the numbers reviewers look for do.

Frontend

I led the work that took our checkout page’s Largest Contentful Paint on mobile from 3.8s to 1.9s, mostly by splitting the bundle and lazy-loading the payment widgets. The page now passes Core Web Vitals, and mobile checkout abandonment fell about 4% the following month.

SRE, platform, or DevOps

I moved our services onto the new deployment pipeline, which cut the average deploy from 25 minutes to 8 and made Friday deploys boring again. I also set SLOs for our three tier-1 services with error-budget alerts, so we hear about slow degradations before customers do. Cleaning up idle staging clusters took about 12% off our cloud bill.

Mobile

Crash-free sessions on Android went from 98.9% to 99.7% after I fixed a leak in the image cache and added crash grouping to our release checklist. I also moved us from monthly to biweekly releases, and our app store rating rose from 4.2 to 4.5 over two quarters.

Data engineering

I rebuilt the nightly revenue pipeline on incremental models, cutting its runtime from three hours to 25 minutes, so finance has numbers by 9am instead of noon. I also added data quality checks on the five tables behind the exec dashboard. They’ve already caught two bad upstream loads before anyone saw a wrong number.

Short phrases you can adapt

Sometimes the form only wants a line or two. Treat these as starting points and swap the brackets for your real details.

For impact:

• “Shipped [project], which [result, ideally with a number].”
• “Took [metric] from [before] to [after] by [what you changed].”
• “Unblocked [team or project] by [what you did].”

For ownership:

• “Owned [system or area] end to end, including on-call and the roadmap.”
• “Spotted [problem] before anyone asked, and [what you did about it].”

For collaboration and mentoring:

• “Partnered with [team] on [project], which [outcome].”
• “Mentored [person or role] through [milestone].”

For growth:

• “Learned [technology or skill] and used it to [concrete result].”

For areas to improve:

• “I want to get better at [skill]. This half it cost us [specific moment]. Next half I’ll [concrete step].”

The hard part is remembering what you did

Every sample answer above has a number or a date in it, and that’s exactly what most people are missing when the form opens. You remember the big launch. You don’t remember that the CI fix was in March, or that it took the failure rate from 18% to 3%.

The way around that is to write things down as they happen. A line at the end of the day is enough, and by review time you’re picking highlights from a list instead of reconstructing half a year.

That habit is what Perfly is built around, and it tries hard to do most of the work for you:

1. You jot down a few lines a day, or connect GitHub, Jira, Google Calendar, or Notion and let Perfly draft them from your activity. If you work with Claude Code, Codex, or Cursor, your agent can send the summary. Either way, you confirm what to keep.
2. At review time you pick the period (a quarter, a half, or a year) and Perfly drafts your self-review from those confirmed items. The draft is grouped into six areas reviewers tend to care about: impact and scope, technical depth, direction, collaboration and influence, execution and ownership, and learning and growth. If you’ve set yearly goals, each goal gets its own block with the work behind it.
3. Every sentence links back to the work items it came from, so when your manager asks “when was that?”, you can actually answer.
4. It can suggest a 1 to 5 score with a short rationale, overall and for each goal. You decide whether to keep it.
5. You copy the result into your company’s review tool, export it as Markdown, or print it. If you want, you can also rehearse the review conversation with an AI interviewer that has read your draft.

Starting from zero this review season? Connect GitHub and Google Calendar and Perfly can pull in the last 12 months of activity, group it into themes, and let you pick the highlights. It won’t know everything you did, but it beats staring at an empty text box.

The same items also feed your weekly reports and your résumé, so the habit pays off in more than one place.

FAQ

How long should a self-evaluation be?

Shorter than you’d think. For most questions, one or two short paragraphs or three to five bullets is plenty. Your manager is reading a stack of these, so put your strongest point first.

Is it okay to use ChatGPT to write my self-evaluation?

For polishing, sure. The catch is that ChatGPT doesn’t know what you did, so if you ask it to write from scratch you get exactly the generic sentences this page started with. It does much better when you hand it a list of real accomplishments with numbers, which is the list most people don’t have.

Should I mention mistakes?

Yes, briefly, and pair each one with what you changed afterwards. A self-review with zero weaknesses is harder to believe than one with a real one.

Can my employer see what I write in Perfly?

No. Perfly is a personal tool with no team dashboard or admin view. You decide what goes into your company’s review system.

How much does Perfly cost?

30 days free with everything unlocked. After that it’s $6.99 a month, or $69.99 a year.