Stories About Failure, Conflict and Hard Feedback

In one line: failure, conflict and hard feedback stories are where interviewers learn the most about you, because they are the moments when pretending is hardest. A strong answer owns its part, stays calm about the other person, shows what you changed, and ends with a lesson you actually use.

What I ran / checked. Nothing was run, since there is no code here. What I read (own words only): the behavioral interview preparation page and the list of 30 common questions in the yangshun/tech-interview-handbook GitHub repository (raw markdown). From that list I took real examples of how these questions are asked, such as "Tell me about a time you had a conflict with a co-worker", "Tell me about a time in which you had a conflict and needed to influence somebody else", "Tell me about a time you had a disagreement with your manager", "What is the most constructive feedback you have received in your career", "How have you handled criticism of your work", "Tell me a situation where you would have done something differently from what you actually did", and "What is the most bad misstep you've made at any point". The handbook's STAR example is a conflict between a front-end developer and a designer. It shows that a good conflict story talks to each side separately, finds the real reason behind the behaviour, and gives each person something. It also suggests adding a reflection at the end, which I use throughout. I also used general public knowledge of blameless post-incident reviews (a well-known practice in engineering teams); I did not fetch a specific document for it. Could not reach: rework.withgoogle.com, Harvard Business Review, Ladders, levels.fyi, Glassdoor pages, the official Cracking the Coding Interview site, and Amazon's principles page. No details from those are claimed. All people, teams and numbers below are invented.

"I'm a perfectionist, so I don't really make big mistakes. One time I did spend too long polishing a feature, and the deadline was close, but I managed to finish. I learned to manage my time better. Another time, a bug got into production, but it was because the requirements were not clear, so the team had to fix it. Overall I try to learn from everything."

"Last spring I ran a data fix script directly on our production database. A support ticket said about three hundred orders had the wrong status, and I wrote a script to correct them. I tested it on my laptop copy, and it looked fine.

What I did not do was a dry run on production first. The script had a filter that I wrote too loosely, and it also changed about nine hundred other orders from 'shipped' back to 'processing'. So roughly twelve hundred orders were touched in total.

I saw it within five minutes because the count printed by the script was four times what I expected. I stopped the script, told my lead right away in the team channel with exactly what I had done, and we restored the changed rows from the backup within the hour. No customers got emails, because the email job only runs at night. But for about an hour the warehouse screen showed wrong statuses, and two staff members had to double-check manually.

The mistake was mine: I skipped the dry run because I was in a hurry. Afterwards I wrote a short checklist for any script that touches production: run in read-only mode first, check the row count against the ticket, and ask a second person to read the query. I also added a 'dry run' flag to our shared script template. In the six months since, nobody has had a similar incident.

What I learned is that the moment I feel hurried is exactly when I should add a check."

"A few years ago I committed to delivering a reporting feature in three weeks. It took seven. I was the only developer on it, so the miss was mine to own.

The cause was that I estimated from the happy path. I counted the screens and the queries, but I did not count the time for unclear data. About a week in, I found that two of our customers stored dates in different formats, and that needed a cleanup I had not planned.

The mistake I made after that was bigger than the first one. I knew in week two that three weeks was not realistic, but I hoped to catch up and I did not tell my manager until week four. By then the sales team had already promised a date to a customer.

When I finally told her, she was not angry about the delay. She was unhappy that she heard about it late. We re-planned, cut one chart, and shipped in seven weeks. The customer was disappointed but accepted the new date.

Since then I do two things. I give estimates as a range, 'three to five weeks', and I list what could make it longer. And I tell my manager the moment I think a date is at risk, even if I am not sure. I would rather give a worry that turns out to be nothing than a surprise in week four."

"I once chose to build our own small job scheduler instead of using an existing library. My reasons were that the library seemed heavy, and our needs were simple. It was a two-week job and I led it.

Six months later, we needed retries, failure alerts and a way to see stuck jobs. I realised I was slowly rebuilding the library, with fewer tests. Two production incidents came from edge cases in my code, like jobs running twice after a restart.

When I saw the pattern, I wrote a short note for the team: what I chose, why, what it had cost so far, and what a switch would take. I estimated three weeks to move to the library. The team agreed, and we switched. The incidents stopped.

The part I would change is the first decision. I did not write down what we would need if the system grew, and I treated 'simple needs' as permanent. Now, before I build something that exists as a library, I write down three questions: what will we need in a year, who will maintain this, and what is the cost of switching later."

"I once worked with a developer who never listened. He always insisted his way was right, and he wrote code that nobody else could read. I tried to talk to him a few times, but he didn't change. Eventually I just went to our manager, and she handled it. I think some people are just hard to work with, and you have to avoid conflict when you can."

"On a recent project, a senior teammate, Marcus, and I disagreed about caching. We were building a product listing page that was slow. He wanted to cache the results in memory inside each server, which was fast to build. I wanted a shared cache, because with several servers, users would see different data depending on which server they hit.

The disagreement got a bit tense in a design meeting, because we both thought the other was missing something. Afterwards I asked him for fifteen minutes and started with a question: what worry made the in-memory option the best one to him? He said it was the time. The deadline was Friday, and a shared cache meant new infrastructure and approvals.

That was a fair point and I had not weighed it enough. So I said what I thought we both wanted: a fast page that is correct, shipped on time. I proposed a small test. We would do his in-memory version now with a short expiry of thirty seconds, which limits how stale data can get, and I would measure how often users saw different data. If it was a problem, we would plan the shared cache for the next sprint.

We shipped on Friday. My measurement showed mismatches in about one in two hundred page views, which the product manager accepted. We moved to the shared cache two sprints later when traffic grew.

What I took from it is to ask about the worry behind a position before I argue against it. Marcus and I have worked well together since."

"My manager wanted to use a certain approach for the project and I knew it was wrong. I told him, but he didn't listen, so I did it his way and it failed. Later, he admitted I was right."

"My manager, Anita, wanted to skip an admin screen for a new feature to save a week. I thought that support would end up paying for it. I could be wrong, so I started by checking. In the previous feature we shipped without an admin view, support had asked developers for help fourteen times in two months. I wrote that down, along with an estimate that a read-only admin page would take two days.

I asked her for ten minutes and said, 'I understand the week matters. Can I show you one number and a smaller option?' She looked at the fourteen requests and the two-day estimate and agreed to the smaller version. We shipped the read-only page, and in the next two months developers got three support requests for that feature, not fourteen.

I want to add that if she had said no, I would have followed her plan. It's her call, and she has more context about deadlines than I do. I would have written down the risk and offered to revisit it after launch.

What I learned is to bring a fact and a smaller option, not only an objection."

"A product manager asked me to add a feature to the current sprint. My team was already at full capacity with a security fix that had to be done. We both had good reasons, and for two days we were going back and forth in chat.

I realised chat was making it worse, so I asked for a quick call. I started by repeating what I understood: that her customer had a launch next week and the feature was important to them. She then heard that the security fix was a promise to another customer with a fixed date. We put the two items side by side on a shared page with my estimates and the date for each.

It became obvious that one of them could slip by a few days without any contract problem, and the other could not. We agreed to move the feature by three days, and I committed to starting it first thing on Monday. She told her customer the new date herself.

I learned that many conflicts about priority are two people not seeing the same list. Putting everything in one visible place often solves it without anyone having to win."

"I needed another team to change the format of an event they sent us, because it broke our parser. I had no authority over them and they had their own deadlines. Asking harder would not have worked, so I made it easy for them to say yes.

I first wrote a small example showing the exact failing message and how much time we lost, which was about four hours a week. Then I wrote the change they would need in two lines, and I offered to submit the pull request myself. Their lead only had to review it.

They merged it in two days. I thanked them in the shared channel, so their work was visible. What I learned is that to influence people, I should lower their cost, show the problem with a real example, and not expect them to care about my deadline as much as I do."

"We did not fully agree. I thought the new tool was a mistake, and the team lead decided to adopt it anyway. I made my case in the meeting, and I wrote my concerns in the decision document. After the decision, I helped with the rollout because it was the team's choice. Three months later, the tool did cause the issue I'd worried about, and I helped to reduce it. I did not say 'I told you so.' What I learned is that being right matters less than helping the team succeed with the decision it made."

"My manager once said I should communicate more. I thought I was already communicating enough, but I started sending more updates, and now I think I communicate well. I always welcome feedback because it helps me grow."

"A senior developer once told me that my pull requests were too big to review properly. My first reaction was defensive. I thought being thorough was a good thing, and I'd spent a week on that change.

But I decided not to argue until I understood. I asked him to show me one example. He pointed to a nine-hundred-line pull request that mixed a refactor, a new feature and two bug fixes. He said he had read the first two hundred lines carefully and skimmed the rest, because he couldn't hold it all in his head. That was a fair point: if the reviewer skims, the review is not doing its job.

I changed three things. I started to split work so each pull request has one idea, usually under three hundred lines. I wrote a short description of what to focus on. And if I found a refactor in the middle of a feature, I made it a separate pull request first.

Within a month, my average review time dropped from about two days to under one, and the comments I got were more useful, because people could read the whole thing. My manager mentioned it in my next review as the biggest change that year.

I learned to ask for one example whenever feedback feels vague. It turns an opinion into something I can act on."

"My manager told me that I was too quiet in meetings. At first I disagreed. I felt I spoke when I had something to say. But I decided to check, so I asked two teammates I trust. Both said that I often had good ideas which they only heard later in chat, and by then the decision was made.

So part of the feedback was true, though the real problem wasn't being quiet, it was timing. I changed how I prepare: I read the agenda the day before and write down one point or question to raise early. I did not change my whole personality. I told my manager what I was doing and asked her to tell me in a month if it helped. She said yes, and the decisions in our design meetings began to include my points.

I think it's fine to disagree with part of feedback, as long as I check it with facts first and keep the useful part."

"A teammate, Lena, often joined meetings late, and the rest of us began to wait for her. It was affecting the sprint planning. I did not want to bring it up in front of everyone, and I did not want to go to the manager before talking to her.

I asked for a private five minutes and began with a fact and its effect: 'In the last three planning meetings we started about ten minutes late, and we ran out of time to discuss the last stories.' Then I asked, 'Is something making it hard to be on time?' She told me that another meeting ended exactly when ours started, and she couldn't change it.

I had not known that. We asked the organizer to move our planning by fifteen minutes. The problem disappeared. Lena thanked me for asking, not accusing.

I learned to give feedback as a fact plus an effect plus a question. I find that the question often brings a reason I did not know."