A Selected-Work Block for the System You Know Best
The bullet format has a hard limit: two lines. That is enough for a decision, a mechanism, and a change of state, and it is not enough for a system — its constraints, the option you rejected, and the thing that turned out to be difficult.
So senior resumes end up with fifteen bullets that each gesture at something interesting and never land on one. The alternative is a short named block, before or just after the experience section, that describes a single piece of work properly.
What the block is
Four to six lines about one system you know better than anything else on the page. Not a portfolio, not a case study, not a link — text, on the resume, in the same typeface as everything else.
Selected work — tenant isolation for the reporting API A shared reporting service where one tenant’s heavy query could exhaust the connection pool and slow every other tenant’s dashboards. Constraints: no per-tenant infrastructure (the cost model wouldn’t carry it), no change to the public query interface, and a fixed budget of one engineer for a quarter. Approach: admission control at the API boundary keyed on tenant, a separate pool for queries over an estimated-cost threshold, and per-tenant concurrency limits derived from their plan. Trade-off: chose queueing over rejection, which meant slow queries got slower rather than failing — acceptable for a reporting workload, and it would have been the wrong choice on an interactive path. Result: the class of incident where one tenant degraded everyone stopped occurring; the on-call runbook entry for it was deleted.
An illustration, not a real system. But notice what a reader gets from it that no bullet could carry: a problem with a cause, three named constraints, a rejected alternative with the reason, and a limit on the claim.
Why it outperforms bullets at senior level
It shows judgement rather than asserting it. Every senior resume claims to make good technical decisions. This is the only format on a resume with room to demonstrate one, because a demonstration needs the alternative in it.
It gives the interview somewhere to go. A reviewer who reads this block has three questions ready, all of them about work you know cold. That is a much better opening than a scan of bullets producing “so tell me about your experience with Kafka”.
It solves the depth problem in one place. As the questions a technical reviewer is trying to answer sets out, depth is the hardest thing to evidence and the thing most resumes never answer. One block answers it permanently, which frees the rest of your bullets to be about scope and ownership.
It is very hard to fake. Anyone can write “designed a scalable microservices architecture”. Nobody can write a specific constraint, a rejected option, and a stated limitation about a system they didn’t work on. Technical readers know this, and the block reads as credible for exactly that reason.
The five lines, and what each is for
The problem. What was wrong, in system terms, with a cause rather than a symptom. “Slow dashboards” is a symptom; “one tenant’s query exhausting a shared pool” is a cause.
The constraints. This is the line people skip and it is the most valuable one. Cost, compatibility, headcount, deadline, an interface you couldn’t change, data you couldn’t move, a regulation. Constraints are what make an engineering decision an engineering decision rather than a preference, and stating them tells the reader you were operating in reality.
The approach. Mechanism, not technology roster. Name a tool only where the choice was the substance — the same discipline as name the problem, not just the tool.
The trade-off. What you gave up, and the condition under which your choice would have been wrong. This single line does more for a senior application than anything else on a resume. It shows you understood the shape of the decision rather than having found one thing that worked.
The outcome, bounded. What changed, at the scope you can actually defend. A class of incident that stopped. A migration that completed. A team that stopped being paged. If you have a defensible number, use it; if you don’t, describe the state change, which is the argument in when the numbers belong to another team.
Where it goes, and what it costs
Directly under the summary, before the experience section, if the work is your strongest asset and the role is a close match. After the experience section if your recent employers and titles are doing more work than the system is.
It costs six lines, which means something else leaves. Usually that’s fine: the six weakest bullets scattered across your older roles were carrying almost nothing. If you can’t find six lines to cut, the resume has a different problem and what belongs on an engineering resume is the place to start.
One block. Two at the absolute most, if they demonstrate genuinely different things — a system and a migration, say. Three is a portfolio pretending to be a resume, and at that point the block has stopped being selective, which was its entire advantage.
Choosing the system
Not the most impressive one. The one you know best, which is usually the one that went wrong in an interesting way.
Three questions to pick it:
- Could you draw it on a whiteboard, from memory, including the parts you’d forgotten about until you started drawing?
- Can you name a decision you’d make differently now, and say why?
- Was there a constraint that made the obvious solution unavailable?
A yes to all three means the block will write itself and the conversation about it will go well. A no to the third usually means the work was unconstrained, which makes for a weaker block even if the system was larger.
What it must not become
A paragraph. Line-broken, labelled, scannable. A prose block in the middle of a resume does not get read.
A pitch. No adjectives about the system’s importance. “Business-critical”, “high-performance”, and “at scale” are all claims where the constraint line should be.
Confidential. Describe the shape, not the internals: the pattern, the trade-off, and the failure mode, without proprietary detail, customer names, or specifics your employer would object to seeing. Almost every system can be described this way, and the version that survives the redaction is usually the more interesting one anyway.
A substitute for the experience section. The block is evidence of depth. The experience section is still where scope, ownership, and progression live — see the staff-level resume problem for the rest of that page.
The test
Show the block to an engineer who doesn’t work with you and ask them what you’d have to be good at to have done it.
If the answer is a specific technical judgement — capacity, isolation, consistency, sequencing — the block works. If the answer is “building microservices”, it’s still a bullet in disguise and the constraint line is the thing that’s missing.