BQ-011 · SELF-GUIDED PRACTICE
Tell me about a commitment you could not meet.
Illustrative fictional example · Editorial draft, version 1. Use the structure and reasoning to prepare your own experience. Do not present this sample as your personal history.
Attempt before reading the example
Spend about two minutes explaining your own experience aloud, then use the worksheet. The sample stays closed until you choose to reveal it.
Build your own answer
This worksheet stays in this page’s memory. It is not saved to your account or this device. Copy or download it before leaving or refreshing. Remove confidential details and use only experiences you can defend.
Self-review against observable evidence
This is a coaching checklist, not a company hiring score. Choose one rating per dimension.
Review each dimension to choose one concrete improvement for your next attempt.
Next exercise
Rehearse your own example, then ask a listener to identify a corrected interaction verified before the rescheduled demonstration and the decision that led to it.
Prepare a follow-up on presenting a limited demonstration with explicit exclusions. Replace every fictional detail with your own facts and identify one claim that needs more evidence.
What the interviewer may evaluate
These are general coaching criteria; interviewers and roles differ.
- Name the commitment you made, the assumption you owned, and how you communicated and repaired the miss.
- Can you explain the evidence behind a corrected interaction verified before the rescheduled demonstration?
- Can you describe including verification work before committing to a date without overstating the outcome?
Before you start
- Name the commitment you made, the assumption you owned, and how you communicated and repaired the miss.
- Separate personal actions from team outcomes.
Choose an experience that answers the prompt
Suitable examples
- A commitment you personally made or endorsed.
- A miss where you communicated impact and a revised plan.
Examples to avoid
- Blaming testers for discovering a legitimate defect.
- A deadline you never actually agreed to meet.
Gather your evidence
- Name the commitment you made, the assumption you owned, and how you communicated and repaired the miss.
- Your decision, the alternative of presenting a limited demonstration with explicit exclusions, and the reason for the choice.
- The observations that support a corrected interaction verified before the rescheduled demonstration and their limitations.
Build the answer
- Situation and responsibility. Name the commitment you made, the assumption you owned, and how you communicated and repaired the miss.
- Actions and reasoning. Explain what you personally changed, who helped, and why you considered presenting a limited demonstration with explicit exclusions.
- Outcome and evidence. Report a corrected interaction verified before the rescheduled demonstration. Distinguish observation from an assumption or future goal.
- Reflection and follow-through. Explain including verification work before committing to a date. Name one limitation or remaining follow-up.
Full sample answer and paragraph explanations
Read aloud to check pacing. Expand the annotations to see why each paragraph matters and which detail belongs in a follow-up.
Reveal the full illustrative answer
Situation and responsibility
I committed to making a new account settings page ready for a partner demonstration. I had estimated the form and API work, but treated accessibility verification as a final check rather than part of implementation. During keyboard testing, we found that a shared dialog trapped focus and made part of the page unusable. I owned the estimate and should have included that verification earlier. The original commitment could not be met safely.
Why this paragraph works
Evidence: A personal estimation omission and its consequence.
Why it matters: Admits responsibility before describing recovery.
Prepare for a follow-up: Explain what was known about the interaction at estimation time.
Actions and reasoning
I told the product owner as soon as we understood the issue, rather than waiting for the demonstration date. I explained what was complete, what failed, and which users would be affected. I proposed two options: move the full demonstration, or demonstrate the supported non-dialog flow while clearly identifying the unavailable part. I recommended moving the full demonstration because presenting the broken flow as ready would create a false expectation. I also obtained help from the shared-component owner on the focus behavior.
Why this paragraph works
Evidence: Prompt communication and explicit options.
Why it matters: Shows stakeholders could still make a decision.
Prepare for a follow-up: Prepare the reason for choosing a rescheduled demonstration.
Outcome and evidence
We agreed on a revised demonstration plan and separate acceptance checks for keyboard operation and screen-reader labeling. I supplied a progress update after each check instead of making another unsupported date promise. The corrected flow passed the agreed checks before the rescheduled demonstration. The partner still experienced a delay, and the product owner had to adjust their communication. I did not treat the eventual fix as evidence that the original commitment was acceptable.
Why this paragraph works
Evidence: Acceptance checks and acknowledgment of the delay.
Why it matters: Does not let eventual delivery erase the missed commitment.
Prepare for a follow-up: Name who approved readiness and what remained limited.
Reflection and follow-through
I changed my estimation checklist to include accessibility and shared-component risks before committing to a delivery date. On the next settings change, I tested the interaction pattern early enough to adjust the estimate. The lesson was to own the missing work in my plan and provide stakeholders with usable choices when a commitment becomes unreliable, rather than simply saying that testing found an unexpected problem.
Why this paragraph works
Evidence: A specific change to estimation behavior.
Why it matters: Connects the lesson to a later decision.
Prepare for a follow-up: Explain what early verification looked like on the next change.
Reveal the concise version — roughly 60–90 seconds
I missed a commitment to have a settings page ready for a partner demonstration. I had estimated the form and API work but left accessibility verification until the end. Keyboard testing exposed a focus trap in a shared dialog, so the page was not ready to demonstrate as a complete experience. I told the product owner promptly, explained the affected flow, and proposed either moving the full demonstration or showing a clearly limited flow. We rescheduled, involved the component owner, and agreed on explicit interaction checks before proceeding. The fix passed those checks, but the delay still affected the partner and was my responsibility to explain. I now include accessibility and shared-component verification in the estimate before committing.
Improve a weak answer
Weak excerpt
Testing found a last-minute problem, so the date slipped. Once we fixed it, everything was fine.
Improved excerpt
I told the product owner as soon as we understood the issue, rather than waiting for the demonstration date. I explained what was complete, what failed, and which users would be affected. I proposed two options: move the full demonstration, or demonstrate the supported non-dialog flow while clearly identifying the unavailable part. I recommended moving the full demonstration because presenting the broken flow as ready would create a false expectation. I also obtained help from the shared-component owner on the focus behavior.
Owns the missing verification in the estimate and gives stakeholders explicit choices; eventual delivery does not erase the miss. The improved excerpt still needs the observed result and its limits to become a complete answer.
Prepare for probing questions
Attempt each response before opening the guidance. Replace fictional details with your own evidence.
When did you communicate the risk?
As soon as the issue made the original promise unreliable, with a specific explanation of what was known and still being investigated. Earlier uncertainty should also have been visible. Waiting until every detail is solved prevents stakeholders from making useful choices.
Why not just show the working parts?
That was an option if the demonstration was explicitly limited and the partner’s goal could still be met. In this example the goal was to review the full interaction, so moving it was clearer. The point is to expose the trade-off rather than hide an unavailable flow.
Was the shared component team to blame?
No. Their component needed a correction, but I owned the estimate and the decision to defer verification. I asked them to help diagnose the behavior instead of using their ownership as an excuse for my commitment.
How did you rebuild confidence in the revised plan?
I replaced a broad ready-by promise with visible checks, owners, and progress updates. Once the interaction was corrected, we verified the agreed paths before demonstrating them. Confidence came from evidence and transparency, not a more forceful promise.
What did you change in future estimates?
I identified interaction risks and tested shared patterns earlier. In a real answer I would provide a later example showing that habit. A checklist alone is a mechanism; claiming that every subsequent delivery became on time would require broader evidence.
Adjust the evidence to your level
Early-career
Use a bounded project, internship, or volunteer example that demonstrates accountability. Explain guidance you received rather than claiming senior authority.
Mid-level
Show independent responsibility for a defined outcome, including a corrected interaction verified before the rescheduled demonstration. Name dependencies and when you sought help.
Senior
Explain trade-offs with affected colleagues, the verification plan, and including verification work before committing to a date. Broader scope needs evidence rather than a larger job title.
Staff
Show a mechanism that changed decisions or capability across teams, including who adopted it and what remained outside your authority. Do not describe a local change as organization-wide influence.
Common mistakes
- Listing tasks without explaining why you considered presenting a limited demonstration with explicit exclusions.
- Claiming a corrected interaction verified before the rescheduled demonstration without describing how you observed it.
- Claiming sole credit for decisions or work owned by collaborators.
- Treating a proposed follow-up as already completed.