Failure, Mistakes, Pressure and Ambiguity

Interviewers ask about failure because everyone fails, and how you respond to failure predicts how you will perform when things go wrong on their watch. The same applies to pressure and ambiguity: real work rarely arrives with clear instructions and generous time. A candidate who says "I have never failed" gives no information and loses credibility. This chapter explains what a good failure story looks like, how to talk about mistakes honestly without damaging your case, and how to handle questions about pressure, deadlines, changing requirements and multitasking.

1. Why they ask

• Honesty and humility: can you admit a mistake plainly?
• Accountability: do you own it, or blame others?
• Learning: what changed afterwards?
• Resilience: did you recover and keep going?
• Judgement: was it a reasonable risk, or reckless?
• Impact awareness: do you understand who was affected?

The best answers describe a real, moderate failure in which you did something wrong or misjudged, explain the cause without excuses, describe how you repaired the damage, and show a lasting change.

2. Choosing a failure story

Freshers can use: a project that failed to meet its goal, a bad exam result and what changed in how you studied, a missed deadline in a team task, a failed attempt at a competition or an interview, an internship task that went wrong.

3. The shape of a good failure answer

1. What happened (briefly, factually).
2. What went wrong and why, including your part.
3. What you did immediately to limit the damage and communicate.
4. What you changed to prevent repetition.
5. A later example where the change helped (the strongest finish).

Spend a short time on the failure and the greatest part on what you did and learned.

4. Sample answers

A mistake at work or in an internship

Question: "Tell me about a time you made a mistake."

"In my internship, I was asked to update the discount rate in a pricing configuration. I changed the value in the test environment, checked it, and then applied the same change in production without re-checking the file, which had a different structure. The wrong field was changed, and for about forty minutes some products showed incorrect prices before our monitoring flagged it. I told my mentor immediately, reverted the change, and helped to list which orders were affected so that the support team could handle them. Afterwards I wrote a short checklist for configuration changes: verify the target, make the change through a reviewed pull request, and run a diff before applying. I have used that checklist for every change since, and in a later task it caught a similar mismatch before it reached production."

Features: an honest account, a specific cause (skipped a check), immediate disclosure, damage control, a durable process change, and evidence of the change working.

Missing a goal in a project

Question: "Tell me about a time you failed."

"In my second year, I led our team's entry into a national software competition and we did not reach the finals. Looking back, I made two mistakes: I spent the first three weeks refining the idea and left only two weeks to build it, and I did not ask for feedback from a mentor until the last day. We submitted a working but unpolished prototype. After the result I asked a senior for a review, and he pointed out that the problem statement was unclear and the demo hid our best feature. In the next competition, I set a rule that we would have a rough working version in the first week, and I booked a mentor review at the halfway point. We reached the finals that time. The setback taught me that building early and seeking feedback early matter more than perfecting the plan."

A bad academic result

"In my first semester I failed a mathematics paper. I had been studying the night before and assuming that my school habits would work. I talked to the professor, who showed me where I had lost marks, and I realised I had never practised problems under timed conditions. I started solving previous papers every weekend and formed a small study group, and I cleared the paper in the next attempt with a good margin and did well in the subsequent semesters. It taught me that my method, not my ability, was the issue."

Be careful with backlogs and low marks; the chapter on tricky questions shows how to frame them.

5. What not to do

• Do not blame: "The team did not support me", "The manager gave unclear instructions". Mention contributing factors only briefly and factually, and always include your own part.
• Do not grovel: the tone should be calm and matter-of-fact.
• Do not leave it open-ended: the answer must finish with change.
• Do not describe a mistake that raises a safety, ethics or integrity concern unless you are prepared to explain how you corrected it and why it will never happen again.
• Do not hide behind generalities ("I once made a minor error").

6. Handling pressure

Question: "How do you handle pressure?" or "Tell me about a time you worked under a tight deadline."

Interviewers want a method, not a claim of being "cool under pressure". A reasonable approach:

1. Clarify what is truly required and the real deadline.
2. Prioritise by impact and dependency; cut or defer the rest.
3. Break the work into small steps and start the riskiest first.
4. Communicate early about risks and trade-offs.
5. Ask for help where it will speed things.
6. Protect quality in the critical part; skip polish, not correctness.
7. Look after yourself (short breaks, sleep), because exhaustion causes errors.
8. Review afterwards to learn why the pressure arose.

"In my final semester I had a major project deadline, two exams and a hackathon within the same ten days. I wrote down everything with dates and sorted it by impact. The hackathon was optional, so I told the team early that I could join only for the first day; I put the exams ahead of the project polish and did the project's core in the first three days. I told my project guide that I would submit the main features on time and the report formatting a day later, and he agreed. Everything was submitted, and I did well in the exams. The thing that helped most was being honest early about what I could not do."

7. Ambiguity and changing requirements

Real tasks come with missing details and moving targets. Interviewers ask: "Tell me about a time the requirements changed", "How do you work when instructions are unclear?", "What would you do if you were given a vague task?"

A good approach:

1. Ask clarifying questions to find the goal, the user, the constraints and the definition of done.
2. State your assumptions and confirm them.
3. Start with a small first version or a rough plan, and get feedback early.
4. Break the problem into parts and begin with the parts you understand.
5. Keep the work adaptable (modular, easy to change).
6. Communicate changes and their consequences (time, cost) clearly.

"In my internship, my manager asked me to 'make the report faster'. I asked which report, how slow it was, and what would be fast enough. It turned out that one report took about forty seconds and the target was under five. I measured where the time went, found one slow query, and showed my findings before changing anything. That conversation avoided a week of optimising the wrong thing."

When requirements change midway: acknowledge it without complaint, assess the impact, explain what needs to move (scope, date or resources), and adjust. "I treat a change as new information, not an insult."

8. Multitasking and priorities

"How do you prioritise multiple tasks?" Offer a framework: list tasks, mark deadline and importance (urgent-important grid), consider dependencies and the effort, agree priorities with your manager where there is a conflict, and review daily. Mention a tool you actually use (a task list, calendar blocking, a board).

"What do you do when two managers give conflicting priorities?" Bring them together or ask them to align, with a short summary of the trade-off: "I can finish A by Thursday or B by Wednesday, not both. Which is more urgent?"

9. Resilience and rejection

"How do you handle rejection or setbacks?" Acknowledge the disappointment, find the lesson, adjust, and try again. If you have been rejected in other interviews, you can say: "I have been rejected by two companies, and each time I asked for feedback or reviewed the interview myself. I realised I needed to practise explaining my projects more concisely, and I have been working on that."

"Tell me about a time you were not selected for something you wanted." Describe it, what you did next, and what you gained.

10. Common mistakes

• "I have never failed."
• A fake failure disguised as a strength.
• Blaming others or circumstances.
• No change afterwards (a failure story without learning).
• Excessive apology or self-criticism.
• Claiming you thrive on pressure without any method.
• Panic stories, where the pressure is described but nothing was done.
• Pretending ambiguity does not trouble you, or the opposite: refusing to start without full instructions.

11. Practice questions

1. Tell me about a time you failed. What did you learn?
2. Describe a mistake you made and how you handled it.
3. Tell me about a time you worked under a tight deadline.
4. How do you work when the requirements are unclear?
5. Tell me about a time the plan changed in the middle of a project.
6. How do you prioritise when everything seems urgent?
7. Tell me about a time you were rejected or did not get what you wanted.