To answer “tell me about a time you delivered bad news,” describe a moment when you had to tell someone something they did not want to hear, and show that you told them early, said it plainly in the first sentence, owned your part without excuses, and came with options rather than just the problem. Interviewers are testing whether people can trust you with bad news delivered early and honestly. End with what happened next and how the relationship held up.
What is the interviewer really testing?
Every job produces bad news: a slipped date, a defect, a budget overrun, a cancelled project, a lost deal. The people who handle it well tell others quickly, explain it clearly and help them decide what to do next. The people who handle it badly delay, soften it until it is unclear, or blame someone else. Interviewers want to know which one you are.
Some companies make this explicit. Amazon's Leadership Principles describe “Earn Trust” as including being vocally self-critical even when it is awkward or embarrassing (as of October 2026). Most interviewers, at any company, listen for:
- Timing. You raised it as soon as you knew enough, not when it could no longer be hidden.
- Clarity. The listener understood the news in your first sentence or two.
- Ownership. If any of it was your doing, you said so plainly.
- Options. You brought choices, a recovery plan or a recommendation.
- Empathy. You considered how the news would land and gave the person room to react.
How do you answer “tell me about a time you delivered bad news”?
Tell the story with the STAR method, and make sure the Action section shows how you structured the conversation itself. A simple four-part structure works for most bad news, and naming it in your answer shows you have a repeatable approach:
| Part | What you say | Why it matters |
|---|---|---|
| 1. Headline | The news in one plain sentence | Burying it in context makes people anxious and suspicious |
| 2. Cause and ownership | What happened, briefly, including your part | Shows honesty without turning it into an excuse |
| 3. Impact | What it means for them specifically | Lets them judge how serious it is |
| 4. Options and next step | Two or three choices and your recommendation | Turns a problem into a decision they can make |
After the conversation, the follow-through matters as much as the delivery: a written summary, the next update date and keeping every promise you made in that meeting.
Three example answers we wrote
These are examples we wrote to show the structure, not real candidates' answers. Use your own story and numbers.
Example answer we wrote: telling a customer (customer success manager)
Situation: I was a customer success manager for a logistics software company. One of my largest accounts was planning its peak-season operations around an integration with its warehouse system that we had promised for October 1.
Task: In early September, engineering told me the integration would be at least four weeks late because of a security review. I had to tell the customer before they finalized their plans around it.
Action: I called their operations director the same afternoon instead of waiting for our monthly review. I opened with the headline: the integration would not be ready on October 1, and the realistic date was early November. I owned that we had committed to the date before the security review was scoped. Then I asked how they had planned to use it in October. Their main need was daily inventory syncing, so I brought two options to a follow-up call: a nightly file-based sync our team could set up within a week, or extra onboarding support so their staff could run manual syncs. I sent a written summary and a weekly status note until launch.
Result: They chose the nightly sync, which ran through peak season without a missed day. The full integration launched on November 4. The account renewed for two years in January, and their director told our VP that the early call was why they trusted our dates afterward.
Example answer we wrote: telling a manager (software engineer)
Situation: I was a software engineer on a checkout team. While testing a release I had built, I found that a change I had shipped two weeks earlier was rounding tax incorrectly on a small share of orders in two states.
Task: I had to tell my manager that my own code had caused a customer-facing error, and help work out what to do about it.
Action: I went to her within the hour with the headline first: a bug I shipped had overcharged tax by a few cents on some orders since the 3rd. I had already pulled the numbers: about 1,800 orders, roughly $2,100 in total. I explained what my test had missed and then laid out options: a fix that could ship that day, automatic refunds through the payment provider, and a short note to affected customers drafted with support. I recommended doing all three and offered to write the refund script myself.
Result: The fix shipped that afternoon, and all affected customers were refunded within two days. Support received only a handful of contacts about it. I added a tax-rounding test suite for every state we sell in, and my manager asked me to present the incident review to the wider engineering team as an example of how to report problems.
Example answer we wrote: telling a team (engineering manager)
Situation: I managed a team of seven engineers who had spent four months building a new analytics product. Leadership decided to cancel it after a pricing review showed it would not reach profitability.
Task: I had to tell the team their project was cancelled, keep their trust and get them ready to move to new work within two weeks.
Action: I asked leadership to let me tell the team the next morning, before any company-wide announcement, so they would not hear it secondhand. I opened the team meeting with the decision in one sentence, then explained the actual reasons, including the pricing numbers I was allowed to share. I said plainly that I had argued for more time and lost, and that I understood the decision. I acknowledged the work they had put in and gave them space to ask anything. Then I held one-on-ones the same week to understand each person's preferences for what came next, and I worked with two other managers to place people on projects that matched them.
Result: All seven engineers moved to new projects within two weeks, and no one left the company in the following six months. Two components the team built were reused in other products. In our next engagement survey, my team's score for trust in their manager rose compared with the previous survey.
Weak vs strong answers
| Part of the answer | Weak | Strong |
|---|---|---|
| Timing | “I waited until I was completely sure” | “I called them the same afternoon” |
| Opening | Five minutes of context before the news | The news in the first sentence |
| Ownership | “Another team's delay caused it” | “We committed to the date before it was scoped; that was on us” |
| Options | “I told them and let them figure it out” | Two or three choices with a recommendation |
| Empathy | Not mentioned | Time to react and questions answered honestly |
| Result | “They took it well” | What happened next, a number and the state of the relationship |
Follow-up questions to expect
- Why did you deliver it in person (or by phone, or in writing)?
- How did the other person react, and how did you respond?
- Was there any temptation to wait? Why didn't you?
- What would you do differently next time?
- Tell me about a time you had to give someone difficult feedback.
The last follow-up is a related question with its own answer guide: how to answer “tell me about a time you gave difficult feedback.” If your bad news was a date you could not hit, also prepare for the missed deadline question.
Mistakes to avoid
- Making yourself the messenger only. If the cause was partly yours, say so. Stories with no ownership sound rehearsed and defensive.
- Burying the headline. If your story describes a long lead-up before you got to the point, interviewers assume you do the same at work.
- Bad news with no plan. Delivering a problem without options pushes all the work onto the listener.
- Blaming others. Even when another team caused it, criticizing them makes you look like a risky colleague.
- Waiting too long in the story itself. “I knew for two weeks but wanted to be sure” is the opposite of what the question rewards.
Bad news stories sit close to stories about mistakes and expectations. See our guides to answering “tell me about a time you made a mistake” and managing stakeholder expectations, and the full list of “tell me about a time” interview questions to plan your story bank.
Practice it
This is a story people tend to soften when they say it aloud. Rehearse it once and check whether the news itself appears in your first two sentences. If it does not, cut the setup. The free STAR story builder helps you draft each part before you speak it.
Then practice under pressure. CoPilot Interview's AI mock interview mode builds questions from your résumé and the job description, reads them aloud and scores each spoken answer out of 10 with what to fix and a model answer to compare. It is free for 15 minutes a day with no account, enough to run this answer and its follow-ups.
Rehearse the hard conversation before the interview
Answer by voice, get a score out of 10 with clear fixes, and try again until the headline comes first. Free for 15 minutes a day, no account needed.
Try a free AI mock interviewFAQ
What is a good example of delivering bad news at work?
Good examples include telling a customer a promised date would slip, telling your manager about a bug you shipped, or telling a team their project was cancelled. The best stories show early timing, a clear headline, ownership and options.
Should the bad news be my fault?
It does not have to be, but stories where you owned part of the cause are often stronger because they show accountability. If it was not your fault, show that you did not hide behind that fact.
How do I start a bad news conversation?
Lead with the news in one plain sentence, such as "the integration will not be ready on October 1." Then explain the cause, the impact and the options. Long warm-ups make people more anxious.
Should I deliver bad news by email or in person?
Serious or personal news is usually best delivered by phone, video or in person, then followed by a written summary. Routine updates can go in writing. Explain your choice if the interviewer asks.
How long should the answer be?
About two minutes. Spend most of it on how you delivered the news and what you offered, and finish with the outcome and relationship.
Is this the same as "tell me about a time you gave difficult feedback"?
No. Difficult feedback is about how a colleague performs or behaves. Bad news is about an event or decision, such as a delay, defect or cancellation. Prepare a separate story for each.