What do interviewers evaluate in Critical Feedback questions?

Interviewers listen for signals like: Did you actually give the feedback, or did you complain to others / wait it out? Was the feedback specific with examples, or vague ('communication could be better')? Did you separate the behavior from the person?

gitGood.dev

GeneralAdvanced Premium

Giving Critical Feedback

Tested at every senior+ loop and every people-management interview. The signal is whether you deliver hard truths with care - or whether you avoid, soften beyond recognition, or wait for someone else to do it.

About this theme

Giving critical feedback is one of the highest-stakes interpersonal skills in engineering. The signal interviewers want: did you deliver the hard message clearly and specifically, or did you soften it past the point of usefulness? Did you do it directly to the person, or did you complain to others first? Did you separate the behavior from the person? Did you follow up? The two failure modes interviewers screen for are (1) avoidance - "I waited to see if it would resolve itself" or "I told my manager and let them handle it" without trying first, and (2) bluntness without care - "I told them they were wrong and they needed to fix it." Strong candidates land somewhere harder: they were direct about the substance, they asked permission to give the feedback, they separated the behavior from the person, they were specific with examples, they gave the recipient room to respond, and they followed up. This theme is tested at every senior+ engineering loop, every engineering manager interview, and increasingly at mid-level (L4 / E4 / IC3) loops where companies are screening for early leadership signal.

What interviewers are evaluating

→Did you actually give the feedback, or did you complain to others / wait it out?
→Was the feedback specific with examples, or vague ('communication could be better')?
→Did you separate the behavior from the person?
→Did you give the recipient room to respond, or did you deliver and leave?
→Did you follow up to see if anything changed, or was it a one-shot?
→Did the working relationship survive, or did you burn it?
→When the recipient pushed back, did you stand by the substance while engaging with their reaction?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about a time you had to give difficult feedback to a peer.
?Describe a situation where you had to call out an underperforming colleague.
?Tell me about a time you pushed back hard on a code review or design.
?Walk me through a time you had to deliver feedback that you knew the recipient wouldn't want to hear.
?Describe a situation where you saw a peer or junior making a mistake repeatedly. What did you do?
?Tell me about a time you had to escalate a peer's behavior to their manager.
?Describe a time you gave feedback that didn't land. What did you do next?
?Tell me about a time you had to disagree with a senior engineer's technical direction in writing.

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: Direct feedback to a peer about underperformance

Prompt: "Describe a situation where you had to call out an underperforming colleague."

Situation: About 18 months ago, I was a senior engineer on a 6-person backend team. A peer (let's call him M) had been on the team for a year. His PRs were slow to land, often required multiple review cycles for the same class of issue (test coverage, error handling), and he'd missed two recent commitments. The team was starting to assign work around him - I noticed our tech lead routing the higher-stakes work to other engineers. I'd built a working relationship with M.
Task: M's manager was newer to the team and seemed to be soft-pedaling the issue in 1:1s based on what M had told me. I had no formal authority over M, but I felt the right person to give specific feedback was a peer who saw his work daily. The risk: I could damage the relationship, or worse, M could read it as me trying to undermine him.
Action: I asked for a 1:1 over coffee, off-site. I framed it explicitly upfront: 'I want to share specific feedback about your work that I think will help you. Some of it will be uncomfortable. I'm doing this as a peer who wants you to do well here. Are you open to that right now, or should we do it another time?' He said go. I gave him three specific examples: (1) The auth refactor PR that took 4 weeks and 6 review rounds because the same test-coverage gap kept reappearing - I described the impact: another engineer was blocked on the API. (2) The latency-fix project he committed to in 2 weeks that took 5 - I described the impact: we missed a partner team's launch dependency. (3) A pattern I'd noticed across his last 8 PRs: error handling consistently weaker than the team norm, and I'd seen the same review comments repeated across PRs. Then I named the pattern: 'I think you're getting reviewer fatigue from us, and I think it's hurting your reputation more than you realize. The work I'm seeing assigned to other engineers is work you'd want.' He was quiet for a minute. He pushed back on the latency project - he'd been blocked by a vendor issue. I said 'OK, I didn't know that - did your manager know? Was it on the project page?' He said no. I said 'That's part of the pattern I'm describing - the work happened, but it didn't show up.' We then talked about what was actually happening. He said he'd been afraid to ask for help on the auth refactor because it was the senior-engineer-track project he'd been given. I told him about projects I'd asked for help on, and offered to be his rubber-duck reviewer on his next two PRs before he sent them out for team review. He took me up on it.
Result: Over the next quarter, his PR velocity roughly doubled and the quality issues largely cleared. He'd stopped accepting projects without flagging blockers. About 4 months in, his manager asked me what had changed and I gave M credit ('he asked for specific feedback and acted on it'). M was promoted the cycle after the next. He told me a year later that the conversation was the most useful feedback he'd gotten at the company. The transferable lesson for me: peers see patterns managers miss, and 'asking permission to give feedback' is the single highest-leverage move - it changes the conversation from criticism to collaboration.

Why this works

What makes this strong: (1) Specific feedback with concrete examples, not 'your work isn't good enough.' (2) The candidate had no formal authority - this is peer-to-peer, the harder kind. (3) Asked permission upfront. That single move is the most-recommended pattern in feedback literature, and the candidate names it as the lesson. (4) Engaged with M's pushback (the vendor issue) honestly, didn't dismiss it. (5) Practical help (rubber-duck review), not just diagnosis. (6) Followed up over months. (7) Let the recipient get the credit. This is what mature feedback looks like.

STRONG

Strong: Pushed back hard on a senior engineer's design

Prompt: "Tell me about a time you pushed back hard on a code review or design."

Situation: About two years ago, a staff engineer on a partner team published a design doc for a new internal authorization service. His proposal hardcoded role definitions in source code with deploy-required updates, citing security concerns about runtime configuration. I was a senior engineer on a team that would be a heavy consumer of the service. I disagreed strongly - I thought the deploy-required model would create exactly the security problem he was trying to avoid (teams would work around it with their own role caches, which would drift).
Task: I had to decide whether to leave a strong dissenting comment in a public design doc - against a more senior engineer with stronger formal credibility - or stay quiet. Staying quiet was tempting because the consequences would land mostly on consumer teams over the next year, not on me personally next week.
Action: I drafted my response privately first to make sure it was substantive, not emotional. I structured it: (1) Acknowledged the security concern explicitly and said it was the right concern to optimize for. (2) Named the specific failure mode I was worried about ('teams will build their own role caches because they need same-day role updates for incident response, and those caches will drift'). (3) Cited two real incidents from the prior year where role-update latency had been a problem. (4) Proposed an alternative: runtime config in a hardened config service with audit logging, immutable history, and per-role approval workflow - which I argued met the security bar without the operational fragility. (5) Explicitly said 'I might be missing context on why runtime config is unacceptable here. If there's threat-model reasoning I don't have, I'd like to understand it before we ship.' I posted it as a comment on the design doc. He responded the next day, defended the deploy-required choice, and pointed to a specific compliance requirement I hadn't been aware of. I went and read it, and he was partially right - one specific role class genuinely required the deploy-time controls. But the requirement only applied to ~20% of roles. I came back with a refined proposal: 'split the role classes, deploy-required for the compliance-bound ones, runtime-configurable for the rest with the audit controls.' He pushed back once more on the split being too complex; I sketched the implementation in a follow-up doc and showed it was about 100 LOC of additional code. He came around. The final design adopted the split. We co-presented it to the security review board.
Result: The service shipped with the split design. Over the next year, roughly 60% of role updates were the runtime-configurable kind and the runtime path handled them in seconds instead of hours. Zero teams built their own role caches. The compliance-bound roles stayed in the deploy-required path with audit. The staff engineer and I co-led one more cross-team project after that, and the working relationship was visibly stronger - we'd both updated. I learned to draft pushback privately first - that one habit catches the difference between 'I disagree' (low signal) and 'here's what I think is wrong and what I'd do instead' (high signal).

Why this works

What makes this strong: (1) Pushed back publicly against someone with more formal credibility - that takes real conviction. (2) Substantive disagreement: alternative proposal with specific failure mode named, not just 'I disagree.' (3) Acknowledged what could be wrong about the candidate's own view ('I might be missing context'). (4) Updated when the staff engineer was right about a specific subset. (5) Followed up with implementation evidence when the next pushback came. (6) Working relationship strengthened - that's the giveaway that the feedback was delivered with care, not as a fight.

WEAK

Weak: Avoided the hard conversation

Prompt: "Tell me about a time you had to give difficult feedback."

Situation: I had a coworker who was struggling with their work and the team was getting frustrated.
Task: I needed to address it.
Action: I talked to my manager about the situation and she agreed to handle it. She gave the person feedback and the situation got better.
Result: The team dynamic improved.

Why this is weak

Why this is weak: (1) The candidate didn't actually give the feedback - they delegated it to the manager. That's avoidance dressed up as escalation. Sometimes manager-route is right (e.g., for performance management), but the question is asking about the candidate's feedback skills. (2) No specifics about what was happening, what the candidate thought should change, or whether the candidate had tried peer-level conversation first. (3) 'The team dynamic improved' suggests the candidate didn't actually verify what changed. Bar Raisers will read this as the candidate doesn't give hard feedback.

Common pitfalls

×Stories where you delegated the feedback to a manager without trying peer-to-peer first. That's avoidance, not leadership.
×Generic feedback ('communication could be better,' 'work harder'). Strong feedback is always specific with examples.
×Skipping the 'asking permission' step. Asking 'are you open to feedback right now?' is the single highest-leverage technique and interviewers know it.
×Bluntness without care. Telling someone 'you're underperforming' without context, examples, or a path forward is below bar at senior+.
×Stories that end at 'I gave the feedback.' The signal is in the follow-up - did you check in? Did anything change?
×No pushback. Real critical feedback gets pushed back on. If your story has none, you're either omitting it or the feedback wasn't real.
×Burning the relationship. If the working relationship deteriorated and you don't address it, interviewers will read you as someone who can't deliver hard messages with care.
×Giving feedback only when you have authority. The signal interviewers want is whether you give peer feedback - the harder kind.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→If asked 'how did you decide to give the feedback yourself vs going to the manager?' - have a rationale. 'Peer-level patterns get peer-level feedback; performance management is the manager's path' is a strong frame.
→If asked 'what if they had pushed back hard?' - your story should include real pushback. If not, acknowledge that you didn't face it in this case and describe how you'd handle it.
→If asked 'how did you follow up?' - have specifics. 'I checked in 2 weeks later' beats 'I kept an eye on it.'
→If asked 'how did you protect the relationship?' - the strongest answers describe specific moves: separating behavior from person, asking permission, offering practical help, giving the recipient credit later.
→If asked 'what would you do differently?' - real reflection finds something. 'I'd give the feedback sooner - I waited 6 weeks too long' is a credible answer.
→If asked 'have you ever given feedback that landed badly?' - have one. If your answer is 'no, my feedback always lands well,' interviewers read it as either lack of self-awareness or lack of feedback experience.
→If asked 'how do you give feedback to someone more senior than you?' - have a specific technique. Drafting privately first, structuring as 'here's what I'm seeing and what I'd propose,' explicitly inviting correction are all strong patterns.

Related behavioral themes

Conflict

General

The most universal behavioral question. Tested everywhere. The signal is in how you investigate the disagreement, not in how you 'won.'

Influence

General

The senior+ signal. Can you drive cross-team work, mentor, and build consensus when nobody reports to you - or do you only execute when given a mandate?

Ownership

Amazon LP

Tested at every level, scored harder at senior. Did you take responsibility for outcomes - or just for tasks?

FREE

Companies that test this theme

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →

GeneralAdvanced Premium

Giving Critical Feedback

About this theme

What interviewers are evaluating

→Did you actually give the feedback, or did you complain to others / wait it out?
→Was the feedback specific with examples, or vague ('communication could be better')?
→Did you separate the behavior from the person?
→Did you give the recipient room to respond, or did you deliver and leave?
→Did you follow up to see if anything changed, or was it a one-shot?
→Did the working relationship survive, or did you burn it?
→When the recipient pushed back, did you stand by the substance while engaging with their reaction?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about a time you had to give difficult feedback to a peer.
?Describe a situation where you had to call out an underperforming colleague.
?Tell me about a time you pushed back hard on a code review or design.
?Walk me through a time you had to deliver feedback that you knew the recipient wouldn't want to hear.
?Describe a situation where you saw a peer or junior making a mistake repeatedly. What did you do?
?Tell me about a time you had to escalate a peer's behavior to their manager.
?Describe a time you gave feedback that didn't land. What did you do next?
?Tell me about a time you had to disagree with a senior engineer's technical direction in writing.

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: Direct feedback to a peer about underperformance

Prompt: "Describe a situation where you had to call out an underperforming colleague."

Situation: About 18 months ago, I was a senior engineer on a 6-person backend team. A peer (let's call him M) had been on the team for a year. His PRs were slow to land, often required multiple review cycles for the same class of issue (test coverage, error handling), and he'd missed two recent commitments. The team was starting to assign work around him - I noticed our tech lead routing the higher-stakes work to other engineers. I'd built a working relationship with M.
Task: M's manager was newer to the team and seemed to be soft-pedaling the issue in 1:1s based on what M had told me. I had no formal authority over M, but I felt the right person to give specific feedback was a peer who saw his work daily. The risk: I could damage the relationship, or worse, M could read it as me trying to undermine him.
Action: I asked for a 1:1 over coffee, off-site. I framed it explicitly upfront: 'I want to share specific feedback about your work that I think will help you. Some of it will be uncomfortable. I'm doing this as a peer who wants you to do well here. Are you open to that right now, or should we do it another time?' He said go. I gave him three specific examples: (1) The auth refactor PR that took 4 weeks and 6 review rounds because the same test-coverage gap kept reappearing - I described the impact: another engineer was blocked on the API. (2) The latency-fix project he committed to in 2 weeks that took 5 - I described the impact: we missed a partner team's launch dependency. (3) A pattern I'd noticed across his last 8 PRs: error handling consistently weaker than the team norm, and I'd seen the same review comments repeated across PRs. Then I named the pattern: 'I think you're getting reviewer fatigue from us, and I think it's hurting your reputation more than you realize. The work I'm seeing assigned to other engineers is work you'd want.' He was quiet for a minute. He pushed back on the latency project - he'd been blocked by a vendor issue. I said 'OK, I didn't know that - did your manager know? Was it on the project page?' He said no. I said 'That's part of the pattern I'm describing - the work happened, but it didn't show up.' We then talked about what was actually happening. He said he'd been afraid to ask for help on the auth refactor because it was the senior-engineer-track project he'd been given. I told him about projects I'd asked for help on, and offered to be his rubber-duck reviewer on his next two PRs before he sent them out for team review. He took me up on it.
Result: Over the next quarter, his PR velocity roughly doubled and the quality issues largely cleared. He'd stopped accepting projects without flagging blockers. About 4 months in, his manager asked me what had changed and I gave M credit ('he asked for specific feedback and acted on it'). M was promoted the cycle after the next. He told me a year later that the conversation was the most useful feedback he'd gotten at the company. The transferable lesson for me: peers see patterns managers miss, and 'asking permission to give feedback' is the single highest-leverage move - it changes the conversation from criticism to collaboration.

Why this works

STRONG

Strong: Pushed back hard on a senior engineer's design

Prompt: "Tell me about a time you pushed back hard on a code review or design."

Situation: About two years ago, a staff engineer on a partner team published a design doc for a new internal authorization service. His proposal hardcoded role definitions in source code with deploy-required updates, citing security concerns about runtime configuration. I was a senior engineer on a team that would be a heavy consumer of the service. I disagreed strongly - I thought the deploy-required model would create exactly the security problem he was trying to avoid (teams would work around it with their own role caches, which would drift).
Task: I had to decide whether to leave a strong dissenting comment in a public design doc - against a more senior engineer with stronger formal credibility - or stay quiet. Staying quiet was tempting because the consequences would land mostly on consumer teams over the next year, not on me personally next week.
Action: I drafted my response privately first to make sure it was substantive, not emotional. I structured it: (1) Acknowledged the security concern explicitly and said it was the right concern to optimize for. (2) Named the specific failure mode I was worried about ('teams will build their own role caches because they need same-day role updates for incident response, and those caches will drift'). (3) Cited two real incidents from the prior year where role-update latency had been a problem. (4) Proposed an alternative: runtime config in a hardened config service with audit logging, immutable history, and per-role approval workflow - which I argued met the security bar without the operational fragility. (5) Explicitly said 'I might be missing context on why runtime config is unacceptable here. If there's threat-model reasoning I don't have, I'd like to understand it before we ship.' I posted it as a comment on the design doc. He responded the next day, defended the deploy-required choice, and pointed to a specific compliance requirement I hadn't been aware of. I went and read it, and he was partially right - one specific role class genuinely required the deploy-time controls. But the requirement only applied to ~20% of roles. I came back with a refined proposal: 'split the role classes, deploy-required for the compliance-bound ones, runtime-configurable for the rest with the audit controls.' He pushed back once more on the split being too complex; I sketched the implementation in a follow-up doc and showed it was about 100 LOC of additional code. He came around. The final design adopted the split. We co-presented it to the security review board.
Result: The service shipped with the split design. Over the next year, roughly 60% of role updates were the runtime-configurable kind and the runtime path handled them in seconds instead of hours. Zero teams built their own role caches. The compliance-bound roles stayed in the deploy-required path with audit. The staff engineer and I co-led one more cross-team project after that, and the working relationship was visibly stronger - we'd both updated. I learned to draft pushback privately first - that one habit catches the difference between 'I disagree' (low signal) and 'here's what I think is wrong and what I'd do instead' (high signal).

Why this works

WEAK

Weak: Avoided the hard conversation

Prompt: "Tell me about a time you had to give difficult feedback."

Situation: I had a coworker who was struggling with their work and the team was getting frustrated.
Task: I needed to address it.
Action: I talked to my manager about the situation and she agreed to handle it. She gave the person feedback and the situation got better.
Result: The team dynamic improved.

Why this is weak

Common pitfalls

×Stories where you delegated the feedback to a manager without trying peer-to-peer first. That's avoidance, not leadership.
×Generic feedback ('communication could be better,' 'work harder'). Strong feedback is always specific with examples.
×Skipping the 'asking permission' step. Asking 'are you open to feedback right now?' is the single highest-leverage technique and interviewers know it.
×Bluntness without care. Telling someone 'you're underperforming' without context, examples, or a path forward is below bar at senior+.
×Stories that end at 'I gave the feedback.' The signal is in the follow-up - did you check in? Did anything change?
×No pushback. Real critical feedback gets pushed back on. If your story has none, you're either omitting it or the feedback wasn't real.
×Burning the relationship. If the working relationship deteriorated and you don't address it, interviewers will read you as someone who can't deliver hard messages with care.
×Giving feedback only when you have authority. The signal interviewers want is whether you give peer feedback - the harder kind.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→If asked 'how did you decide to give the feedback yourself vs going to the manager?' - have a rationale. 'Peer-level patterns get peer-level feedback; performance management is the manager's path' is a strong frame.
→If asked 'what if they had pushed back hard?' - your story should include real pushback. If not, acknowledge that you didn't face it in this case and describe how you'd handle it.
→If asked 'how did you follow up?' - have specifics. 'I checked in 2 weeks later' beats 'I kept an eye on it.'
→If asked 'how did you protect the relationship?' - the strongest answers describe specific moves: separating behavior from person, asking permission, offering practical help, giving the recipient credit later.
→If asked 'what would you do differently?' - real reflection finds something. 'I'd give the feedback sooner - I waited 6 weeks too long' is a credible answer.
→If asked 'have you ever given feedback that landed badly?' - have one. If your answer is 'no, my feedback always lands well,' interviewers read it as either lack of self-awareness or lack of feedback experience.
→If asked 'how do you give feedback to someone more senior than you?' - have a specific technique. Drafting privately first, structuring as 'here's what I'm seeing and what I'd propose,' explicitly inviting correction are all strong patterns.

Related behavioral themes

Conflict

General

The most universal behavioral question. Tested everywhere. The signal is in how you investigate the disagreement, not in how you 'won.'

Influence

General

The senior+ signal. Can you drive cross-team work, mentor, and build consensus when nobody reports to you - or do you only execute when given a mandate?

Ownership

Amazon LP

Tested at every level, scored harder at senior. Did you take responsibility for outcomes - or just for tasks?

FREE

Companies that test this theme

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →