Short answer
A useful engineering self-assessment connects work from the full review period to the expectations for your level. Use artifacts you can point to, explain your contribution without inflating it, and give every development note a concrete next step.
Start with the story of the period
Open with the engineering problem that took most of your attention and what changed because of your work. Keep the opening to one or two sentences, then support it with evidence from the rest of the period.
Write in the first person. Separate what you owned from what the team delivered together so your contribution is clear without claiming other people's work.
Use engineering evidence you already have
Useful evidence includes design documents, pull request discussions, test plans, release notes, incident timelines, runbooks, and decisions recorded during delivery. Name the artifact and the effect it had. If no metric exists, do not create one.
Cover more than shipped features. Risk found before release, a simpler design chosen after review, and an operational handoff that another engineer could follow are all assessable outcomes.
- What I changed or decided
- What evidence shows my contribution
- Who could act, deliver, or operate more clearly afterward
A first-person example without invented detail
Use placeholders when the facts belong to you. Replace each bracket with a real artifact, decision, or outcome from the review period.
A complete example can include a contribution and a limit: I owned [component or project] from design through release. I documented [decision], incorporated review feedback about [risk], and left [runbook or test coverage] for the team. I did not surface [known gap] early enough, so next time I will add it to the design checklist before review.
Evidence-led phrasing
I worked hard and delivered a lot of high-quality code.
I owned [change] through release, recorded the key tradeoff in [artifact], and addressed the review comments that affected [risk or user outcome].
Connect the work to your level expectations
Read the Function version used for this review cycle. For each relevant competency, explain whether the evidence shows the scope, autonomy, and complexity expected at your current level.
Do not argue for the next level with a list of tasks. Point to repeated evidence of next-level scope, such as setting direction for a shared system or helping multiple teams make the same technical decision.
Give each development note a next step
Choose one or two observable gaps. Written design, review timing, incident updates, test strategy, and operability are useful only when tied to something that happened.
Write what you will do next and how someone can see the change. For example: I left rollback planning until review on [project]. For the next design, I will draft failure modes and rollback steps before requesting feedback, then ask the on-call owner to review them.