BQ-050 · Mentoring, delegation, and team leadership
Describe giving constructive feedback that was difficult to deliver.
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.
- Describe an observable behavior and its impact, how you discussed it respectfully, and what support and follow-up you agreed.
- Can you explain the evidence behind an earlier review that exposed a compatibility assumption before cutoff?
- Can you describe giving behavior-specific feedback with practical shared commitments without overstating the outcome?
Before you start
- Describe an observable behavior and its impact, how you discussed it respectfully, and what support and follow-up you agreed.
- Separate personal actions from team outcomes.
Choose an experience that answers the prompt
Suitable examples
- Describe an observable behavior and its impact, how you discussed it respectfully, and what support and follow-up you agreed.
- An experience where you can distinguish your decision from the work owned by other people.
Examples to avoid
- I told them their pull requests were bad and they needed to be more professional.
- An example whose outcome you cannot distinguish from a plan or an assumption.
Gather your evidence
- Describe an observable behavior and its impact, how you discussed it respectfully, and what support and follow-up you agreed.
- Your decision, the alternative of publicly labeling the engineer careless without investigating the pattern, and the reason for the choice.
- The observations that support an earlier review that exposed a compatibility assumption before cutoff and their limitations.
Build the answer
- Situation and responsibility. Describe an observable behavior and its impact, how you discussed it respectfully, and what support and follow-up you agreed.
- Actions and reasoning. Explain what you personally changed, who helped, and why you considered publicly labeling the engineer careless without investigating the pattern.
- Outcome and evidence. Report an earlier review that exposed a compatibility assumption before cutoff. Distinguish observation from an assumption or future goal.
- Reflection and follow-through. Explain giving behavior-specific feedback with practical shared commitments. 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
A teammate repeatedly submitted large pull requests shortly before a release cutoff, leaving reviewers little time to examine risky changes. I reviewed several of those requests and was also responsible for one dependent release. I needed to discuss the pattern without treating speed or ambition as a character flaw. The concern was that important assumptions were reaching review when there was little room to change them.
Why this paragraph works
Evidence: A specific pattern and work impact.
Why it matters: Identifies a relevant situation and your responsibility before describing the solution.
Prepare for a follow-up: Prepare this follow-up: Why speak privately?
Actions and reasoning
I asked for a private conversation and used two concrete examples where late scope made review difficult. I explained the effect on release risk and reviewers, then asked what was driving the timing. They described uncertainty about when a partial change was worth sharing. We agreed on earlier design questions and smaller reviewable slices, with a short planning check for changes that could not be separated safely. I offered to review an early outline rather than wait for a completed implementation.
Why this paragraph works
Evidence: Private examples and diagnosis of the obstacle.
Why it matters: Makes a decision and its reasoning visible rather than listing activities.
Prepare for a follow-up: Prepare this follow-up: How did you avoid a personality judgment?
Outcome and evidence
On the next feature, they shared the contract and first slice before the cutoff. Review found a compatibility assumption while there was still time to address it, and later slices were easier to assess against that agreement. The teammate also said the earlier checkpoint reduced uncertainty about what reviewers expected. I did not infer a permanent behavior change from one feature or claim they had been careless before. We scheduled another check on whether the approach remained useful.
Why this paragraph works
Evidence: Observed later behavior with feedback.
Why it matters: Connects the claimed result to observations and acknowledges their limits.
Prepare for a follow-up: Prepare this follow-up: What did you offer beyond criticism?
Reflection and follow-through
I learned that feedback should connect observable behavior to impact and offer a practical route forward. Simply demanding smaller pull requests would have missed the uncertainty underneath the pattern. I also kept responsibility for timely review on my side, because asking for earlier work and then ignoring it would make the agreement unfair. The goal was a safer shared workflow, not proving that I could deliver difficult criticism.
Why this paragraph works
Evidence: Support plus reciprocal accountability.
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 check improvement?
Reveal the concise version — roughly 60–90 seconds
A teammate repeatedly opened large changes near release cutoff, making meaningful review difficult. I raised two examples privately, explained the risk and reviewer impact, and asked what drove the pattern. They were unsure when partial work was ready to share. We agreed on early contract questions, smaller slices, and a planning check for inseparable changes. I committed to reviewing the early outline promptly. The next feature exposed a compatibility issue with time to correct it, and the teammate found the checkpoint useful. I kept follow-up open rather than claim permanent change. The lesson was specific behavior, fair impact, practical support, and obligations on both sides.
Improve a weak answer
Weak excerpt
I told them their pull requests were bad and they needed to be more professional.
Improved excerpt
I asked for a private conversation and used two concrete examples where late scope made review difficult. I explained the effect on release risk and reviewers, then asked what was driving the timing. They described uncertainty about when a partial change was worth sharing. We agreed on earlier design questions and smaller reviewable slices, with a short planning check for changes that could not be separated safely. I offered to review an early outline rather than wait for a completed implementation.
The improved excerpt explains a specific decision rather than the unsupported claim in the weak version. Complete it with an earlier review that exposed a compatibility assumption before cutoff, 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 speak privately?
The aim was to understand and change a working pattern, not embarrass someone in a review thread. Private examples allowed a more useful discussion while the release expectations could still be documented openly.
How did you avoid a personality judgment?
I described request size, timing, and the resulting review constraint. Labels such as careless would not explain what needed to change and could hide the underlying uncertainty.
What did you offer beyond criticism?
I offered early outline review and a plan for changes that could not safely split. That support addressed the stated uncertainty, while keeping ownership of the implementation with the teammate.
How did you check improvement?
The next feature reached review early enough to resolve a compatibility assumption. We also discussed whether the checkpoint helped. One example was progress, not evidence the behavior could never recur.
What if nothing changed?
I would revisit the agreement with concrete observations and clarify expectations or involve the relevant lead as appropriate. Support and empathy do not mean leaving repeated release risk unaddressed.
Adjust the evidence to your level
Early-career
Use a bounded project, internship, or volunteer example that demonstrates constructive feedback. Explain guidance you received rather than claiming senior authority.
Mid-level
Show independent responsibility for a defined outcome, including an earlier review that exposed a compatibility assumption before cutoff. Name dependencies and when you sought help.
Senior
Explain trade-offs with affected colleagues, the verification plan, and giving behavior-specific feedback with practical shared commitments. 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 publicly labeling the engineer careless without investigating the pattern.
- Claiming an earlier review that exposed a compatibility assumption before cutoff 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 an earlier review that exposed a compatibility assumption before cutoff and the decision that led to it.
Prepare a follow-up on publicly labeling the engineer careless without investigating the pattern. Replace every fictional detail with your own facts and identify one claim that needs more evidence.