Question and When It Applies
Tell me about a time you had to give a teammate difficult but necessary feedback. Explain what you observed, why you could no longer avoid the issue, how you conducted the conversation, how the other person responded, and what verifiable change followed.
Bar Raiser includes “give difficult feedback to a peer” in its 2026 list of software engineering behavioral questions. A May 2026 senior software engineer interview recorded by Glassdoor asked for both receiving and giving difficult feedback. Amazon's recruiting guidance recommends STAR for behavioral questions and asks candidates to make their individual actions and concrete results clear. The Center for Creative Leadership's SBI method organizes feedback around the situation, observable behavior, and impact, followed by an inquiry into intent so that an assumption is not presented as fact.
The question applies to engineering, product, data, design, operations, and management roles. You may discuss a peer, a cross-functional partner, or a direct report, but you must state the power boundary accurately. With a peer, you can explain an impact and establish a working agreement; you cannot pretend to own their performance rating. With a direct report, formal performance feedback must also follow the organization's established expectations and process.
A suitable story contains a consequential conversation. The feedback could damage a working relationship, expose an error in your own judgment, or require both people to change how they work. A routine code review comment, a casual reminder, or praise without a difficult message is usually too weak. Discrimination, harassment, retaliation, safety issues, and unlawful conduct may create a formal reporting duty; do not reduce that duty to a private chat. Record the relevant facts and use the required organizational channel.
The demonstration later in this article is fictional practice material. It must not be presented as personal experience, and every number of people, events, hours, and outcomes is sample data that must be replaced.
What the Interviewer Evaluates
First, can you separate observation from judgment? “He was irresponsible” is a character conclusion. “He did not mark himself unavailable in two confirmed reviews, then raised blockers immediately before release” is behavior that can be discussed. If the evidence came from someone else, verify it before confronting the person.
Second, are you willing to take a relationship risk at the right time? A strong answer does not use harmony as a reason to avoid the issue, and it does not save months of frustration for one retrospective accusation. Explain why the conversation was necessary then, what delay would cost, and why you chose a private, timely setting with enough time for a real response.
Third, was the feedback both direct and fair? Direct means naming the behavior that needs to change and its impact. Fair means not inventing a motive, allowing the other person to add facts, and recognizing that a process or your own behavior may have contributed. Hiding criticism inside excessive praise can obscure the message. Delivering a verdict without inquiry turns the conversation into a compliance test.
Fourth, how did you handle disagreement, silence, or emotion? Interviewers do not expect every colleague to thank you immediately. They want to see whether you paused an argument, restated the disagreement, asked what context was missing, and returned to a shared goal. If new evidence disproved your conclusion, revising or withdrawing the feedback would show sound judgment.
Fifth, could you convert the conversation into observable behavior? “Communicate more” has no owner, situation, or checkpoint. A strong answer defines who will do what, by when, what signal triggers escalation, and when the parties will follow up. The endpoint is not “they understood.” It is a change in behavior and impact in a similar situation.
Sixth, did you attribute the result accurately? A later project may succeed through many people's work. Separate the other person's action, your own change, a process correction, and the team result. If behavior did not improve, explain how you returned with evidence, involved the accountable manager, or moved into a formal process.
Finally, interviewers look for reflection. A credible story often includes something you handled imperfectly: you prepared evidence too late, used a heavy tone, failed to establish roles, assigned a process defect entirely to one person, or chose a poor follow-up interval. Reflection must become a specific action you would take earlier next time.
Questions to Clarify Before Answering
- Who received the feedback? A peer, cross-functional partner, direct report, and manager create different power
dynamics. State whether you had advisory authority, management responsibility, or only the standing of an affected colleague.
- Was this constructive feedback, formal performance management, or misconduct? Work behavior and collaboration
fit this question. Formal performance issues require the manager and HR process; harassment, safety, and unlawful conduct may require reporting rather than one private conversation.
- What did you personally observe? Separate direct observation, records, secondhand reports, and interpretation.
If you only heard an account, verify its source and context before deciding that feedback is appropriate.
- What made the feedback difficult? The stakes might be a valuable relationship, a level difference, a history of
defensive reactions, your own contribution to the problem, or severe time pressure. “I dislike conflict” alone is not enough.
- What change would close the loop? Define the target behavior, affected outcome, and follow-up method. Agreement
in the room is not resolution, and one successful project does not prove stable change.
- Can you protect the person's privacy? Remove names, performance ratings, health information, and irrelevant
identity details. Retain only the work facts needed to understand your judgment, actions, and result.
- How is this different from mentoring? Mentoring centers on a sustained path to independent capability. This
question centers on one consequential feedback conversation, the reaction, and behavioral closure. Support may follow, but it cannot turn the story into a training program.
- How is this different from a technical disagreement? A disagreement story compares options and decision rights.
This story examines observable work behavior and its impact. If the main point is still that your architecture was better, choose another example.
The 30-Second Answer Framework
During [project and situation], I directly observed [specific behavior], which caused [impact on delivery,
team, or customer]. Because [risk of continued avoidance], I first checked [record or fact], then chose a
[private, timely setting with enough time] to speak with my teammate. I described the situation, behavior,
and impact without guessing their motive, then asked for context. They explained [new information or a
different view]. I acknowledged [my own or the process's contribution] while remaining clear about [behavior
that needed to change]. We agreed on [specific next action, owner, and checkpoint]. In later [comparable
situations], [behavioral evidence] and [work result or follow-up] showed [change]. In retrospect, I would
[one specific improvement] earlier.Use STAR for the overall experience. Keep Situation and Task short. Spend most of Action on evidence, the structure of what you said, the person's response, and the agreement. Use Result for behavioral and work evidence, then add a specific Reflection. Do not recite framework names; let the interviewer hear what you actually said and adjusted.
Step-by-Step Deep Dive
Step 1: Choose a story with a conversation, reaction, and closure
Prefer an experience with five properties: you personally observed behavior that can be described; it had a real impact; you initiated the conversation; the other person supplied information or disagreement you did not already know; and you later observed change, no change, or an appropriate escalation.
“I left a code review comment asking for tests” is usually routine collaboration. “A teammate repeatedly introduced release blockers only in the final go/no-go meeting, requiring a discussion about review commitments, workload, and early escalation” contains more judgment. The story does not need a perfect reconciliation, but it does need a next action.
Avoid a story in which the other person was obviously malicious and you were entirely right. If the narrative has one irrational colleague and one flawless version of you, the interviewer cannot see whether you were fair. A stronger story gives the other person reasonable context, shows something you changed, and still addresses the core behavior clearly.
Step 2: Build an evidence ladder before the conversation
Separate the information into four levels:
- Direct observation: what you saw, heard, or owned in a record;
- Verifiable outcome: delay, rework, customer impact, meeting decision, or ticket state;
- Secondhand report: a lead worth checking, not an automatic accusation;
- Interpretation and motive: “does not care” or “delayed intentionally” is a hypothesis for inquiry.
Now write one description without a personality judgment. “In Tuesday's release review, you raised two blockers after recording approval, and the team had to reduce scope” is usable. “You always create problems at the last minute” is not. Words such as “always,” “never,” and “bad attitude” are easy to dispute and force the other person to defend an identity rather than examine an event.
Check your own contribution too. Was the invitation late? Was “approval” undefined? Was the workload impossible to decline? Had you ignored an earlier warning? Shared context does not erase the feedback; it prevents a system defect from being disguised as a character defect.
Step 3: Choose a setting that protects clarity
The usual choice is soon after the event, in private, when both people have enough time. Public correction increases the cost of embarrassment. A detailed behavioral discussion during the urgent phase of an incident conflicts with containment. Saving a list until the end of a quarter removes the chance to adjust promptly.
Open with purpose and scope: “I want to discuss one thing from yesterday's release review because it affects how we confirm launch scope. Do you have fifteen minutes now, or should we reserve a complete slot today?” Fifteen minutes is only sample wording; use your actual arrangement. The person may schedule a better time, but asking permission cannot become indefinite avoidance of necessary feedback.
If you are a manager discussing formal performance, confirm policy, prior expectations, and documentation duties. If you are a peer, do not issue a “final warning” or imply that you control a rating. The more power you have, the more explicitly you should allow questions, evidence, and support channels.
Step 4: Conduct the core conversation with SBI-I
Organize the conversation into four moves:
- Situation: anchor one time and context;
- Behavior: describe what a camera could record;
- Impact: explain a concrete consequence for work, the team, or you;
- Intent inquiry: ask what the person knew, what they were protecting, and what context you missed.
For example: “In the last two release reviews, you marked the document approved but raised blocking risks only before the freeze. We reduced scope at the last minute and could not tell what the earlier approval meant. I want to understand your workload then and how you interpreted ‘approved.’” The statement is clear and leaves room to learn.
After the explanation, restate their view and consider three outcomes. Your facts were wrong, so the feedback must be withdrawn or revised. An unclear process contributed on both sides, so both must fix it. The core behavior still stands, so an expectation must be made explicit. A mature answer does not assume the third outcome in advance.
Step 5: Handle defensiveness, silence, and feedback in return
If the person denies the feedback, do not get louder or stack examples rapidly. Ask where the disagreement sits: “Do you disagree that the behavior occurred, that it caused this impact, or with the next step I proposed?” This converts an identity defense back into a question that can be examined.
If emotion is high, pause and agree on a time to resume; do not pretend the topic disappeared. If the person is silent, allow thought and invite a response with an open question. If they say you ignored an earlier warning, check the record and acknowledge it. An apology does not require abandoning the part of the feedback that remains valid.
Feedback in return can demonstrate judgment. Suppose “approved” was never defined and review requests repeatedly conflicted with the person's on-call week. You can acknowledge that the process made the behavior more likely while still agreeing that an unavailable reviewer must decline or delegate rather than leave a misleading approval.
You do not have to tolerate insults, threats, or retaliation through better communication technique. Record observable facts, end an unsafe conversation, and use the manager, HR, compliance, or safety channel.
Step 6: Turn improvement into the next observable action
Replace “raise issues earlier” with a complete working agreement: the situation, owner, deadline, status, and escalation path. For example:
- a reviewer must choose “approved,” “changes required,” or “unable to review by the deadline”;
- an on-call conflict requires delegation before the freeze;
- a blocker goes into the decision record as soon as it is found, not at the final meeting;
- two missed checkpoints cause the project owner to reassign responsibility.
The agreement should include your action too. You might send material earlier, define approval semantics, acknowledge asynchronous blockers before the meeting, or stop treating silence as consent. Both people changing does not dilute the feedback. It incorporates confirmed system factors into the remedy.
Ask the person to restate the next step so that a polite “got it” does not hide a different interpretation. Record a short action item if appropriate; do not create a secret performance file out of ordinary peer communication.
Step 7: Close the loop with multiple kinds of evidence
Use at least two layers of result evidence:
- Behavior evidence: in the next comparable event, did the person mark, decline, delegate, or escalate earlier?
- Impact evidence: did rework, delay, error, meeting friction, or customer impact change?
- Relationship evidence: could the person still disagree, and could both people continue direct conversation?
- Process evidence: did the team clarify a role, state, or escalation rule?
“They accepted the feedback” is not a result; they may have agreed only to end the conversation. One successful release does not prove stable behavior either. State how many comparable events you observed, who confirmed the change, and what evidence remains limited.
If the behavior did not improve, a strong answer explains the next step: return with another specific example, test whether the agreement was feasible, involve the person who truly owns the outcome, or follow the formal process. Feedback cannot guarantee change. Your responsibility is to be clear, fair, timely, and accountable within your role.
Step 8: Use STAR(R) to keep follow-up answers stable
Situation establishes the project, relationship, and stakes. Task explains why you had responsibility to speak. Action covers evidence, timing, SBI-I, the reaction, and the agreement. Result gives behavior, impact, and relationship evidence. Reflection names what you would do earlier. Action should take most of the answer.
Have a practice partner ask: “Why did you decide it was their problem?” “What were your exact words?” “What did they disagree with?” “What did you change?” and “What if it had not improved?” If every answer preserves the same facts, authority, and measurement definitions, the story is ready for a deep interview.
High-Quality Sample Answer
The following story is fictional practice material and must not be presented as personal experience. Three reviews, two releases, forty-eight hours, twenty-four hours, four follow-up reviews, and every other quantity are **sample data that must be replaced**.
“I coordinated releases for a payments product. A peer senior engineer reviewed the risk module. In three design reviews, he marked the record approved, but in two cases he raised blockers only in the final go/no-go meeting. The team had to reduce scope at the last minute, and one release moved by forty-eight hours. Three, two, and forty-eight hours are sample data that must be replaced.
I was accountable for a trustworthy release decision, but he did not report to me. I first checked the review records and invitation times and confirmed that the blockers first appeared in the final meeting. I also noticed that one review overlapped his on-call rotation, so I did not frame the issue as irresponsibility. The day after we contained the release problem, I asked to speak privately and said I wanted to discuss what the approval state meant and how we would work next time.
I said, ‘In the last two releases, you marked the design record approved and then raised blocking risks in the freeze meeting. The team reduced scope, and we could not tell whether we could rely on the earlier approval. I want to understand what information you had and how you were using that state.’
He was initially defensive and said that risks would be ignored unless he insisted in the final meeting. I did not argue about his attitude. I asked whether he had raised the same concerns earlier. He pointed out that review requests often arrived during his on-call week and that an earlier asynchronous comment had gone unanswered. I verified that and acknowledged that invitation timing and acknowledgment needed improvement. I also remained clear that if he could not complete a review, marking approval was misleading because other teams made launch commitments from it.
We agreed on three actions. A reviewer would choose ‘approved,’ ‘changes required,’ or ‘unable to review by the deadline.’ An on-call conflict required him to delegate before the freeze. A blocker had to enter the decision record immediately. I would send material at least twenty-four hours earlier and explicitly close each blocker. Twenty-four hours is sample data that must be replaced.
Across the next four reviews, he used the unavailable state once and delegated the review. Two blockers entered the record before the freeze, and none appeared for the first time in the final meeting. Four, one, and two are **sample data that must be replaced**. I followed up after the fourth review. He said the states let him represent his capacity honestly and also noted one case when I still acknowledged a comment too slowly. I added an acknowledgment owner to the release checklist. We continued to disagree on technical issues, but we could discuss them directly instead of waiting for the final meeting.
I cannot attribute that result only to my feedback. He changed how he used the state, the project owner supported the process adjustment, and I corrected the invitation and acknowledgment problems. My contribution was to initiate an uncomfortable conversation with specific evidence, stay engaged through a defensive response, and translate both people's responsibilities into observable actions. In retrospect, I would clarify approval semantics after the first mismatch instead of waiting for repeated release impact.”
When adapting your own story, do not copy the payments, risk, or release scenario. Replace every sample quantity and preserve the real causal chain: direct observation, necessity, private conversation, the other person's perspective, your contribution to the problem, a specific agreement, later evidence, and reflection.
Common Mistakes
- Calling the person “difficult” → A personality label cannot be verified and leaves only blame → **Describe a
specific situation, behavior, and work impact.**
- Relying mainly on hearsay → You may amplify a misunderstanding and damage trust → **Verify direct records and
label anything that still needs confirmation.**
- Sandwiching the message inside praise → The person may receive only an ambiguous signal → **State the behavior,
impact, and reason respectfully and directly.**
- Giving negative feedback in public → Embarrassment can overwhelm the issue → **Unless an immediate safety risk
must be stopped, choose a private, complete conversation.**
- Guessing intent → “You do not care” turns the discussion into a character defense → **Describe observation and
impact, then inquire about intent.**
- Retreating as soon as the person is defensive → The discomfort ends while the problem continues → **Pause,
locate the disagreement, and return to facts and the shared goal.**
- Rejecting all feedback in return → You ignore the process and your own contribution → **Verify the new facts and
state what you also need to change.**
- Agreeing only to “communicate more” → There is no situation, owner, or checkpoint → **Define the next observable
behavior and escalation condition.**
- Using “they thanked me” as the result → Politeness does not prove change → **Give later behavior, impact,
relationship, or process evidence.**
- Claiming one conversation changed the colleague → This exaggerates causality and takes their credit → **Separate
their action, process support, and your contribution.**
- Treating formal misconduct as ordinary conflict → You may miss reporting and protection duties → **Record facts
and use the appropriate manager, HR, compliance, or safety channel.**
- Inventing attractive metrics → The story will fail when definitions are challenged → **Use real records; when
no number exists, give a specific, verifiable qualitative change.**
Follow-Up Questions and Responses
Follow-up 1: What exactly did you say?
Reproduce the core structure in one or two sentences: the specific situation, observable behavior, impact, and inquiry into intent. Do not recite a speech or say only that you were tactful. The interviewer is testing directness and fairness.
Follow-up 2: What if the person completely disagreed?
Locate the disagreement in the fact, impact, or next step. Add verifiable records and genuinely examine their new information. If you still cannot agree, document both understandings and the work risk, then ask the accountable owner to decide the process. A peer should not appoint themselves the judge.
Follow-up 3: What if you later learned that you were wrong?
Withdraw the unsupported conclusion explicitly, explain which facts changed your judgment, and repair any impact from the incorrect feedback. You may restate a portion that remains valid, but “my intentions were good” does not replace an apology.
Follow-up 4: What if the person was your manager?
Stay with behavior you observed and its work impact, choose an appropriate setting, and make a concrete request. The power difference increases risk but does not lower the evidence standard. If retaliation or misconduct is a concern, use a skip-level manager, employee relations, or compliance channel.
Follow-up 5: What if the person was your direct report?
Explain the prior expectation, your management responsibility, and the organizational process while allowing response and support. Do not turn the first clear message into evidence of a long-standing performance problem. Do not hide the actual standard in an attempt to sound kind. Follow company policy for formal documentation.
Follow-up 6: How did you know the relationship was not damaged?
Do not stop at “our relationship improved.” Offer observable evidence: the person later raised disagreement proactively, both people had another direct conversation, they completed comparable work together, or the person could still point out something you had not fixed. Continued candor does not require friendship.
Follow-up 7: What if the behavior did not change?
Recheck the expectation, obstacle, and feasibility of the agreement; provide another specific example; and involve the manager who owns the outcome. If the issue enters formal performance, safety, or compliance territory, follow that process. Show continued accountability while acknowledging that you cannot control another person's choice.