To answer "tell me about a time you made a difficult decision," choose a decision where every option had a real cost, explain the options and the criteria you used to choose, state the call you made and the downside you accepted, and finish with the result and what you would keep or change. The interviewer is grading your reasoning more than the outcome, so spend most of your answer on how you weighed the trade-off. About two minutes is enough.
This is one of the questions in our tell-me-about-a-time question bank, which groups the common behavioral prompts with answer frames for each.
What is the interviewer really testing?
A difficult decision is one where the right answer was not obvious and someone was going to be unhappy. Interviewers use the question to see how you think when there is no clean option: whether you gather enough information without waiting forever, whether you consider people as well as numbers, and whether you own the downside instead of pretending there was none.
| Signal | A strong answer shows | What weakens it |
|---|---|---|
| Real stakes | Every option cost something: time, money, trust or a relationship | A choice with an obvious right answer |
| Reasoning | Named options and the criteria you used to compare them | "I went with my gut" |
| Timing | You decided with enough information, not perfect information | Months of analysis, or no analysis at all |
| Ownership | You made the call and said "I decided" | The decision just "happened" to the team |
| Follow-through | You managed the fallout and checked whether it worked | The story ends the moment you chose |
Some companies describe this trait explicitly. In his 2016 letter to shareholders, Jeff Bezos wrote that most decisions should probably be made with somewhere around 70% of the information you wish you had, and that many decisions are reversible "two-way doors." You do not need to quote anyone in your answer, but showing that you knew which kind of decision you were facing is a strong signal.
The trade-off frame: how to show your reasoning
Use STAR as the outer structure, and put these five beats inside your Action:
- Options. Name two or three real options. Not a straw man and the obvious winner.
- Criteria. What mattered most, and why: customer impact, deadline, cost, team health, long-term risk.
- Information. What you checked before deciding, and what you still did not know.
- The call and its cost. What you chose and the downside you knowingly accepted.
- Mitigation. What you did to reduce that downside, including how you told the people affected.
| Beat | What to say | Example line |
|---|---|---|
| Options | The realistic choices on the table | "We could delay the launch, cut scope, or ship and patch." |
| Criteria | What you were optimizing for | "Our biggest customer's renewal depended on reliability, not the new feature." |
| Information | What you checked and the gaps you accepted | "I had incident data and two customer calls; I did not have a full cost estimate." |
| Call and cost | The decision and the price | "I chose to delay, knowing sales would lose a demo date." |
| Mitigation | How you softened the downside | "I gave sales a dated plan and a preview build for their demo." |
How do you answer "tell me about a time you made a difficult decision"? Three example answers
These are example answers we wrote for three common types of difficult decision: resourcing, technical and people. The details and numbers are invented to show structure. Use your own story and your own numbers.
Example we wrote: a resourcing decision
Situation. I led a team of six engineers. Six weeks before a feature launch that sales had already promised to customers, our error rate on the core checkout service doubled after a traffic spike, and on-call pages were waking people up most nights.
Task. I had to decide whether to keep everyone on the launch or pull people onto reliability work.
Action. I laid out three options: keep the launch date and accept the pages, split the team, or move two engineers to reliability for a month and slip the launch. My criteria were customer impact first, then the team's ability to sustain the pace. The incident data showed failed checkouts on roughly 1 in 200 orders, which hurt every customer, while the new feature mattered to three accounts. I chose to move two engineers to reliability and slip the launch by three weeks, knowing sales would be unhappy. I told the sales lead in person before announcing it, gave her a dated plan and arranged a preview build for her key demo.
Result. The error rate returned to its previous level within four weeks and on-call pages fell by about 70%. The feature launched three weeks late, and all three accounts that had asked for it adopted it in the first month. I now flag reliability risk at planning time so the trade-off comes up earlier.
Example we wrote: a technical decision
Situation. I was the senior engineer on a data platform team. Midway through migrating our pipelines to a new orchestration tool, we found it handled our largest nightly jobs poorly, and three months of work were already done.
Task. I had to recommend whether to push through, roll back, or change approach.
Action. I timeboxed one week to gather evidence. I ran our five heaviest jobs on the new tool with production-sized data and wrote down the failure modes. Pushing through meant custom workarounds we would maintain for years; rolling back wasted the quarter. I proposed a third option: keep the new tool for the roughly 80% of pipelines it handled well and leave the heaviest jobs on the old system until we could redesign them. The cost was running two systems for a while, which I stated plainly in the design doc, along with a date to revisit the decision.
Result. We finished the migration of the suitable pipelines a month later than first planned, without the custom workarounds. Nightly job failures dropped from about four a week to under one. Six months later we redesigned the heavy jobs and retired the old system on schedule.
Example we wrote: a people decision
Situation. As an engineering manager, I had a well-liked senior engineer leading a cross-team project. Two milestones had slipped, and the partner team's lead told me privately they had lost confidence in the plan.
Task. I needed to decide whether to keep him as lead, add support, or hand the lead role to someone else.
Action. Before deciding, I met with him to hear his view, reviewed the project plan and talked to two engineers on the partner team. The problem was coordination, not technical skill: he was strong on design but was not running the cross-team syncs or tracking dependencies. Adding a co-lead risked confusion, so I chose to move the lead role to a teammate with stronger coordination skills and keep him as technical owner of the design. I knew he would be disappointed. I told him first, privately, explained my reasoning, and agreed on specific coordination goals for his next project so the change had a path back.
Result. The project hit its next two milestones and shipped one sprint behind the original plan. He stayed on the team, and he led his next cross-team project successfully the following year.
Weak vs strong answers
| Part of the answer | Weak version | Strong version |
|---|---|---|
| The decision | Which framework to use for a side project | A choice where every option hurt someone or something |
| Options | Only the option you picked | Two or three realistic options, briefly compared |
| Reasoning | "It felt right" | Named criteria and the evidence you checked |
| Cost | No downside mentioned | The downside you accepted, stated plainly |
| People | Absent | How you told and supported the people affected |
| Result | "It worked out" | Numbers, dates and what you learned about deciding |
If your decision involved disagreeing with your boss, you may be better served by our guide on answering "tell me about a time you disagreed with your manager". If it hinged on numbers, see a time you used data to make a decision, and if the decision carried real downside risk, a time you took a risk is a natural pairing. A fill-in version of the structure is in our STAR method template.
What follow-up questions should you expect?
- What other options did you consider, and why did you reject them?
- What information did you wish you had?
- Who disagreed with you, and how did you handle it?
- Was the decision reversible? How did that affect how fast you moved?
- Looking back, was it the right call? What would you do differently?
- How did you communicate the decision to the people it affected?
The "was it the right call?" follow-up is where many candidates get defensive. It is fine to say that with hindsight you would have decided sooner or handled one conversation differently. That shows judgment, not weakness.
Mistakes to avoid
- Choosing an easy decision. If anyone would have made the same call in five minutes, it does not show much.
- Hiding the cost. A decision with no downside sounds either trivial or edited.
- Telling only the outcome. "We delayed the launch and it went well" skips the part the interviewer is scoring.
- Blaming the people affected. In a people decision, describe the gap respectfully and keep confidential details out.
- Picking a decision someone else made. Use a call where you were the decision maker or the person whose recommendation carried it.
- Running long. Keep the situation short so the trade-off gets the time.
Practice it
The trade-off frame only sounds natural after you have said it out loud a few times. Write the five beats in the free STAR story builder, then rehearse with an AI interview assistant like CoPilot Interview. Its Mock Interview 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, so you can see whether your reasoning came through. It is free for 15 minutes a day, with no account needed. Follow each employer's rules and use AI to prepare beforehand, then answer in your own words on the day.
Test your decision story before the interview
Answer out loud, get a score out of 10 and find out whether your reasoning, not just your outcome, comes across.
Try a free AI mock interviewFAQ
What counts as a difficult decision for this question?
A choice where every option had a real cost, such as delaying a launch, reversing a technical approach, reassigning a person or saying no to an important stakeholder. If the right answer was obvious, pick a different story.
Should the decision have turned out well?
Not necessarily. A decision that only partly worked is fine if you can explain your reasoning, what you learned and what you would change. Interviewers care more about how you decided than whether you were lucky.
Can I talk about a personal decision instead of a work one?
Use a work, school or volunteer decision if you can, because the interviewer wants to see how you will make decisions in the job. A personal decision such as a career change can work if it shows clear trade-offs, but keep private details brief.
How do I describe a people decision without sounding harsh?
Describe the gap factually, show that you heard the person out first, explain why the decision helped the team and the person, and say how you communicated it. Leave out names and confidential details.
How long should the answer be?
About two minutes. Keep the situation to two sentences and spend most of the time on the options, criteria and the cost you accepted.
What if I made the decision with a group?
That is common. Make clear which part was yours, for example that you framed the options and made the recommendation, and say "I" for your own actions.