Appendix F - Behavioral Question Bank

The first question is rarely the whole question

“Tell me about a time you disagreed with someone” sounds like a request for a story about conflict. The follow-ups may reveal a more exact interest: whether you understood the other position, what authority you had, which evidence could change your mind, how the decision was made, or whether the relationship still worked afterward.

Use this bank to retrieve real experience and expose its weak points. Do not write an answer for every prompt. Choose a story, speak from a few evidence notes, and let the probes test whether the story contains enough judgment to carry an interview.

The same event may answer several questions, but it should not give the same answer to all of them. A migration can be a delivery story when the hinge is a scope decision, an influence story when another team bears the cost, or a failure story when an assumption survives too long. Choose the event whose decision matches the question.

Ownership and ambiguity

These questions look for motion without overreach. Make the unresolved risk specific, separate your authority from the authority of others, and show how you made the work governable.

1. Tell me about a time you took ownership of an unclear problem. What exactly was unknown? Which uncertainty could safely remain?
2. Describe a project that had no obvious owner. What did you take on temporarily? Who owned the outcome afterward?
3. Tell me about a decision you made with incomplete information. What evidence did you have, and what would have caused you to reverse the decision?
4. When did you challenge the way a problem had been framed? What did the original framing miss? Who had to accept the new one?
5. Tell me about work you deliberately refused or stopped. What consequence did you protect, and how did you handle the disappointed stakeholder?

A weak ownership story expands until the candidate appears to run the whole organization. A credible one names the boundary crossed, why crossing it was necessary, and the mechanism—an experiment, owner map, decision record, or launch criterion—that prevented permanent invisible ownership.

Delivery and product judgment

Deadline stories become useful when every option costs something. State whose outcome was at risk, what you protected, and what you knowingly left for later.

1. Tell me about a deadline that forced a hard trade-off. What did you cut? Which quality or safety guardrail remained nonnegotiable?
2. Describe a time technical quality and product urgency pulled in different directions. Who could accept the risk? How was the debt or follow-up made real?
3. Tell me about a project that was slipping. When did you know? What did you communicate before you had a recovery plan?
4. Describe a decision that disappointed a customer or stakeholder in the short term. What larger harm were you avoiding? What evidence supported that choice?
5. Tell me about a launch you delayed—or one you chose not to delay. Which signal decided it? What rollback or containment option existed?

Do not turn schedule pressure into a story in which quality simply wins. Senior delivery judgment often means preserving one invariant while reducing scope, sequencing risk, or making an explicit and reversible compromise.

Technical and production judgment

The interviewer does not need a second system-design presentation. Give only enough architecture to make the choice and its operating consequences clear.

1. Tell me about an important technical decision you influenced. Which alternative nearly won? What would have changed your recommendation?
2. Describe a time you chose a simpler design. Which future need did you decline to optimize for? How would you know when simplicity stopped being enough?
3. Tell me about a migration or rollout with meaningful risk. What was the irreversible step? How did you compare old and new behavior?
4. Describe an incident that changed your technical judgment. Which earlier assumption failed? What mechanism changed after the review?
5. Tell me about technical debt you chose to pay down. What present cost justified the work? Why then, instead of sooner or later?
6. Describe a reliability concern that changed a product plan. Which failure did you still accept? Who owned the launch decision?

“We added a queue” or “we rewrote the service” is a starting condition, not evidence of judgment. Keep the requirement, rejected alternative, new failure mode, and result visible. If the result is an inference from one incident or a short observation window, say so.

Influence and conflict

Influence is not the ability to make reluctant people agree. Strong stories preserve the other party’s reasonable incentives and show what changed in the work after the conversation.

1. Tell me about a time you influenced another team without authority. What cost did your proposal impose on them? What did you change or give up?
2. Describe a serious technical disagreement. What did the other person believe that was reasonable? Which decision rule resolved it?
3. Tell me about a stakeholder whose priorities conflicted with yours. Did you change their mind, change your plan, or escalate a decision—and why?
4. Describe a proposal that initially failed to gain support. What was wrong with the first version? What evidence made the next decision easier?
5. Tell me about a cross-team commitment that broke down. How did you separate a relationship problem from an ownership or planning problem?
6. Describe a time you disagreed and did not get your way. What did you do after the decision? Under what condition would you reopen it?

Consider an identity team already committed to reliability work when a checkout team requests an API change for a compliance launch. “I explained that our request was urgent” makes the partner team scenery. A stronger influence story begins with their legitimate constraint. The candidate might offer two options, narrow the request to one endpoint behind a feature flag, own the integration tests, and defer a larger cleanup. The useful probes then become obvious: why should the identity team trust the deadline, who accepted the residual risk, what did the checkout team contribute, and what happened after launch?

Mentoring and raising the bar

The result of mentoring belongs partly to someone else. Avoid claiming a colleague’s growth as your achievement; show the environment, feedback, or mechanism you improved and the evidence you could actually observe.

1. Tell me about someone you helped grow. What did they want? What changed in their behavior rather than merely in your opinion of them?
2. Describe a standard you raised across a team. What recurring mechanism carried it after your personal attention moved elsewhere?
3. Tell me about feedback you gave that was difficult to hear. Which behavior and consequence did you name? What happened in the next encounter?
4. Describe a time your attempt to help was ineffective. What assumption did you make about what the other person needed?
5. Tell me about work you delegated that you could have completed faster yourself. How did you bound the risk without taking the work back?

Keep management boundaries visible. A peer can pair, review, share context, or name a missed handoff. Formal performance expectations, staffing, accommodations, and sustained support usually belong to a manager or another authorized owner.

Failure, feedback, and changed practice

Choose failures with a real cost and a contribution you can own. A disguised success story protects the candidate from the very evidence these questions seek.

1. Tell me about a mistake you made. When could you first have detected it? What did the correction cost?
2. Describe a project that failed to achieve its intended result. Which part was execution, which part was the original bet, and which part remains uncertain?
3. Tell me about difficult feedback that changed how you work. What made it credible? What later behavior could another person observe?
4. Describe a strained working relationship you improved. What did you initially get wrong? What changed in the next interaction?
5. Tell me about an opinion you held strongly and later changed. Which evidence defeated the old view? What limit does the new view have?
6. Describe a failure you could not fully repair. How did you communicate the remaining consequence? What prevention exists now?

A specific changed practice is stronger than a moral. “I now require consumer contract tests before shadow traffic” can be inspected. “I learned that communication matters” cannot.

The probes beneath almost every question

Once the opening answer is coherent, stop asking more primary questions. Ask the probes that make unsupported stories fail:

• What did you personally decide, build, write, organize, or communicate?
• What belonged to the team, a partner, a manager, or another decision owner?
• What credible alternative did you reject, and by which criterion?
• What did you know then, before the outcome made the decision look obvious?
• How do you know what changed, and what does the evidence not prove?
• What went wrong, or remained imperfect, after the apparent success?
• What would a reasonable critic say about your account?
• What rule, mechanism, or habit changed in your later work?

If a story collapses under one of these, do not decorate the answer. Repair the evidence card or choose a different event.

Build coverage without scripting a catalogue

Prepare a small set of stories with different kinds of resistance: ambiguous ownership, a delivery trade-off, a technical or production decision, cross-team influence, a mistake, and feedback that changed your practice. Add a mentoring or bar-raising story if the role expects substantial technical leadership.

For each story, keep a short card with:

• the stakes and the constraint that shaped the decision;
• your contribution boundary;
• two reasonable options and the criterion you used;
• observable actions rather than “alignment” or “leadership” as labels;
• the result, its evidence, and its limits; and
• the later behavior that changed.

An unusually rich project can support several question families, but keep at least one small event in reserve. A focused code-review disagreement or a missed handoff can reveal more judgment than a year-long transformation whose causal chain no longer fits into an answer.

Rehearse for interruption

Choose one question at random and answer it in roughly ninety seconds. Keep the context short enough that the decision arrives early. Then have a partner interrupt with three probes: one about ownership, one about the rejected alternative, and one about the limits of the result.

On the next pass, answer the same question from evidence notes without repeating the same wording. On the final pass, shorten it while preserving the stakes, responsibility boundary, decision, and defensible result. If changing the wording changes the facts, the answer has become a script. If every probe requires retelling the entire event, the story card has not isolated its decision.

The aim is not a perfect past or a polished monologue. It is an account sturdy enough for another engineer to inspect.

Related links

• Build the Senior Story Bank
• The Senior Story Spine
• Ownership and Ambiguity
• Influence Without Authority
• Feedback and Difficult Working Relationships
• Project Dossier Template