BQ-045 · SELF-GUIDED PRACTICE
Tell me about choosing mitigation before a permanent fix.
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 recovery of the core page after removing the optional panel’s demand and the decision that led to it.
Prepare a follow-up on shipping an unverified retry-code patch while the incident continued. 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.
- Explain the customer harm, the reversible containment choice, and how you kept a temporary mitigation from becoming an unowned permanent state.
- Can you explain the evidence behind recovery of the core page after removing the optional panel’s demand?
- Can you describe separating immediate containment from verified restoration without overstating the outcome?
Before you start
- Explain the customer harm, the reversible containment choice, and how you kept a temporary mitigation from becoming an unowned permanent state.
- Separate personal actions from team outcomes.
Choose an experience that answers the prompt
Suitable examples
- A reversible mitigation with a real customer trade-off.
- An incident where root-cause certainty came after stabilization.
Examples to avoid
- Treating a disabled feature as a completed permanent fix.
- Claiming causality solely because an incident became quiet.
Gather your evidence
- Explain the customer harm, the reversible containment choice, and how you kept a temporary mitigation from becoming an unowned permanent state.
- Your decision, the alternative of shipping an unverified retry-code patch while the incident continued, and the reason for the choice.
- The observations that support recovery of the core page after removing the optional panel’s demand and their limitations.
Build the answer
- Situation and responsibility. Explain the customer harm, the reversible containment choice, and how you kept a temporary mitigation from becoming an unowned permanent state.
- Actions and reasoning. Explain what you personally changed, who helped, and why you considered shipping an unverified retry-code patch while the incident continued.
- Outcome and evidence. Report recovery of the core page after removing the optional panel’s demand. Distinguish observation from an assumption or future goal.
- Reflection and follow-through. Explain separating immediate containment from verified restoration. 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
During a release, a new recommendation panel began making repeated calls to a catalog service. The extra load affected the main product page, even though recommendations were optional. I was the engineer investigating the new panel, while the incident lead coordinated the response. We had an early hypothesis about a retry loop, but the exact cause was not yet established. Customers needed the main page to work before we completed that investigation.
Why this paragraph works
Evidence: Customer harm, optional capability, and uncertain cause.
Why it matters: Makes the recovery priority concrete.
Prepare for a follow-up: Prepare who coordinated the incident and what you owned.
Actions and reasoning
I confirmed that the panel could be disabled independently and proposed turning off its feature flag. I explained that this would temporarily remove recommendations while preserving the core browsing task. Before changing it, we checked that the page had a valid no-panel state and that disabling it would not break a required checkout dependency. The incident lead approved the mitigation, and I watched request volume from the panel and the main page’s error behavior after the change.
Why this paragraph works
Evidence: A reversible flag change with dependency checks.
Why it matters: Shows a deliberate containment decision.
Prepare for a follow-up: Explain the fallback state and rollback approval.
Outcome and evidence
Calls from the disabled panel stopped, and the main-page path recovered during the incident observation window. That was evidence that containing the panel’s demand helped recovery; it did not prove the suspected retry loop was the root cause. We kept the flag off while reproducing the behavior. The later fix changed the retry handling, added a bounded-call check, and was tested before a gradual re-enable. I recorded separate owners for the incident closeout and the re-enable decision.
Why this paragraph works
Evidence: Recovery evidence separated from later diagnosis.
Why it matters: Avoids overstating what the mitigation proved.
Prepare for a follow-up: Prepare the re-enable criteria and owners.
Reflection and follow-through
I learned to separate a reversible recovery action from certainty about the diagnosis. Waiting for a complete explanation would have prolonged customer harm, but declaring success after disabling the panel would have left an important capability indefinitely unavailable. The useful outcome was service recovery followed by a tracked, verified restoration path. In an interview I would state the actual observation window and what remained uncertain at each stage.
Why this paragraph works
Evidence: An owned restoration path.
Why it matters: Connects short-term judgment with follow-through.
Prepare for a follow-up: Explain how the missing capability was tracked.
Reveal the concise version — roughly 60–90 seconds
A new recommendation panel overloaded a catalog dependency and affected the main product page. The retry-loop cause was still a hypothesis, so I proposed disabling the optional panel while investigating. We verified the no-panel state and checked that core browsing and checkout did not depend on it. With the incident lead’s approval, we disabled the flag and watched panel requests and main-page errors. The core path recovered during the observation window, but we did not call that proof of the exact cause. We kept a separate owner and acceptance checks for fixing and gradually re-enabling the panel. I learned that a temporary mitigation needs both a clear customer trade-off and an owned restoration plan.
Improve a weak answer
Weak excerpt
We turned the feature off, errors stopped, and that proved the retry loop was fixed.
Improved excerpt
I confirmed that the panel could be disabled independently and proposed turning off its feature flag. I explained that this would temporarily remove recommendations while preserving the core browsing task. Before changing it, we checked that the page had a valid no-panel state and that disabling it would not break a required checkout dependency. The incident lead approved the mitigation, and I watched request volume from the panel and the main page’s error behavior after the change.
Separates containment from causal diagnosis and gives restoration an owner and acceptance criteria. 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.
Why not fix the retry code immediately?
The exact fault was not yet reproduced, while disabling the optional demand source was understood and reversible. A hurried code change could have added another failure. Explain why the mitigation was safer in the available evidence, not that mitigation is always preferable.
What did customers lose?
They temporarily lost the recommendation panel, while the core browsing path remained available. That loss mattered and was communicated. A mitigation has a cost; calling a feature optional does not mean customers never value it.
Did recovery prove the root cause?
No. It supported the hypothesis that panel demand contributed to the incident. The retry-loop explanation still required reproduction and inspection. Distinguish containment evidence from a completed causal diagnosis.
How did you prevent the flag from staying off forever?
We assigned an owner, recorded the missing capability, and specified re-enable checks and a gradual rollout. A temporary control without a tracked next decision can quietly become permanent degradation.
What if turning off the panel had not helped?
We would compare the expected request reduction with observed behavior and continue the incident plan. The action’s reversibility and monitoring were important. I would not keep claiming a successful mitigation when the recovery signals did not change.
Adjust the evidence to your level
Early-career
Use a bounded project, internship, or volunteer example that demonstrates incident judgment. Explain guidance you received rather than claiming senior authority.
Mid-level
Show independent responsibility for a defined outcome, including recovery of the core page after removing the optional panel’s demand. Name dependencies and when you sought help.
Senior
Explain trade-offs with affected colleagues, the verification plan, and separating immediate containment from verified restoration. 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 shipping an unverified retry-code patch while the incident continued.
- Claiming recovery of the core page after removing the optional panel’s demand without describing how you observed it.
- Claiming sole credit for decisions or work owned by collaborators.
- Treating a proposed follow-up as already completed.