Guides for engineering managers
Self-review examples for software engineers
How to write a self-review your manager can actually use, with before-and-after examples for every section.
- Your self-review is the one document in the cycle where your own view of your work is on the record. Treat it as evidence, not modesty.
- Use a simple structure: summary, impact, collaboration, growth, a mistake you learned from, and what you want next.
- Every claim needs a specific example: what you did, when, and what changed because of it.
- Gather evidence before you write. An hour in your pull requests, tickets and Slack beats a weekend of trying to remember.
Most engineers write their self-review the night before it is due, from memory, in a tone somewhere between apologetic and vague. That is a missed opportunity. Your manager is summarising six months of your work, probably for several people at once, and probably remembers the last few weeks best. Your self-review is your chance to put the full picture in front of them before they write.
This guide is written for engineers. If you manage engineers, it is also a reasonable thing to forward to your team a week before self-reviews are due: better self-reviews make your own reviews faster to write and fairer.
A structure that works
If your company gives you a form, use its questions, but this structure maps onto almost any of them.
Self-review template
- Summary (2 to 3 sentences). The most important things you did this period and how you think it went overall.
- Impact. Two to four pieces of work that mattered most, with the outcome of each.
- Collaboration. How you helped others: reviews, mentoring, unblocking, incidents, hiring.
- Growth. What you got better at, with an example that shows it.
- A mistake and what you learned. One thing that went wrong and what you changed.
- Next period. What you want to work on, and what support would help.
Keep it to about one page. Your manager will read it closely, but not three pages of it.
Impact: lead with outcomes
The most common weakness in self-reviews is listing activity. Activity tells your manager you were busy. Outcomes tell them why it mattered.
I worked on a lot of tickets this half and helped with the checkout project. I also did some performance work.
I owned the checkout redesign backend from April to June. I split it into three releases so we could ship the saved-cards change first, which went out in week three. I also profiled the order summary endpoint and cut p95 latency from about 1.4s to 500ms by removing an N+1 query, which the mobile team had been flagging for months.
If you don't have a number, describe what changed: who stopped waiting on you, which alert stopped firing, which question support stopped asking.
Collaboration: name the invisible work
Reviewing pull requests, answering questions, onboarding new people and calming down incidents rarely appear in a ticket tracker. If you don't write them down, there is a good chance nobody will.
I'm a team player and always happy to help others.
I was the main reviewer for the data pipeline this half, and I tried to make reviews teach as well as catch problems. When Leo joined in July, I paired with him for his first two weeks and wrote the local setup guide we now give every new hire. I also ran two interview loops for the backend role.
Growth: show it, don't claim it
"I grew a lot as an engineer" is not something your manager can use. Pick one area and give the before and after.
I improved my system design skills.
Last review we agreed I should take on more design work. This half I wrote my first two design docs, for the notifications queue and the audit log. The first needed three rounds of review; the second was approved in one, partly because I started including the options we rejected and why. I'd like to keep building on this.
Mistakes: own one, briefly
Many engineers skip this, or bury it. A short, honest account of something that went wrong, and what you changed, reads as maturity. It also means your manager doesn't have to raise it first.
Some things didn't go as planned but overall I think it went well.
I underestimated the export feature by two weeks and didn't flag it until the sprint demo, which left product scrambling to reset a customer date. Since then I break work into milestones of a week or less and post in the project channel when one slips. On the audit log project that meant we moved scope early instead of missing the date.
Pick something real but proportionate. One mistake, three or four sentences, ending in what you do differently now.
Next period: ask for something specific
I'd like to keep growing and take on more responsibility.
I'd like to lead a project end to end next half, including the planning and stakeholder updates, not just the technical work. The billing reconciliation project looks like a good fit. It would help to have you review my first project plan, and to be added to the weekly product sync.
A specific ask gives your manager something to say yes to. A general one usually gets a general answer.
How to gather evidence in an hour
Do this before you write a word. Block an hour, open a blank note, and go through these in order, writing one line per item: what, when, and what changed.
- Your merged pull requests. On GitHub, filter by author and the review period. Skim the titles; the big ones will jog your memory about projects.
- Pull requests you reviewed. Same filter, but by reviewer. Note any reviews that caught real bugs or turned into a design discussion.
- Tickets you closed in Jira, Linear or whatever you use, plus any epics you owned.
- Design docs, RFCs and postmortems you wrote or contributed to.
- Slack. Search for messages from you in the team and incident channels, and for thank-you messages that mention you. Screenshots of praise are easy to forget and useful to quote.
- Your 1:1 notes and last review. What did you and your manager agree you would work on? Address it directly.
- Your calendar. Interviews, onboarding sessions, demos and talks you gave.
You will end up with far more than fits. That is the point. Now pick the best two to four items for impact and one or two for each other section.
Next cycle, skip the archaeology: keep a short running list as you go, one dated line whenever something notable happens. Five minutes a week is plenty.
How long should it be?
About one page, or 400 to 800 words if your form has free text. Under that, you are probably leaving out evidence. Much over that, your strongest points get lost. If your form has a character limit per question, write your best example first in each answer.
Common mistakes
- Underselling. "Helped with" when you led it. Say what your part actually was.
- Overclaiming. "I delivered the migration" when four people did. Name your part and credit others; managers notice both.
- Only the last month. Look across the whole period. Your strongest work may have been in the first quarter.
- Surprises. If you are unhappy about something important, raise it in a 1:1 first, not for the first time in a form.
- Adjectives instead of examples. "Proactive", "reliable" and "passionate" mean nothing without a story attached.
For managers forwarding this
If you send this to your team, add two things: the date you need self-reviews by, and a reminder that you would rather read a specific page than a polished one. Then read each self-review before you start writing your own review, so you can respond to their view instead of talking past it.
To see the other side of the process, read how to write an engineering performance review, and for how the finished manager paragraphs look, see our performance review examples for software engineers.