Sample Feedback Report
What Your Feedback Looks Like
This is a real first-attempt example. See how the AI coach identifies exactly what to fix - and provides a model answer to learn from.
Tell me about a time you had to make an unpopular decision with your team. What was the situation and how did you handle it?
Category: Leadership · Role: Engineering Manager · Interviewer: Startup CTO
Session Transcript
AI Interviewer
Tell me about a time you had to make an unpopular decision with your team. What was the situation and how did you handle it?
Candidate
So we had this legacy service that kept causing production incidents. I decided we needed to stop feature work and fix it. The team wasn't happy because we had a roadmap to deliver, but I felt strongly that we couldn't keep going with all these incidents happening.
AI Interviewer
Can you be more specific about the scale of the problem? How many incidents were there, and what was the actual impact on the team and the business?
Candidate
There were quite a few incidents - I think maybe a few per month. The engineers were spending a lot of time firefighting instead of building features. It was definitely hurting our velocity, though I don't have the exact numbers off the top of my head.
AI Interviewer
You mentioned the team wasn't happy. How did you handle that pushback? Did you do anything specific to get their buy-in?
Candidate
I basically just told them this is what we need to do and explained my reasoning. I said the incidents were getting worse and if we didn't fix it now, it would only get harder. Some people disagreed but eventually they came around. I think once we started the work and they saw things improving, they understood why I made the call.
AI Interviewer
How did you manage the relationship with your product counterpart? Pausing a roadmap has implications beyond just engineering.
Candidate
Yeah, the PM wasn't thrilled either. I told them we needed to pause and that it would be better in the long run. They understood - I mean, they were also feeling the pain of the incidents disrupting our sprints. We basically just pushed the roadmap out by a couple of sprints.
AI Interviewer
What was the outcome? And looking back, is there anything you would have done differently?
Candidate
The outcome was positive - incidents went down and the team was happier. In terms of doing things differently, I think I made the right call. Maybe I would have communicated it a bit better, but overall I think the decision itself was correct and the results speak for themselves.
Keep Practising
Strengths
You chose a relevant example that genuinely involves an unpopular decision - pausing a roadmap for tech debt is a common and credible EM scenario.
Your answer was reasonably concise and didn't ramble. You stayed on topic throughout the conversation.
Areas to Improve
Your answer is almost entirely missing concrete data. 'Quite a few incidents' and 'a lot of time firefighting' are vague. An interviewer wants to hear '3 P1 incidents per month, costing 120 engineering hours per quarter.' If you have the numbers, use them. If you don't remember exactly, give your best estimate and say so.
You described telling the team what to do, but showed no evidence of actually leading them through the change. Strong answers demonstrate how you built buy-in: Did you meet with dissenters individually? Did you address their specific concerns? Did you adapt your approach based on feedback? 'I just told them' signals a command-and-control style that will raise red flags in most EM interviews.
The product management angle was handled superficially. Saying 'they understood' skips over the hard part. Interviewers want to hear how you navigated the trade-off - did you propose a compromise? Did you present data to justify the pause? Did you give product any say in the approach?
Your reflection at the end was a missed opportunity. 'I think I made the right call' with no real self-awareness will score poorly. Strong candidates identify specific things they'd change: starting earlier, involving the team in the decision, measuring outcomes differently. This signals growth mindset.
The STAR structure is weak - you have a vague Situation, no clear Task, a thin Action, and a generic Result. Each part should be specific and concrete.
Detailed Coaching
Your answer tells a recognisable story but lacks the specificity and leadership evidence that interviewers at top tech companies look for. The biggest issue is that every part of your response is vague where it should be precise.
On the Situation: you mention a legacy service causing incidents, but never quantify the problem. How many incidents per month? How many engineering hours lost? What was the business cost? Without numbers, the interviewer has no way to assess whether this was a minor annoyance or a genuine crisis - and therefore no way to evaluate whether your decision was proportionate.
On the Action: your approach to the team ("I basically just told them") is the weakest part of the answer. Engineering Manager interviews are specifically testing for your ability to influence, build consensus, and lead through change. Describing a top-down directive with no stakeholder management signals that you may default to authority rather than leadership. A stronger answer would show you understanding individual concerns, adapting your approach, and finding ways to bring people along.
On the Result: "incidents went down and the team was happier" is too generic. By how much? Over what timeframe? Did you measure it? Did you share results with stakeholders? The Result section of your answer is where you demonstrate impact - and impact needs to be quantified.
On Self-Awareness: saying "I made the right call" without identifying any genuine learnings will hurt you. Interviewers want to see that you extract lessons from your experiences, especially around how you could have handled the people side better. The fact that you acknowledged you might "communicate it a bit better" is a start, but it's too vague to count as genuine reflection.
This answer would significantly improve with two changes: (1) add specific numbers everywhere - incidents per month, hours lost, percentage improvement after the fix, and (2) replace "I told them" with a genuine stakeholder management story that shows how you built buy-in.
Model Answer for Comparison
"We were experiencing 3 P1 incidents per month from a legacy service, costing roughly 120 hours of engineering time per quarter in firefighting. I decided to pause feature work for two sprints to address the root cause - a decision my team initially opposed because we had committed to a product roadmap with tight deadlines.
I took three steps to build buy-in. First, I shared the data with the team: incident frequency, engineering time cost, and a projection showing it would get worse. Second, I met one-on-one with the two engineers who pushed back hardest. One was worried about his promotion timeline, so I helped him reframe leading the migration as a high-impact contribution for his packet. The other was concerned about product trust, which led me to my third step: I proposed a compromise to our PM - we'd deliver a de-scoped version of the top feature (80% of user value, 30% of engineering effort) alongside the tech debt work, so product still had something to ship.
The result: P1 incidents dropped to zero the following quarter. Cycle time improved 25% because engineers stopped context-switching into firefighting. The engineer worried about his promotion was promoted that cycle, partly on the strength of leading the migration.
What I learned: I should have acted sooner - the data was available three months before I made the call. And I would have involved the team in the decision earlier. I came with a decision already made, which created unnecessary resistance. I've since changed my approach: for decisions that affect the whole team, I present the problem and data first and let the team propose solutions before I weigh in."
Want feedback like this on your answers?
Try a free practice question. No signup, no credit card. Get your personalised scorecard in minutes.
No account needed. No credit card. Takes 3 minutes.
