What does the hiring person really want to hear in response to the question “Tell me a story where you really went wrong?”
Why do they ask about errors?
Do you know why they always ask this question at interviews? In fact, almost no one is interested in failure itself; everyone wants to hear how you think, how you get out of your ass, how you make decisions.
And for this there is a simple, but damn working scheme - STAR (yes, yes, you already heard 100%).
What is STAR
This is a way to structure your story so that it doesn't sound like:
Well, in short, there’s more to come...
But like a normal case, after which they believe you can work.
- S — Situation — the context of what actually happened.
- T — Task — what exactly was your task.
- A — Action — what steps did you take (in detail).
- R — Result - what is the result and what are the conclusions.
That's it. The whole magic is that you don’t jump between facts, don’t forget important things and don’t get lost in “well, it’s a long story...”.
Why STAR works
- You show the context (otherwise your fap may look either small or super scary).
- You emphasize personal responsibility rather than “we did it.”
- You highlight specific steps where your professionalism is visible.
- And most importantly, conclusions that prove that you do not repeat the same mistakes.
How to construct an answer
What not to do:
Well, I was wrong, we later fixed it. I have drawn conclusions.
No use. Not informative.
What's the right way? Clearly in structure:
Context → your role → your actions → result → conclusions.
5-7 sentences, but it sounds like the story of a real engineer, and not like a reply.
Why is this important for developers
Because many of us:
- Or they justify themselves with technical details (“well, PG didn’t calculate the plan that way”).
- Or they go into self-flagellation (“I’m just a fool”).
- Or they talk about “we” instead of “I”.
STAR helps you speak professionally:
Yes, I broke it. Here's how. Here's why. Here's how I fixed it. Here's what changed in my process.
Prepare your stories
Learn to talk about your mistakes competently. This is about the maturity of the developer, your competence.
It's okay to fuck off.
But if you can tell your fapcap using STAR, then you understand what you are doing, why you are doing it and how you are developing.
Prepare examples of mistakes from several areas:
- Technical problem.
- A problem in communication.
The following STAR examples show how to structure your own answers. Use them to tell stories from your actual experience.
From scheme to history
7 examples of mistakes
Five technical situations and two stories about communication. In each example - what happened, how they decided and what conclusions were drawn.
Technical problem
Refactoring that broke a rare case
Description:
I started refactoring the old logic while executing the task. Test coverage is poor. I hit a rare case, the units passed, I didn’t notice any regression.
What happened:
After 1–48 hours, a bug appeared in certain situations. At first they didn’t understand what was happening. I remembered that I touched the code of this particular functionality.
How I decided:
I immediately told the team that I could catch the logic. We rolled back the feature and specifically corrected the data in the database.
Conclusions:
Before refactoring, I understand the code, check the coverage, write tests and documentation. We run all rare behavior options on a test bench - and only then deploy.
Units that worked on a live test base
Description:
I came to the project, didn’t understand docker-compose and launched units. It turned out that the image was looking at a common test database.
What happened:
The tester noticed strange data on the stand. We figured it out - my tests generated it.
How I decided:
Corrected .env so that by default everything goes to the local docker database. The excess data was cleared along with the tester.
Conclusions:
Before running any tests/scripts, I double check the environment and configs.
Cleanup script that destroyed demo data
Description:
There was a script for local data cleaning. I launched it on a general demo/test bench by mistake.
What happened:
I demolished all the demo data before the important show. The team was “delighted.”
How I decided:
We refilled the stand with data - tests and pens.
Conclusions:
Before launching anything destructive, I make sure to check the environment. Twice.
Deploy on Friday (classic)
Description:
The big task was completed by Friday. We checked it with a tester on the test bench and suggested releasing it.
What happened:
On production, in 5% of cases the functionality broke. They wanted to roll back, but they couldn’t: new data had already appeared.
How I decided:
On Friday evening, my colleague and I edited the data manually until the system was back in order.
Conclusions:
Friday deployment is only for small changes. I always think through a rollback plan in advance and the conditions under which it is possible.
Suboptimal query that slowed down production
Description:
I wrote a query with OR, tested it on a test database - everything was fast.
What happened:
At the end, the handle began to slow down. The data there is distributed differently, and the request did not get into the index - it was seq scan.
How I decided:
Via EXPLAIN ANALYZE found out the problem. I split the request into two, connected it via UNION - both began to get into the indexes.
Conclusions:
Test data ≠ production data. I generate data for real scenarios and always check indexes on large volumes.
Communication / soft skills
Refactoring that I drowned in
Description:
During the task, I started refactoring the old code. There are tests, but the logic is complicated. I realized that there is no end to this.
What happened:
On calls he said that everything was ok, although the deadlines were already slipping away. Overtimed, repaired, tried to finish off. Error: refactoring not approved.
How I decided:
When a task was 1-3 days overdue, I told the team lead. He said that this was a known problem, and we were going to refactor it piece by piece.
Conclusions:
Before any refactoring, I consult with the team. Often guys know hidden nuances.
Underestimated the task and missed the deadline
Description:
In the process, I realized that the task was more difficult than it seemed. I thought it was me who didn’t understand something.
What happened:
At daily meetings he said that everything was under control, although the deadlines were already slipping. I worked in the evenings, trying to make it through.
How I decided:
Shared the problem with the team. We discussed the solution, colleagues suggested a simpler approach - and the problem was closed.
Conclusions:
If I understand that deadlines are growing, I immediately tell the manager or team. Transparency and predictability are more important than “I can handle it myself.”
Material by Sergei Solovev from the channel “sol_mentor”.
Original post about STAR ↗