Performance Review Examples for Software Engineers

Most performance-review example posts I’ve seen suffer from the same problem: the examples are so generic that you could paste them into a review of literally any engineer and they would fit. That makes them useless as references. If “Sarah is a strong collaborator who consistently delivers high-quality work” describes both Sarah and Priya and the engineer down the hall, it doesn’t describe any of them.

The examples below try to do the opposite. Each one picks up a specific scenario you’ll recognise, names a specific engineer (composite, not real), and shows the actual prose I would write for that situation. After each example there’s a short note explaining what it’s doing well so you can steal the moves, not just the words. The full process behind these examples (evidence collection, the four-bucket framework, the drafting flow) is in how to write a performance review for a software engineer.

Example 1: Senior engineer who shipped a hard project

Scenario: Priya, senior engineer on the platform team, led the billing-system migration this half. It went live without customer-visible incidents, but it took a quarter longer than the original estimate.

Priya owned the billing-system migration end-to-end this half. The scope was real: cutting over from the legacy provider to Stripe while keeping six months of invoice history in sync and not interrupting any active subscriptions. The cutover landed in Q3 instead of Q2 as originally scoped, but the slip was the right call. Priya pushed back when it became clear the original plan didn’t handle proration on mid-cycle plan changes, and the extra time turned a project that would have shipped with known defects into one that shipped without them.

The work I’d call out beyond the headline outcome: the rollback plan Priya wrote was used twice during the dry-run cutovers and prevented a Stripe API rate-limit incident from reaching customers. Her design doc was the most-referenced artefact on the team this half, including by people outside platform. She is operating squarely at senior level on technical contribution and is the strongest candidate on the team for the staff promotion conversation in 12 months.

What this does well:the slip is named directly instead of hidden, but it’s framed as judgement (which is what it was). The rollback plan is a specific artefact, not an adjective. The forward-looking line about staff promotion is future-tense and conditional, which is exactly how that conversation should be set up months in advance.

Example 2: Mid-level engineer ready for promo

Scenario: Marco, mid-level on the growth team. Has been at the company for two years, mid-level for one. The case for promotion is real but the evidence is scattered.

Marco has spent this half quietly doing senior work. He owned the experimentation-platform rebuild from scoping through rollout. The original ask was a one-month patch; Marco came back with a one-page proposal arguing for a six-week rebuild with a clean abstraction layer, and the trade-off he flagged (slightly slower delivery now, faster iteration on every future experiment) played out exactly as predicted. The team has shipped three experiments since the rebuild that would have taken twice as long under the old system.

The growth case is in collaboration. A year ago Marco would bring me design problems to make calls on; this half he brought me two options with a recommendation, and was usually right about which one to pick. He has also picked up mentorship of two juniors who joined in Q2, and his PR review comments on their work are the kind I would write myself. He is ready for the next level. The remaining gap is cross-team visibility: most of his impact this half lived inside growth, and senior work generally requires showing up in design reviews on other teams. That should be the next-half focus.

What this does well:the promotion case is made by evidence (specific projects, specific behaviours), not by adjectives. The remaining gap is named so the conversation about next-period focus is grounded. Note the “he was usually right about which one to pick” line. That’s the kind of specific observation about judgement that’s very hard to fake.

Example 3: Newer hire, six months in

Scenario: Sam joined as a mid-level engineer six months ago. It’s their first review at the company. They’re still in the ramp window, and most of their work has been smaller scope by design.

Sam is in the part of ramp where the technical fundamentals are clearly in place and the company-specific context is still building. Their first three months were the right shape: starter projects with clear acceptance criteria, lots of questions in 1:1s, PR throughput steady. The second three months have shown signs of the next gear, particularly in code review. Sam’s review comments on the auth refactor caught two real issues that more senior people had missed, and the explanation in their comments was patient enough that the author learned something.

For the next six months, the focus is scope: moving from bounded tickets to small features Sam scopes themselves. The easiest way to make that visible is for them to take ownership of one feature end-to-end in Q1, including the design doc. I would rather they pick a small one and write the proposal well than a big one and execute on someone else’s plan. They are tracking exactly where I would want a mid-level engineer to be at six months.

What this does well:the review acknowledges that ramp is its own period, doesn’t over-promise on impact, and gives the engineer a concrete shape for what “next gear” looks like. The line about “rather they pick a small one and write the proposal well” is the kind of guidance that’s actually useful, vs the generic “take on more ownership.”

Example 4: Engineer who’s coasting

Scenario: Jordan, mid-level engineer, three years on the team. Output has been steady but the work has been small, repetitive, and nobody is reaching to put bigger work in front of them.

Jordan is delivering at the lower end of mid-level this half. The PRs are clean, the tickets close on time, and there have been no incidents traced back to their work. That sounds positive, and it is, but the shape of the work has been a step down from where Jordan was last year. The tickets they’ve closed have been the kind I would expect a strong junior to handle. When bigger work has come up, Jordan hasn’t reached for it, and I haven’t pushed.

That pattern is fixable, and I want to be honest that I share responsibility for letting it set in. For next half I’d like Jordan to own one substantive piece of work that requires a design doc and a meaningful cross-team conversation. The two candidates I have in mind are the read-model refactor and the notifications-pipeline cleanup. Either one would put Jordan back on the mid-level trajectory and create the surface area for the senior conversation in 12 to 18 months. The risk of not making this change is real: another flat half at this scope and the next conversation gets harder.

What this does well:the manager owns part of the pattern (“I haven’t pushed”) which makes the feedback land as a conversation, not a verdict. The consequence is named directly without being threatening. The next-step options are concrete, not “take on more impactful work.”

Example 5: Engineer with a collaboration gap

Scenario: Riya, mid-level engineer, exceptional technical chops. Two peers have flagged in separate 1:1s that her code review comments come across as dismissive.

Riya’s technical work this half has been outstanding: the rate-limiter rewrite landed under-budget, the incident post-mortem she wrote in Q2 is now a template the platform team uses, and the design decisions she made on the queue migration aged extremely well. The collaboration side has more to work on. Two peers have flagged that Riya’s code review comments sometimes read as dismissive (“this is wrong” without context, or “why would you do this?” in situations where the answer would have helped). The technical substance of the reviews is right; the tone is leaving people not wanting to send her their PRs.

I don’t think this is a character problem and I don’t want it framed that way. The pattern looks like Riya assuming more context than the author has, which makes a precise technical comment read as a put-down. For next half, the small change I’d like to see is one extra sentence on review comments where the author is more junior: name the thing you’d do instead, not just the thing that’s wrong. I flag this because Riya is otherwise an obvious senior candidate and the only thing holding it back is this. It’s a fixable, concrete thing.

What this does well:the technical strength is named and credited before the harder feedback lands, so it doesn’t feel like a setup. The collaboration gap is named as a specific pattern (“assuming more context”), not a character trait. The fix is one sentence the engineer can actually try the next day. And the stakes are made clear without being threatening (“the only thing holding it back”).

What these examples have in common

If you re-read the five examples, the same handful of moves shows up in each:

• Specific artefacts, not adjectives. Design docs, PR comments, incident retros, named projects. The reviews work because they could only have been written about this engineer.
• The harder feedback is framed as fixable. Even example 4 (the coasting case) names two specific candidate projects. Even example 5 (the collaboration gap) names one concrete behaviour change. Vague criticism is the cousin of vague praise; neither moves anyone forward.
• The manager shows up in the writing.Lines like “I haven’t pushed” or “I’d rather they pick a small one” carry a point of view. Reviews that read like minutes from a meeting nobody attended are AI-prose tells.
• The forward-looking line is conditional and specific.“The next conversation gets harder.” “Strongest candidate for staff in 12 months.” That kind of specificity puts the conversation on rails before it happens, which is the whole point.

For the matching engineer-side post (what to write in your own self-evaluation given these patterns), see software engineer self-evaluation examples. For the tactical tips on both sides of the review, see performance review tips for software engineers.