Что действительно хочет услышать нанимающий в ответ на вопрос «Расскажи историю, где ты прям ошибся?»
Зачем спрашивают про ошибки
Знаешь, почему на собесах всегда спрашивают этот вопрос? На самом деле, почти никому не интересен сам провал, всем хочется услышать, как ты думаешь, как выбираешься из задницы, как принимаешь решения.
И для этого есть простая, но охрененно рабочая схема — STAR (да, да, ты уже слышал 100%).
Что такое STAR
Это способ структурировать свою историю так, чтобы она звучала не как:
Ну там короче прод лёг, ы у а…
А как нормальный кейс, после которого тебе верят, что ты умеешь работать.
- S — Situation — контекст, что вообще происходило.
- T — Task — что именно было твоей задачей.
- A — Action — какие шаги ты сделал (в деталях).
- R — Result — какой итог и какие выводы.
Всё. Вся магия в том, что ты не прыгаешь между фактами, не забываешь важное и не утопаешь в «ну это длинная история…».
Почему STAR работает
- Ты показываешь контекст (иначе твой факап может выглядеть или мелким, или суперстрашным).
- Ты подчёркиваешь личную ответственность, а не «мы сделали».
- Ты выделяешь конкретные шаги, где виден твой профессионализм.
- И самое главное — выводы, которые доказывают, что ты не повторяешь одни и те же ошибки.
Как строить ответ
Как не надо делать:
Ну я ошибся, мы потом починили. Я сделал выводы.
Бесполезно. Неинформативно.
А как правильно? Чётко по структуре:
Контекст → твоя роль → твои действия → результат → выводы.
5–7 предложений, но звучит как история реального инженера, а не как отписка.
Почему это важно для разработчиков
Потому что многие из нас:
- Либо оправдываются техническими деталями («ну там PG не так план посчитал»).
- Либо уходят в самобичевание («да я просто дурак»).
- Либо втирают про «мы» вместо «я».
STAR помогает говорить профессионально:
Да, я сломал. Вот как. Вот почему. Вот как я это починил. Вот что изменилось в моём процессе.
Подготовь свои истории
Научись рассказывать про свои ошибки грамотно. Это про зрелость разработчика, твою компетентность.
Факапить — это нормально.
Но если ты умеешь рассказать свой факап по STAR, значит, ты понимаешь, что делаешь, почему делаешь и как развиваешься.
Заготовь сразу несколько версий факапов в разных направлениях:
- Технический косяк.
- Косяк в коммуникации.
Ниже — классические примеры факапов в стиле STAR, чтобы ты мог сформулировать свои в схожем стиле. Используй их как опору для своей реальной истории.
От схемы к истории
7 примеров факапов
Пять технических ситуаций и две истории про коммуникацию. В каждом примере — что произошло, как решили и какие выводы сделали.
Технический косяк
Рефакторинг, который сломал редкий кейс
Описание:
Начал рефакторить старую логику во время выполнения задачи. Покрытие тестами — слабое. Задел редкий кейс, юниты прошли, регресс не заметил.
Что случилось:
Через 1–48 часов всплыл баг в отдельных ситуациях. Сначала не понимали, что происходит. Вспомнил, что трогал код именно этого функционала.
Как решил:
Сразу сказал команде, что мог зацепить логику. Откатили фичу, точечно починили данные в базе.
Выводы:
Перед рефакторингом разбираюсь в коде, проверяю покрытие, дописываю тесты и документацию. Все редкие варианты поведения прогоняем на тестовом стенде — и только потом деплой.
Юниты, которые работали по живой тестовой базе
Описание:
Пришёл на проект, не разобрался в docker-compose и запустил юниты. Оказалось, образ смотрел на общую тестовую БД.
Что случилось:
Тестер заметил странные данные на стенде. Разобрались — это сгенерировали мои тесты.
Как решил:
Исправил .env так, чтобы по умолчанию всё шло в локальную docker-БД. Лишние данные вместе с тестером почистили.
Выводы:
Перед запуском любых тестов/скриптов дважды проверяю окружение и конфиги.
Скрипт очистки, который снёс демо-данные
Описание:
Был скрипт для локальной очистки данных. По ошибке запустил его на общем демо/тест стенде.
Что случилось:
Снёс все демо-данные перед важным показом. Команда была «рада».
Как решил:
Наполнили стенд данными заново — тестами и ручками.
Выводы:
Перед запуском чего-либо разрушительного обязательно проверяю окружение. Дважды.
Деплой в пятницу (классика)
Описание:
Большая задача была закрыта к пятнице. С тестировщиком проверили на тестовом стенде — предложил зарелизить.
Что случилось:
На проде в 5% кейсов функционал ломался. Хотели откатить — нельзя: уже появились новые данные.
Как решил:
Вечером в пятницу вместе с коллегой правили данные вручную, пока не вернули систему в порядок.
Выводы:
Пятничный деплой — только для маленьких изменений. Всегда заранее продумываю план отката и условия, при которых он возможен.
Неоптимальный запрос, который тормозил прод
Описание:
Написал запрос с OR, протестил на тестовой БД — всё быстро.
Что случилось:
На проде ручка стала тормозить. Данные там распределены иначе, и запрос не попадал в индекс — был seq scan.
Как решил:
Через EXPLAIN ANALYZE выяснил проблему. Разбил запрос на два, связал через UNION — оба стали попадать в индексы.
Выводы:
Тестовые данные ≠ продовые. Генерирую данные под реальные сценарии и всегда проверяю индексы на больших объёмах.
Коммуникация / софты
Рефакторинг, в котором я утонул
Описание:
Во время задачи начал рефакторить старый код. Тесты есть, но логика сложная. Понял, что конца этому нет.
Что случилось:
На созвонах говорил, что всё ок, хотя сроки уже уплывали. Овертаймил, чинил, пытался добить. Ошибка — не согласовал рефакторинг.
Как решил:
Когда просрочил задачу на 1–3 дня, рассказал тимлиду. Он сказал, что это известная проблема, и рефакторить её мы собирались по кускам.
Выводы:
Перед любым рефакторингом консультируюсь с командой. Часто ребята знают скрытые нюансы.
Недооценил задачу и провалил сроки
Описание:
В процессе понял, что задача сложнее, чем казалось. Думал, что это я что-то не понимаю.
Что случилось:
На дейликах говорил, что всё под контролем, хотя сроки уже плавали. Работал по вечерам, пытаясь дожать.
Как решил:
Поделился проблемой с командой. Обсудили решение, коллеги подсказали более простой подход — и задача была закрыта.
Выводы:
Если понимаю, что сроки растут — сразу говорю менеджеру или команде. Прозрачность и предсказуемость важнее, чем «я сам справлюсь».
Материал Сергея Соловьёва из канала «sol_mentor».
Исходный пост о STAR ↗