BQ-028 · Failure, feedback, and growth
Describe an assumption you discovered was wrong.
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.
What the interviewer may evaluate
These are general coaching criteria; interviewers and roles differ.
- Explain why an assumption initially seemed reasonable, which evidence contradicted it, and how your decision changed.
- Can you explain the evidence behind a revised design supported by a reproduced access-pattern cause?
- Can you describe making falsifiable performance hypotheses without overstating the outcome?
Before you start
- Explain why an assumption initially seemed reasonable, which evidence contradicted it, and how your decision changed.
- Separate personal actions from team outcomes.
Choose an experience that answers the prompt
Suitable examples
- Explain why an assumption initially seemed reasonable, which evidence contradicted it, and how your decision changed.
- An experience where you can distinguish your decision from the work owned by other people.
Examples to avoid
- I knew caching was the answer because every slow API benefits from a cache.
- An example whose outcome you cannot distinguish from a plan or an assumption.
Gather your evidence
- Explain why an assumption initially seemed reasonable, which evidence contradicted it, and how your decision changed.
- Your decision, the alternative of adding a cache before checking the source of repeated database work, and the reason for the choice.
- The observations that support a revised design supported by a reproduced access-pattern cause and their limitations.
Build the answer
- Situation and responsibility. Explain why an assumption initially seemed reasonable, which evidence contradicted it, and how your decision changed.
- Actions and reasoning. Explain what you personally changed, who helped, and why you considered adding a cache before checking the source of repeated database work.
- Outcome and evidence. Report a revised design supported by a reproduced access-pattern cause. Distinguish observation from an assumption or future goal.
- Reflection and follow-through. Explain making falsifiable performance hypotheses. 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 assumed a slow dashboard needed a caching layer because several requests repeated similar calculations. I owned the performance investigation and had seen the endpoint spend time in a database call. Before proposing cache infrastructure, I captured a representative request breakdown and examined the actual query. That evidence showed repeated per-row lookups rather than one expensive calculation shared across users.
Why this paragraph works
Evidence: A plausible assumption stated honestly.
Why it matters: Identifies a relevant situation and your responsibility before describing the solution.
Prepare for a follow-up: Prepare this follow-up: Why did caching seem plausible?
Actions and reasoning
I discussed the traces with a colleague and reproduced the query pattern using synthetic accounts with different row counts. The request count grew with the number of rows, and the requested data could be fetched in a bounded batch. I changed my recommendation from adding a cache to correcting the access pattern. I also explained to the product owner that the original plan was a hypothesis, not a commitment justified by completed measurement.
Why this paragraph works
Evidence: Contrary evidence and a changed recommendation.
Why it matters: Makes a decision and its reasoning visible rather than listing activities.
Prepare for a follow-up: Prepare this follow-up: What contradicted the assumption?
Outcome and evidence
We implemented a batched lookup, verified the same response shape, and compared query count and request behavior on the tested sizes. The number of lookups no longer grew one-for-one with rows in those cases. The endpoint still had other costs, so I did not claim caching was never useful or that all dashboard performance was solved. We retained measurements for later decisions rather than introduce a cache merely to preserve my initial proposal.
Why this paragraph works
Evidence: Bounded compatibility and query verification.
Why it matters: Connects the claimed result to observations and acknowledges their limits.
Prepare for a follow-up: Prepare this follow-up: How did you communicate the reversal?
Reflection and follow-through
I learned to separate an observed slow database call from the explanation I attached to it. The assumption was plausible, but the request breakdown changed the relevant design choice. I now write the hypothesis and the observation that would contradict it before proposing performance infrastructure. That helps me change direction without treating new evidence as a threat to my credibility or hiding the earlier recommendation.
Why this paragraph works
Evidence: A repeatable hypothesis discipline.
Why it matters: Turns the experience into a concrete changed habit or mechanism.
Prepare for a follow-up: Prepare this follow-up: How did you verify improvement?
Reveal the concise version — roughly 60–90 seconds
I initially thought a slow dashboard needed caching because requests repeated similar work. Tracing showed a different cause: per-row database lookups grew with result size. I reproduced the pattern with synthetic accounts, discussed it with a colleague, and changed the recommendation to a batched access pattern. We checked response compatibility and lookup behavior across representative sizes. The repeated lookup growth disappeared in those cases, while other costs remained. I did not conclude caching was universally wrong. The lesson was to distinguish a slow call from its cause and make the evidence that could disprove my hypothesis explicit before selecting infrastructure.
Improve a weak answer
Weak excerpt
I knew caching was the answer because every slow API benefits from a cache.
Improved excerpt
I discussed the traces with a colleague and reproduced the query pattern using synthetic accounts with different row counts. The request count grew with the number of rows, and the requested data could be fetched in a bounded batch. I changed my recommendation from adding a cache to correcting the access pattern. I also explained to the product owner that the original plan was a hypothesis, not a commitment justified by completed measurement.
The improved excerpt explains a specific decision rather than the unsupported claim in the weak version. Complete it with a revised design supported by a reproduced access-pattern cause, and state the limits of what you observed.
Prepare for probing questions
Attempt each response before opening the guidance. Replace fictional details with your own evidence.
Why did caching seem plausible?
The requests repeated similar-looking work and database time was visible. Those observations justified a hypothesis, not a causal conclusion. I explained the initial reasoning instead of pretending I had always known the actual issue.
What contradicted the assumption?
The lookup count grew with rows, and the data could be fetched in a batch. That changed the solution boundary from shared-result reuse to request-local access behavior.
How did you communicate the reversal?
I showed the trace, the original hypothesis, and the revised recommendation. Framing earlier work as investigation rather than certainty made the change understandable without concealing it.
How did you verify improvement?
I compared lookup count and response behavior at representative sizes while preserving the contract. A real latency claim would need comparable measurements; reduced query count alone does not establish every performance effect.
Could caching still be useful?
Yes, for a separately demonstrated reuse pattern with acceptable freshness and operating cost. The lesson is evidence-led selection, not replacing one universal technology preference with another.
Adjust the evidence to your level
Early-career
Use a bounded project, internship, or volunteer example that demonstrates learning. Explain guidance you received rather than claiming senior authority.
Mid-level
Show independent responsibility for a defined outcome, including a revised design supported by a reproduced access-pattern cause. Name dependencies and when you sought help.
Senior
Explain trade-offs with affected colleagues, the verification plan, and making falsifiable performance hypotheses. 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 adding a cache before checking the source of repeated database work.
- Claiming a revised design supported by a reproduced access-pattern cause without describing how you observed it.
- Claiming sole credit for decisions or work owned by collaborators.
- Treating a proposed follow-up as already completed.
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 revised design supported by a reproduced access-pattern cause and the decision that led to it.
Prepare a follow-up on adding a cache before checking the source of repeated database work. Replace every fictional detail with your own facts and identify one claim that needs more evidence.