Most people prepare for "tell me about a project you are proud of". It is easy. You get to brag a little.
The three questions in this note are the opposite. "Tell me about a disagreement." "Tell me about a time you failed." "Tell me about hard feedback you got." Your stomach drops a bit when you hear them, and that is exactly why interviewers ask them. Anyone can look good when things go well. They want to see what you do when things go badly.
The good news is that all three have the same hidden shape. Once you see it, you can build an honest answer for each one in about an hour.
The shape behind all three
Think of a school report card. Nobody is worried about the marks you got in your best subject. The teacher reads the weak subject, and then checks one more thing: did the student do anything about it?
Interviewers read your answer the same way. They listen for four things:
- Did you tell the truth about what happened, including your part in it?
- Did you stay calm and fair to the other person?
- Did you learn something specific?
- Did you change what you do now?
If you hit all four, a small story beats a dramatic one. If you miss the third and fourth, even a great story falls flat.
Keep this four-step line in your head. Every answer below follows it.
A word on length. Aim for about two minutes spoken, which is roughly 250 to 300 words. The sample answers below are a little longer than that so you can see all the parts. Trim them when you practise.
Question 1: A disagreement with a teammate
What the interviewer is checking
They are not looking for someone who never argues. A team where nobody disagrees is a team where people stay quiet and the bugs ship. They want to know if you can disagree and still work with the person next week.
Specifically they check whether you listened to the other side, whether you used facts instead of feelings, whether you could let go when you lost, and whether the relationship survived.
A bad answer
"My teammate wanted to use MongoDB but I knew it was the wrong choice. I showed him why it was wrong and eventually the team agreed with me. He was not very experienced so it took some time."
Read it again as the interviewer. You learn nothing about the other person's reasons. The teammate is made small ("not very experienced"). You were right, the story ends with you winning. And there is no sign that you ever asked yourself whether he had a point.
Interviewers hear this a lot. It reads as someone who needs to win.
A good answer, in full
Here is a made-up example. Use it to see the parts, then replace it with your own story.
Say the question is "Tell me about a disagreement with a teammate", and the answer goes like this.
"On a previous team, we were building a notification feature for an order tracking app. About 40,000 users, so not huge. Another engineer on the team, I will call him Dev, wanted to build it on a message queue with a separate worker service. I wanted to keep it simple: save the notification in the database and have a job run every minute to send it.
We went back and forth in the pull request for two days, and honestly it was getting a bit sharp. So I asked him to have a quick call instead.
On the call I asked him why he wanted the queue. His reason was something I had not thought about. The marketing team had told him they planned a big sale in two months, and they expected maybe 10 times the traffic. A job that polls the database once a minute would fall behind, and users would get 'your order shipped' messages 20 minutes late.
My worry was the other side. A queue meant a new service to run, new alerts to set up, and only two of us on the team who understood it.
So instead of arguing about which design was better, we wrote down what we both cared about: messages arrive within 30 seconds, and the team can support it at night without calling Dev. Then we tested my approach. I ran a quick load test with 10 times the traffic. The one-minute job fell behind by about 8 minutes. That settled it. He was right about the sale.
But we also did not go with his full design. We picked a managed queue service from our cloud provider, so there was nothing new to run. We wrote a one-page note so any engineer could debug it.
What I took from it: I had been arguing about my solution without knowing the facts he had. Now when I disagree with someone, my first move is to ask what they know that I do not. We still work together, and he asked me to review his next design before he wrote any code."
What makes this work:
- There is a number early (40,000 users), then a number that matters (10 times traffic, 8 minutes late).
- The speaker admits being wrong. This is the part most people are afraid to say, and it is the part interviewers trust most.
- The conflict ended in a third option, not a win for one side.
- The last lines show a changed habit and a healthy relationship.
The traps
- Picking a story where the other person was plainly a fool. Even if it is true, it makes you look hard to work with.
- Picking a tiny story ("we disagreed about tabs and spaces"). It shows nothing.
- Saying "I have never had a real conflict". Nobody believes this. It reads as either no experience or no honesty.
- Winning by escalation, such as "I went to the manager and she agreed with me". Sometimes that is right, but it should not be the main move in your story.
- Skipping the ending. If you do not say how things were afterwards, the interviewer assumes it went badly.
How to disagree with a manager
This question comes in many forms: "Tell me about a time you disagreed with your manager", "...pushed back on a decision", "...disagreed and then committed."
The picture to keep in mind is a bank counter. The cashier cannot approve a loan on their own, but a good cashier will still say "I think this form is missing a page" instead of quietly stamping it. You can do the same with a manager: say your concern clearly, once, with a reason, and then accept that the decision belongs to them.
A sensible order:
- Ask a question first. "Can you help me understand why we are picking this?" You may learn something.
- Say your concern in private, not in front of the whole team.
- Bring facts or numbers, not a feeling. "This adds about 3 weeks and our deadline is in 4" lands better than "I think it is too risky".
- Offer an option, not only a complaint.
- If the manager still decides the other way, commit. Do the work properly. Do not say "I told you so" later.
The phrase "disagree and commit" means exactly step 5: you gave your view, the decision went the other way, and now you help make it work.
A short sample, again made up.
"Our manager wanted to ship a new search page before a Friday demo. I had checked and the page was slow with large accounts, about 9 seconds for anyone with more than 5,000 records. I asked for 10 minutes and showed her the numbers. I said I was worried the client would see a spinner on the biggest account in the demo, and I suggested we either demo with a smaller account or spend two days on an index.
She decided to go ahead with the demo using a smaller account, and keep the index work for the following week, because the demo date was fixed and the two days were not. I disagreed a little, but her reasoning was fair. I helped by preparing the demo data. The demo went fine, and I did the index work the next week. Search dropped to under a second.
The part I learned was to put the cost of waiting in the same sentence as my worry. She could weigh it, instead of just hearing me say no."
Traps with managers: sounding like you resent them, telling a story where the manager was a villain, or the opposite, a story where you caved at once and never said anything. Both versions fail. You want to show a spine and respect together.
Question 2: A time you failed
What the interviewer is checking
Here is something that surprises people. The interviewer is not trying to catch you out. Every engineer they have ever worked with has broken something. They are checking that you can say it plainly, without shrinking it or blowing it up.
They look for:
- A real failure with a real cost, not a polished one.
- Ownership. You say "I", not "the team" or "the process".
- A lesson that is specific enough that they could test it.
- Proof the lesson stuck, meaning a change in what you do afterwards.
Fake failures
Every interviewer has heard these.
- "I work too hard."
- "I care too much about quality."
- "I am a perfectionist."
These are compliments dressed up as faults. They are the quickest way to look like you are hiding something. Do not use them.
A real failure has a cost you can name: hours lost, a deadline missed, money, a customer upset, a teammate who had to clean up. If you cannot name a cost, it is probably not a failure story yet.
Also avoid the other extreme, a failure so large that it raises worries about hiring you ("I deleted the whole customer database and the company nearly closed"). Pick something real but recoverable, where you did the right things after.
A bad answer
"My biggest failure was a project that was late. The requirements kept changing and the product manager did not give us clear direction. We eventually delivered it, and I learned to communicate better."
Count the blame: requirements, the product manager. Count the lesson: "communicate better", which could mean anything. No number, no action, no change. The interviewer learns nothing about you.
A good answer, in full
Say the question is "Tell me about a time you failed", and the story is invented, like this.
"Early on a team of five, I was asked to add a discount code feature to a checkout page. It was a two-week task and I estimated it at 5 days, because it looked simple. I did not ask anyone to look at my plan.
What I missed was that discount codes had to work with gift cards, and with the refund flow. I found that on day 6. By day 10 I was clearly late, and I had said nothing, because I kept thinking I could catch up over the weekend. I did not.
On day 11 my lead asked how it was going and I told her the truth. The launch was already announced to a partner for day 12. We missed it by 5 days. The partner was not happy, and two other engineers spent about a day each helping me finish.
I said sorry to the team, in the standup, in one sentence. Then I sat down with my lead and asked her what I should have done. She said the real mistake was not the estimate, it was the silence between day 6 and day 11.
Two things changed for me after that. First, if I am more than 20 percent over an estimate, I tell my lead the same day, with a new date. Second, before I give any estimate on something that touches payments, I write the list of other features it touches and ask someone who knows the code to read it. On the next three tasks, my estimates were within a day.
I still think about it when I am tempted to quietly work harder instead of saying 'this is slipping'."
Notice the structure. The failure is clear, the number is plain (5 days estimated, 5 days late, two people for a day each), the speaker owns the silence rather than only the estimate, and the lessons are rules you could check.
The traps
- Blaming the situation. Context is fine ("the deadline was tight"), but the story must still be about your choice.
- No lesson, or a lesson like "I learned to be more careful". Careful how?
- A lesson with no change after. "I learned to ask for help" is weak unless you say when you last did it.
- A failure that was really somebody else's. If your answer starts with "so my teammate made a mistake and..." it is a different story.
- Going on too long about the pain. About a third of your time should go on what happened, and two thirds on what you did and learned.
Talking about a production incident you caused
This is a special case of "a time you failed", and it is very common for engineers. A production incident means something went wrong on the live system that real users were using. "I took down the site" is not a story that ends your career. How you handle it in the interview says a lot.
Picture a restaurant where the cook sends out the wrong dish. The customer does not remember the mistake as much as how the restaurant fixed it. Interviewers feel the same.
A good incident answer has a clear order:
- What broke, who felt it, for how long. Use real units: "checkout was failing for about 25 minutes, around 600 users saw an error."
- How you found out, and what you did first. Usually this is "roll back" before "find the cause". To roll back means to go back to the version that worked.
- What caused it, in one plain sentence, with your part named.
- What you told people while it was happening.
- What changed afterwards. A blameless review (a meeting where the team looks at how the system allowed the mistake, not who to punish) and one or two real fixes.
A made-up example:
"Say I pushed a database change on a Tuesday afternoon that added a required column to an orders table. I had tested it on a small test database. On the real one, with about 2 million rows, it locked the table, and checkout started failing at 3:10 pm.
I saw the alert within two minutes and told the team channel at once: 'I think my change caused this, I am rolling it back.' It took 7 minutes to roll back and about 25 minutes in total before orders were normal. Around 600 customers hit an error and we lost a few dozen orders.
In the review the next day, I did not defend myself. The facts were that I had tested on a table that was a hundredth of the real size, and nothing in our process caught that. We made two changes: a check that runs big migrations on a copy of real data, and a rule that schema changes do not go out after 2 pm. I wrote the first check myself."
Three habits make or break this story.
- Say "my change" and not "a change was deployed". The passive voice sounds like hiding.
- Do not lie about the damage to look smaller. If you are unsure of a number, say "roughly".
- Do not turn it into a story about heroic night work. Calm and honest beats dramatic.
If you have never caused a production incident, pick a near miss, where you caught something just before it shipped, or an incident you helped fix. Say clearly which one it is. Do not claim one you did not have.
Question 3: Hard feedback
What the interviewer is checking
This one is about whether you are easy to teach. Feedback is how teams fix problems early. If you get defensive or collapse, people stop giving it to you, and then you stop growing.
They want to hear four things. You listened without arguing. You understood what was actually said. You did something with it. And you can show the difference afterwards.
A bad answer
"My manager once said I was too direct in code reviews. I think it is just that I care about quality, and some people are sensitive. But I tried to be a bit softer."
The feedback is dismissed ("some people are sensitive"), the change is vague ("a bit softer"), and there is no result. Also notice it is a thin version of the fake-failure trick: the feedback is really a compliment.
A good answer, in full
Say the question is "Tell me about hard feedback you have received", and this is an invented answer.
"About a year into a job, my lead told me in a one-to-one that my pull requests were hard to review. Some of them touched 25 or 30 files. Two teammates had told her they put off reviewing mine, and my changes were waiting two to three days for a review.
My first reaction was a bit defensive, if I am honest. I thought: everything in one change belongs together. I said nothing for a moment, and then I asked her to show me an example. She pointed at one change with 1,100 lines. Looking at it with fresh eyes, I could see maybe four separate changes in it, a rename, a small bug fix, a new feature, and some tests.
So I decided to try something for a month. I would keep every pull request under about 300 lines, and put renames and cleanups in their own change. I told my lead the plan, so she could check in on me.
After a month the average wait for a review had gone from about 2 days to under 1 day. One teammate told me, without being asked, that mine were now the easy ones to review. I also noticed I was finding my own mistakes while splitting changes.
I still keep to the 300-line habit. And since then, when someone gives me feedback, I try to ask for one concrete example before I answer, because it stops me arguing with a general idea."
Why this works: the speaker admits the first reaction. It is a human detail, and interviewers like it. Then they move from feeling to action, with a measurable change.
The traps
- Choosing feedback that is secretly praise ("I was told I am too passionate").
- Choosing something harmless, like being too quiet at one meeting.
- Choosing something so damaging that it raises concern ("my manager said I was rude to customers") and then having no solid fix.
- Arguing with the feedback in the retelling. Even if you partly disagree, say what you took from it.
- Saying the feedback was wrong. If it truly was, say what you learned about how others see you.
Quick comparison
| Question | They want to hear | Common trap |
|---|---|---|
| Disagreement | You listened, used facts, kept the relationship | Making the other person look foolish |
| Failure | A real cost, your part, a real lesson | "I work too hard" |
| Hard feedback | You heard it, acted, and it improved | Dismissing the feedback |
| Disagree with a manager | Said it once, with a reason, then committed | Either caving silently or sulking |
| Production incident | Calm facts, fast rollback, a fix to the process | Passive voice and shrinking the damage |
How to find your stories
You do not need a movie plot. You need three small true memories. Open your pull request history, your old chat messages, or a retro (a team meeting where the team looks back at the last stretch of work) from the last two years, and look for these:
- A pull request with a long argument under it.
- A date that moved.
- A bug that reached users.
- A review comment that stung.
Write each one as four lines: what happened, my part, what I did, what changed. Do not write a script. Scripts that you memorise word for word come out stiff, and interviewers can hear it. Memorise the four lines and numbers, and say the rest in your own words.
If your stories involve people, do not say their full names. First names or "a teammate" are fine. Never say anything about a former employer you would not want repeated.
Try it yourself
Take 30 minutes, a pen and a timer.
- Write one true story for each of the three questions, in four lines each.
- For the failure story, underline the cost. If there is no number or no clear loss, pick another story.
- Say each story out loud to your phone's voice recorder. Stop at 2 minutes. Listen back and note any sentence where you blame someone.
- Find the sentence in each story that starts "Now I..." If you cannot write one, the story is not finished.
- Ask a friend to interrupt with "and what did you do about it?" at any point. Your answer should be ready.