Senior Engineering Interview Handbook / Chapter 121
Build the Senior Story Bank
A practical method for recovering useful stories, recording their evidence and limits, balancing coverage, and testing retrieval without writing scripts.
Page tools
Begin with memory, not prompt labels
Asked for an example of influence, many candidates remember the story they have already practiced. Asked next about disagreement, they remember the same project and change the emphasis. By the third reuse, a substantial career has shrunk to one launch.
The remedy is not twelve polished answers. It is a private index of events you can retrieve before polish begins. A good bank contains enough of the event to survive questions about consequence, contribution, alternatives, evidence, and what changed afterward. It also records what must remain private. The spoken answer comes later.
Begin with concrete nouns from roughly the last five years: the queue that backed up, the proposal that lost review, the launch cut in half, the teammate who began owning a design review, the alert everyone had learned to ignore. Write twenty such labels without sorting them into interview categories. The labels need only be specific enough to restore the scene:
partner retry migration
mobile release rollback
API review standard
schema dependency miss
support escalation handoff
review habit coaching
Prompt-first notes such as “conflict story” or “leadership example” erase the very detail you will later need. Recover events first. Classify them only after you can say what actually happened.
Turn each event into an evidence card
Most raw memories will not earn a place in the final bank. Give each plausible one a short card:
Label:
Situation and stakes:
My contribution boundary:
Hinge:
Evidence and limits:
Changed practice:
Safe version:
Prompt reach:
The hinge is the moment the story could have gone another way: a reasonable alternative, a disagreement, a missed assumption, a constraint that forced a cut, or new evidence that changed the plan. Without a hinge, an achievement often collapses into chronology. “We migrated the service and it went well” may be true, but it gives an interviewer little judgment to inspect.
The contribution boundary separates your work from the team’s. Use verbs that can withstand a follow-up: designed, implemented, proposed, reviewed, influenced, advised, or recovered. “Led” and “owned” are useful only when the card says what they included and excluded.
Evidence may be a metric, an incident record, an adoption pattern, a launch result, a review artifact, or a stakeholder observation. Record its limit in the same line. That prevents an observed improvement from becoming a causal claim during rehearsal.
The changed practice is not a moral. “Communication matters” tells you nothing about what the event taught. “External readiness now requires a named owner, a testable artifact, and a date” is a rule you could use on the next project.
Work one card until it is honest
Suppose the raw label is API standard adoption. At first the memory may be:
I convinced three teams to adopt a shared API standard, which reduced review
problems and made integrations more consistent.
That sentence has a favorable result but almost no inspectable evidence. Which review problems? Why did the teams resist? Was adoption voluntary? What part did you do? Did consistency actually improve for clients?
After returning to design notes and review history, the card might become:
Label: narrow API error contract
Situation and stakes: Three service teams represented the same retryable
failure differently, so client teams kept rediscovering handling rules.
My contribution boundary: I proposed the contract and ran integration reviews;
service owners decided whether and when to adopt it.
Hinge: A broad platform standard promised consistency but made migration too
expensive. We narrowed the contract to the repeated failure mode.
Evidence and limits: Three teams adopted the narrow contract and repeat review
comments declined. This did not remove every client-specific error path.
Changed practice: Start a standard at a pain teams already recognize, then
expand only when another concrete case requires it.
Safe version: Remove service and customer names; preserve retry semantics and
the voluntary adoption boundary.
Prompt reach: influence, disagreement, technical decision, cross-team work
The revised card is less triumphant and more useful. It preserves the skeptical teams’ valid objection, identifies the mechanism of influence, and stops where the evidence stops. It can answer several prompt families, but it cannot honestly answer everything.
Build a portfolio with range
Once the viable cards exist, tag each with no more than two to four prompt families. Then look across the bank rather than down a single card. You need evidence for major impact, ambiguity, a difficult technical choice, disagreement, influence without authority, mentoring, failure or a missed commitment, an incident or quality problem, technical debt, cross-functional work, a customer or business trade-off, and strategic or ethical judgment.
Those are coverage needs, not slots that each require a different story. A production migration may cover ambiguity, technical choice, and customer trust. A missed dependency may cover failure and cross-functional work. Yet a bank assembled from one project still has a range problem even if its tags fill every category. Find substitute stories for the prompts most likely to pull you back to the same project.
Aim for twelve to sixteen usable cards. The number is a practical constraint, not a badge. A smaller bank leaves common probes dependent on one example; a much larger one becomes hard to retrieve. Retire a card when your role was too peripheral, the evidence is inaccessible, the useful version cannot be shared safely, or the event contains heat but little engineering judgment.
Include imperfect outcomes deliberately. A credible miss might involve a weak estimate, an untested dependency, a late escalation, a rollout assumption, or an incident response that preserved data but failed operators. Record what you owned, what you did not own, what you repaired, and the rule that changed. Do not choose catastrophe for drama, and do not disguise a team failure as your personal confession.
Write the safe version before rehearsal
When a useful story is sensitive, decide the boundary while you are calm. A safe version should generalize identifiers without destroying the technical shape.
Details I can share:
Details I must generalize:
Safe substitute language:
Technical truth I must preserve:
“A regulated workflow with partner retries and audit requirements” preserves more judgment than “a backend project.” Exact customer names, volumes, schemas, source code, security posture, personnel details, and proprietary processes can remain private. The constraints, alternatives, interfaces, and consequences can often remain precise.
If generalization makes the decision impossible to explain, do not force the story into the bank. Choose another event.
Test retrieval, then repair the cards
A bank is ready when it works under interruption. Give a peer a set of common prompts and ask for them in random order. Choose a card within ten seconds, but do not tell the full story yet. Explain only why that card fits and name a second choice. Slow selection reveals a missing label or weak coverage before you waste time polishing an answer.
Next, let the peer choose four cards and ask only:
- What did you personally contribute?
- What was the best rejected option?
- What evidence supports the result?
- What can you not fairly claim?
- What did you do differently later?
Repair the card that fails, not the wording of the answer. If the evidence is not recoverable, retire it. If every prompt selects the same project, widen the portfolio. If a sensitive question makes you freeze, improve the safe version.
Stop when the bank is small enough to scan, broad enough to avoid compulsive reuse, and deep enough that the first follow-up restores detail rather than exposing invention. The next chapter will turn one of these cards into a spoken story. For now, keep the evidence compressed and the prose unwritten.