Каркас ответа

1. Назвать четыре части и сразу сказать, зачем метод нужен: он не даёт свалиться в пересказ контекста.
2. S - обстановка, ~20 секунд: система, момент, кто страдал. Две-три фразы, без экскурсии по архитектуре.
3. T - задача, ~20 секунд: что нужно было сделать лично мне и с какими ограничениями.
4. A - действия, ~55 секунд: шаги от первого лица, какие варианты рассматривал, по какому критерию выбрал, что делал, когда пошло не по плану. Это ядро.
5. R - результат, ~30 секунд: цифра или проверяемый факт, системное изменение, вывод одной фразой.

Чего говорить нельзя

• Проговаривать буквы вслух в самой истории. «Итак, ситуация. Теперь задача.» Так звучит отчёт по шаблону. Каркас должен быть невидимым: он у тебя в голове, а вслух идёт обычный рассказ.
• Начинать историю с результата. Соблазн есть, но тогда весь рассказ дальше слушают как оправдание уже названной цифры, и интрига «как ты к этому пришёл» пропадает.
• Одна история на все вопросы. Если на четвёртый вопрос подряд ты возвращаешься к тому же инциденту, это читается как «больше ничего не было».

Чем добить

Скажи, что истории у тебя заготовлены заранее и почему: «я держу четыре истории - спор, инцидент, фича целиком и улучшение по своей инициативе; они закрывают почти любой вопрос с разных сторон». Это выглядит как подготовка к встрече, а не как зубрёжка, и заодно подсказывает интервьюеру, о чём тебя интересно спросить.

Предмет спора: булевы флаги против раздельных методов

Классика, которая случается в любой команде. Была одна ручка обновления сделки, потом понадобилось «иногда не слать уведомление», потом «иногда пропустить валидацию для импорта». Каждый раз добавляли булев параметр, и получилось вот такое:

// Что было в сигнатуре
func (s *DealService) Update(ctx context.Context, d *Deal, notify bool, skipValidation bool) error

// Как это выглядит на месте вызова, в другом файле
if err := s.Update(ctx, deal, true, false); err != nil { ... }
// Чтобы понять, что значат true и false, придётся открыть сигнатуру.
// Два флага дают четыре комбинации, и одна из них бессмысленна:
// skipValidation=true вместе с notify=true уведомит о заведомо невалидной сделке.

Вместо этого поведение разводят по разным входам. Либо отдельные методы, либо функциональные опции, если вариантов много и они ортогональны:

// Вариант А: раздельные методы. Вызов читается сам по себе.
func (s *DealService) Update(ctx context.Context, d *Deal) error
func (s *DealService) UpdateSilently(ctx context.Context, d *Deal) error
func (s *DealService) ImportUpdate(ctx context.Context, d *Deal) error // без валидации, только для импорта

// Вариант Б: функциональные опции, когда флагов много и они правда независимы
type UpdateOption func(*updateCfg)

func WithoutNotification() UpdateOption { return func(c *updateCfg) { c.notify = false } }

func (s *DealService) Update(ctx context.Context, d *Deal, opts ...UpdateOption) error

// На месте вызова:
s.Update(ctx, deal, WithoutNotification()) // понятно, не открывая сигнатуру

Каркас ответа

1. S: ревью PR коллеги, в сигнатуру добавлялся второй булев флаг. Одна фраза.
2. T: как ревьюер я должен был либо согласиться, либо внятно объяснить, почему нет. Не «настоять на своём».
3. A: как я поднял спор с уровня вкуса до уровня критерия. Это ядро. Назвать критерии: читаемость на месте вызова, число комбинаций, которые надо тестировать, стоимость следующего флага.
4. A: что предложил конкретно и что услышал в ответ. У коллеги был контраргумент, его тоже надо назвать.
5. R: к чему пришли, что закрепили в договорённостях команды и в чём я сам оказался не прав.

Чего говорить нельзя

• «Я объяснил, и он согласился». Спор без контраргумента не спор, а лекция. Обязательно назови, что тебе возразили: так видно, что ты слышишь собеседника.
• «Позвал тимлида, он решил». Эскалация первым шагом выдаёт, что договариваться ты не умеешь. Последним шагом она нормальна, и то с формулировкой «нужен арбитр, время идёт».
• Спор про вкусовое. Табы против пробелов, длину строки, порядок импортов решают линтер и форматтер, а не спор. История про такой спор показывает одно: битву ты выбрал не ту.
• Ни одной уступки за всю историю. Если по всем пунктам прав оказался ты, это звучит неправдоподобно и высокомерно.
• Личное. «Он junior, я объяснил, как правильно» проваливает всю историю. Грейд не аргумент: в споре он не весит ничего, прав тот, у кого есть критерий и цифра, а не тот, у кого грейд выше.

Чем добить

Скажи, как ты формулируешь блокирующие замечания: вопросом, а не приказом, и с явной пометкой уровня. «Правильно ли я понимаю, что комбинация skipValidation плюс notify невалидна? Если да - может, вынесем в отдельный метод, чтобы её нельзя было выразить?» И отдельно скажи, что отсутствие флага в сигнатуре часто важнее любого код-стайла: хороший API не даёт выразить невалидное состояние. Это уже разговор про дизайн, а не про ревью.

Каркас ответа

1. S: что сломалось и кто это почувствовал. Одна-две фразы, обязательно с масштабом («часть пользователей получала 500 на списке сделок»).
2. T: моя роль: был дежурным / поднял тревогу / вёл починку.
3. A, шаг 1, митигация: остановить кровь. Что сделал, чтобы пользователям стало легче прямо сейчас, до понимания причины (откат канарейки, фича-флаг, лимит).
4. A, шаг 2, диагностика: по каким сигналам шёл. Метрики → логи → трейсы → состояние БД. Обязательно назови гипотезы, которые отбросил.
5. A, шаг 3, фикс: что именно правил и как убедился, что помогло.
6. R: время до восстановления и, главное, что изменилось в системе и процессе после: алерт, автотест, правило, статический анализ, постмортем без обвинений.

Постмортем без обвинений - как про это говорить

Формулировка, которую стоит произнести дословно: «разбирали не кто написал, а почему система позволила это выкатить». Дальше конкретика того же уровня: код-ревью пропустило, потому что диф был на четыреста строк; стейдж не воспроизвёл, потому что там другой размер пула; алерта не было вообще. Каждую из этих причин чинят инструментом, а не силой воли. Если в твоей истории виноват человек, история слабая: человек ошибётся снова.

Чего говорить нельзя

• Называть виноватого. Даже если это правда, даже если это был не ты. В «коллега написал плохой код» интервьюер услышит, как ты будешь говорить про его команду.
• «Сидел ночью и починил». Героизм выдаёт, что процессов нет. Ценится не бессонная ночь, а откат за пять минут.
• Заканчивать на фиксе. Если после «починил» в системе ничего не изменилось, инцидент повторится, и ровно это услышит интервьюер.
• «Больше не повторится, будем внимательнее». Это не вывод. Вывод выглядит как алерт, тест, линтер, изменённый чек-лист или изменённая архитектура.
• Врать про масштаб. После «лежал весь прод на четыре часа» сразу спросят про SLA, про то, как сообщали клиентам, про компенсации. Лучше настоящий масштаб.

Чем добить

Назови две метрики словами, время до обнаружения и время до восстановления, и скажи, какую из них ты сокращал. Почти все кандидаты чинят вторую (быстрее откатывать), а по-настоящему ценно сокращать первую, чтобы система сообщала о проблеме раньше, чем менеджер продаж в чате. Ещё сильный ход: сказать, что после инцидента ты сам написал постмортем, даже если ошибка была не твоя.

Каркас ответа

1. S: что за фича и зачем она бизнесу. Одна фраза, обязательно с бизнес-смыслом.
2. T: что было на входе (часто это размытая постановка) и что я должен был дать на выходе.
3. A, уточнение: какие вопросы задал до начала. Это первое, что отличает мидла.
4. A, декомпозиция: на какие куски разрезал и по какому принципу. Хороший принцип, например, «каждый кусок можно смержить и выкатить отдельно».
5. A, оценка: как оценивал и чем закрывал неопределённость: спайк, вилка вместо одного числа, буфер на непредвиденное.
6. A, что пошло не так: обязательный элемент. Без него история выглядит вылизанной.
7. R: выкатили так-то, эффект такой-то, и что поменял в своём подходе к оценке.

Про оценку: что говорить, если спросят «как вы оцениваете задачи»

• Резать до кусков в полдня-день. Всё, что оценено «дня в три», на деле оценено наугад: такой кусок режь дальше, и обычно при этом вылезает забытая работа.
• Не забывать невидимое: миграции и их откат, тесты, ревью и время на его ожидание, выкатка и наблюдение за канарейкой, документация, фича-флаг.
• Называть вилку и её причину: «шесть дней, если схема данных подойдёт как есть, восемь-девять, если придётся делать backfill истории». Вилка без причины выглядит как торг.
• Спайк на неизвестное: если в задаче есть кусок с незнакомой технологией, признаться «дайте день на разведку, после него дам оценку» сильнее, чем угадать число.

Чего говорить нельзя

• «Всё прошло по плану». Либо задача была тривиальная, либо ты не помнишь. И то и другое минус.
• «Постановка была плохая, поэтому не успели». Уточнить плохую постановку было твоей работой. Пусть виноват аналитик, но спросят с тебя, и интервьюер это знает.
• Оценка одним числом без обоснования. «Сказал две недели», а почему две?
• Тихо догонять. История, где ты обнаружил риск и молча работал по вечерам, получается про то, что менеджеру с тобой некомфортно: он узнаёт о проблемах последним.

Чем добить

Скажи про порядок нарезки: первым выкатывают самый рисковый кусок, а не самый понятный. Если непонятно, выдержит ли БД массовую операцию, это делают первым, пусть даже заглушкой: именно от этого зависит, останется ли план в силе. Кандидаты обычно нарезают по слоям (сначала БД, потом сервис, потом ручка), а нарезка по риску и по возможности выкатить каждый кусок отдельно звучит гораздо взрослее.

Каркас ответа

1. S: что раздражало и чем это измерялось (или не измерялось вообще, и тогда это первая проблема).
2. T: задачу никто не ставил, я сам решил, что это надо. Так и скажи прямо.
3. A, продажа идеи: как объяснил ценность в терминах боли команды и бизнеса, а не технологии.
4. A, минимальный пилот: сделал маленький кусок на одном сервисе, а не проект на квартал.
5. A, масштабирование: как раскатил на остальное и как сделал так, чтобы это не развалилось без тебя.
6. R: измеримый эффект и то, что этим пользуются до сих пор.

Чего говорить нельзя

• «Сделал по ночам и поставил перед фактом». Это не инициатива, а обход команды. Даже если так и было, расскажи, как ты потом это защищал и передавал.
• «Переписал legacy-модуль, потому что он был ужасный». Без измеренной проблемы улучшение выглядит вкусовщиной за деньги компании. Цифра «до» нужна всегда.
• Инициатива ради технологии. «Затащил Kafka», а какую боль это закрыло? Если ответ «стало модно/интересно», любой тимлид увидит красный флаг.
• Инициатива, которой никто не пользуется. Если «написал генератор, но команда не перешла», рассказывай про то, почему не перешли и что ты понял, а не про генератор.

Чем добить

Расскажи, во что подключение обходится остальным: сколько строк надо написать коллеге и сколько нового ему надо выучить. Инициативы умирают не потому, что они плохие, а потому что их дорого принять. По фразе «я специально сделал так, чтобы подключение стоило три строки и не требовало ничего знать про Prometheus» сразу видно человека, который уже внедрял что-то в живой команде, а не только предлагал.