career bridge
Prove it
This is the road where you have real numbers. Lead with them, and keep the change that did nothing.
You have an audit, a cost table, a regression suite and a deployed service with an incident behind it. That is more operational evidence than most applicants for this role arrive with. None of it is legible yet to somebody holding forty applications and twelve minutes.
What you do
Lead with the numbers, because this is the one road where you have them. Write a single case study built on the cost and latency table: what it cost at the start, what it costs now, what you changed, and which change did nothing at all. Keep the change that did nothing. Anyone can list wins, and the dead end is what makes the wins believable. Put the incident note beside it, unedited apart from anything confidential, because an engineer reading it can tell within a paragraph whether you have carried a real system. Then fix the entry points. Every repository gets a README whose first screen says what it is, what it proved and how to run it, with a recording so nobody installs anything to see it work. Link the deployed service if it is safe to leave running, and if it is not, say so in one line, because knowing when to take something down is also part of the job. Rewrite your CV against the brief from stage one using the language from the postings you collected. Then have an engineer who does not know your work read the set and tell you what they think you operated.
Done when
- One case study leads with before and after numbers and names a change that did nothing.
- The incident note is published alongside it, with only confidential details removed.
- Every repository README's first screen says what it is, what it proved and how to run it.
- A recording exists for each artifact, so nothing needs installing to be evaluated.
- An engineer outside your team has read the set and correctly described what you operated.
What you end up with
A portfolio read in twelve minutes: a cost and latency case study naming a change that did nothing, a published incident note, and repositories with honest READMEs.
If you get stuck
The quiet failure is leaving the deployed service running with no cap and no attention for months, which turns a portfolio piece into a slow bill. Either keep it monitored or take it down and say why. The second failure is writing the case study as a clean list of improvements with no failures in it, which reads as marketing. The dead end you kept is the sentence a senior engineer will actually trust.