Поведенческая секция и рассказ об опыте

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

1. Кто я сейчас (~30 с): имя, роль, сколько лет пишу на Go, что за продукт и для кого. Стек в одну строку, без перечисления всего, что видел.
2. Проект и достижения (~60 с): что за система, за что отвечал я, два-три результата с цифрами в формате «было X — стало Y».
3. Чего хочу дальше (~30 с): чего не хватает сейчас и почему именно эта вакансия это закрывает. Заодно здесь же снимается будущий вопрос «почему уходишь».
4. Передача хода: «с чего вам удобнее начать — с архитектуры или с конкретных задач?» Это выглядит уверенно и экономит время обоим.

Образец под профиль «Go + CRM»

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

• Хронологию с института. После «закончил вуз, потом полгода на PHP, потом...» самое ценное окажется в конце.
• Список технологий без контекста. За «знаю Kafka, gRPC, Redis, k8s, Postgres» сразу следует «а что вы с Kafka делали?», и если ответа нет, доверие падает ко всему списку.
• Личное. Семья, город, хобби, «люблю учиться новому». Либо спросят отдельно, либо это шум.
• Негатив про текущую работу. Даже одна фраза «там всё плохо с процессами» разворачивает разговор не туда.
• Восемь минут. Если тебя перебивают, рассказ был слишком длинным, и это уже минус.

Чем добить

Подстроить последний блок под конкретную вакансию: если в описании выделены высокие нагрузки, делай акцент на латентности и метриках; если интеграции, на идемпотентности и внешних API; если много легаси, на миграциях без даунтайма. Один и тот же рассказ с разными акцентами выглядит как «человек прочитал вакансию», а это редкость.

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

1. Что делает система и для кого. Две фразы. Без этого всё дальнейшее висит в воздухе.
2. Как устроена. Сколько сервисов, кто с кем как общается (синхронно / через события), где живёт состояние, как деплоится.
3. Где здесь я. Прямым текстом: «я отвечал за такие-то сервисы и такие-то задачи». Если что-то делал не ты, так и скажи, это не минус.
4. Как это работает в динамике. Проведи один запрос через всю систему: от кнопки в интерфейсе до записи в БД и события в Kafka. Так проще всего показать, что ты понимаешь систему целиком.
5. Масштаб цифрами. RPS, объём данных, размер команды, темп релизов.

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

• Начинать со стека. «У нас Go, Postgres, Kafka» перечисляет зависимости, а не рассказывает о проекте.
• Сплошное «мы». Если во всём ответе ни разу не прозвучало «я сделал», интервьюер не поймёт, что делал именно ты, и решит, что ничего.
• Присваивать чужое. Достаточно одного уточняющего вопроса вглубь, чтобы это вскрылось. Гораздо сильнее звучит «это делал коллега, я знаю верхнеуровнево».
• Раскрывать то, что нельзя. Внутренние формулы, персональные данные, коммерческие цифры компании. Говори про архитектуру и порядки величин, а не про конкретику под NDA, и скажи об этом прямо: это плюс, а не минус.

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

1. Проблема в одной фразе, и почему она не решалась «просто».
2. Варианты: два-три, каждый с плюсом и минусом. Это ядро ответа.
3. Выбор и критерий: почему именно этот, по какому признаку сравнивал.
4. Как проверил, что не ошибся: метрики, нагрузочный тест, канареечная раскатка.
5. Что бы сделал иначе сейчас. Эта фраза почти всегда добавляет к оценке.

Про «чем гордишься»

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

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

• «Самым сложным было переписать монолит на микросервисы». Если ты был одним из десяти, это про масштаб чужой работы.
• Решение без альтернатив. «Взял Kafka», а почему не RabbitMQ, не outbox с поллингом, не обычная транзакция? Если альтернатив нет, значит, выбора не было и решение принимал не ты.
• Гордиться количеством кода: «написал сервис на 20 тысяч строк». Никто не считает строки.

Обязательный минимум

• Нагрузка: RPS средний и в пике, во сколько раз пик выше среднего.
• Латентность: p50/p95/p99 двух-трёх главных ручек. Только не среднее, оно на собесе выдаёт человека, который метрики не читал.
• Данные: размер БД, число строк в самых крупных таблицах, суточный прирост, глубина хранения.
• Команда: сколько разработчиков, есть ли QA, аналитик, тимлид; сколько человек в твоей зоне.
• Темп: релизов в неделю, время от смерженного PR до прода, есть ли автотесты в пайплайне.
• Надёжность: целевая доступность, есть ли SLO, сколько инцидентов было за квартал, есть ли дежурства.

Где брать, если не помнишь

# Prometheus: RPS сейчас, окно пять минут, и пик за сутки
sum(rate(http_requests_total[5m]))
max_over_time(sum(rate(http_requests_total[5m]))[24h:5m])

# p99 по ручке
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket{route="/deals"}[5m])))

# доля успешных за месяц: фактический SLI доступности
sum(rate(http_requests_total{code!~"5.."}[30d])) / sum(rate(http_requests_total[30d]))

-- размер базы и топ таблиц по объёму
SELECT pg_size_pretty(pg_database_size(current_database()));

SELECT relname,
       pg_size_pretty(pg_total_relation_size(c.oid)) AS total,
       reltuples::bigint                             AS approx_rows
FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE n.nspname = 'public' AND c.relkind = 'r'
ORDER BY pg_total_relation_size(c.oid) DESC
LIMIT 5;

Как называть цифру, если точной нет

В этом ответе три приёма: назван порядок, объяснена форма нагрузки (привязка к рабочему дню показывает, что ты понимаешь систему, а не запомнил цифру) и предложено уточнить позже. Последним почти никогда не пользуются, но напряжение оно снимает.

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

• «Высоконагруженный проект» без числа. Это слово ничего не значит: для кого-то это 500 RPS, для кого-то 500 000.
• Среднее время ответа вместо перцентилей. Сразу прилетит «а p99?», и если ответа нет, вопрос про метрики закрыт не в твою пользу.
• Округление вверх «для солидности». Один вопрос «а на скольких подах это крутилось?», и арифметика не сойдётся.
• Путать SLA, SLO и SLI. Это три ступени одной лестницы. SLI (service level indicator) обозначает саму измеряемую величину, например долю запросов, отработавших без ошибки. SLO (objective, «цель») задаёт внутреннюю цель по этой величине, «не ниже 99,9% за месяц»: за её нарушение никто не платит, но команда обязана реагировать. SLA (agreement, «соглашение») фиксирует то же обещание в договоре с клиентом, и за нарушение уже платят деньгами или скидкой. Мидл эту тройку различает.

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

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, я объяснил, как правильно» проваливает всю историю. Грейд не аргумент. Грейд здесь значит ступеньку на внутренней лестнице компании: джун, мидл, сеньор и их подступени вроде «мидл+». В споре он не весит ничего: прав тот, у кого есть критерий и цифра, а не тот, кто выше по лестнице. Подробнее про грейды в главе 2.5, там от них зависят деньги.

Чем добить

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

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

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

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

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

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

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

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

1. Назвать ошибку прямо, в первой фразе. Без разгона и без смягчений: «я выкатил миграцию, которая сломала работу списка сделок на несколько минут».
2. Признать свой вклад точно. Что именно сделал не так и почему тогда это казалось нормальным.
3. Как чинил. Коротко: что выбрал, откат или движение вперёд, и почему.
4. Что изменилось после. Это ядро: правило, автоматическая проверка, изменённый порядок работы. Желательно два-три конкретных пункта.
5. Вывод одной фразой: обобщение уровня «класс ошибок», а не «этот случай».

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

• «Провалов не было». Мгновенный минус: либо не было прода, либо нет рефлексии.
• «Ревью пропустило». Правда, но не твоя часть правды. Ревью годится как системная причина («диф был большой, миграцию не разглядели, поэтому мы завели отдельный чек-лист»), но не как виноватый.
• Псевдопровал. «Я слишком перфекционист», «задержал релиз ради качества».
• Провал, который никак не закончился. Если после истории ничего не изменилось, лучше взять другую историю.
• Эмоции вместо фактов. «Было очень стыдно, я неделю переживал»: одной фразы хватит, дальше нужны действия.

Чем добить

Обобщи ошибку до класса. Не «я больше не переименовываю колонки», а «я перестал считать деплой атомарным событием — и это касается схемы БД, схем событий и контрактов API». По такому обобщению видно, что выводы человек делает по причине, а не по частному случаю. Второй сильный ход: сказать, что ты сам написал постмортем и сам вынес это на общий разбор, а не ждал, пока разберут за тебя.

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

1. Предмет несогласия одной фразой: техническое, не личное.
2. Позиции сторон и их резоны. Обязательно назови сильную сторону чужого варианта: это доказывает, что ты его понял.
3. Как перевёл в измеримое: критерий, замер, эксперимент. Ядро ответа.
4. Чем кончилось и что взял из чужой позиции.
5. Отдельно про случай, когда решение приняли не твоё, и как ты себя повёл.

Как выглядит хороший исход спора

• Есть решение, а не перемирие. Исход «каждый остался при своём» плохой: вопрос всплывёт снова.
• Есть критерий, по которому выбрали, и он записан: в комментарии к PR, в задаче или в ADR. ADR (architecture decision record, «запись об архитектурном решении») занимает полстраницы: что решали, какие были варианты, что выбрали и почему. Через полгода это единственное, что отвечает на вопрос «а почему у нас так сделано».
• Есть условие пересмотра. Фраза «вернёмся, если p99 выйдет за 500 мс» превращает решение из вечного в обратимое.
• Отношения не пострадали. Признак: с этим человеком ты дальше нормально работаешь и рассказываешь про него спокойно.

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

• Личный конфликт. «Не сошлись характерами», «он токсичный». Даже если так, на собесе это читается как «он приносит конфликты с собой».
• «Я оказался прав». Как единственный итог не годится. Если ты правда был прав, скажи это через данные: «замер показал, что вариант с индексом дешевле».
• «Позвал тимлида, он решил». Как первый шаг это сигнал, что договариваться не умеешь.
• «Я просто уступил, чтобы не спорить». Это не гибкость, а отсутствие позиции.
• Спор длиной в месяц. Затянутый спор тоже плохой исход, даже если ты победил.

Чем добить

Назови вопрос, которым ты пользуешься в тупике: «что должно произойти, чтобы ты изменил мнение?». Он делает две вещи сразу: вытаскивает настоящий критерий собеседника и нередко показывает, что критерия нет вообще. И добавь про формат: длинные споры ты выносишь из чата в пятнадцатиминутный созвон, а решение возвращаешь в письменном виде, чтобы через месяц никто не спорил заново.

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

1. Пересчитываю честно и получаю новую дату: число, а не ощущение.
2. Сообщаю в тот же день, письменно, адресно: риск, причина, новая оценка.
3. Приношу три варианта с ценой каждого и говорю, какой рекомендую.
4. Договариваюсь о точке контроля, чтобы решение можно было принять не в последний день.
5. Дальше работаю по выбранному варианту и держу статус видимым.

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

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

Чем добить

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

Шесть флагов, которые закрывают вакансию

1. Виноватые. В истории появляются должности: аналитик, тестировщик, менеджер. Интервьюер мгновенно достраивает, как ты будешь рассказывать про его команду.
2. «Мы» в неприятных местах и «я» в приятных. Достижения «я сделал», ошибки «мы не учли». Заметно уже на второй истории.
3. Нет системного вывода. «Буду внимательнее», «стал аккуратнее» значат то же, что «ничего не изменилось».
4. Героизм. Ночи, выходные, «спас релиз». Читается так: процессов нет, а человек вот-вот выгорит.
5. Жалобы без действий. «Легаси, документации нет, процессы кривые»: если за описанием проблемы не следует ни одной твоей попытки что-то изменить, это позиция пассажира.
6. Спор ради победы. «В итоге я оказался прав» без единого пункта, где прав был оппонент. Такой человек дорого обходится команде, даже когда технически силён.

Два флага помельче, но заметных

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

Чем добить

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

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

1. Сказать вслух, что это пока не требование. «Быстро» нельзя ни сделать, ни принять, значит, первым делом я перевожу его в проверяемую формулировку.
2. Вопросы про число: что значит «быстро» и в каких единицах, для какой доли запросов (среднее / p95 / p99), при какой нагрузке, на каком объёме данных, на каких конкретно сценариях.
3. Вопрос «зачем»: кто именно жалуется, что он в этот момент делает, что бизнес из-за этого теряет. Часто оказывается, что скорость только симптом, а болит другое.
4. Вопрос про цену: срок и бюджет, а главное, чем можно платить (свежесть данных, консистентность, деньги на железо, часть функциональности).
5. Вопрос про приёмку: какая метрика, на каком дашборде, кто скажет «принято».
6. Закончить сформулированным SLO: показать, как из фразы получается строчка, которую можно проверить.

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

• Сразу предлагать решения. «Поставим Redis, добавим индексы, поднимем реплику». Классический провал: кандидат оптимизирует то, чего не измерил, и, скорее всего, не то.
• «Сделаем максимально быстро». Это обещание без цены и без критерия приёмки.
• Спрашивать только про latency. Без вопросов «зачем» и «чем можно платить» ответ выглядит как чек-лист, а не как понимание.
• Задавать вопросы бесконечно. Если на этом всё и закончилось, кандидат выглядит как человек, который умеет уточнять, но не умеет доводить. Обязательно закончить сформулированным требованием.
• Обещать «всегда быстро». Требование «всегда меньше 100 мс» без перцентиля практически недостижимо: всегда найдётся GC-пауза, ретрай или холодный кэш.

Чем добить

Скажи, что после согласования SLO ты первым делом измеряешь, а не оптимизируешь: вешаешь гистограмму по этой ручке в Prometheus и панель в Grafana. Дальше два аргумента, которые звучат по-взрослому. «Бесплатной скорости не бывает»: за неё всегда платят свежестью данных, деньгами на железо или сложностью поддержки, и весь разговор нужен, чтобы выяснить, чем именно заказчик готов заплатить. И второй, «у скорости есть точка, после которой пользователь не замечает разницы»: если 210 мс и 40 мс для человека неотличимы, второй вариант не стоит своей инвалидации кэша. Так ты показываешь, что оптимизируешь бизнес-эффект, а не число на графике.

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

1. Назвать принцип, а не список. «Иду сверху вниз по цене ошибки».
2. Что делаю до комментариев: читаю задачу, смотрю размер PR, прохожу диф целиком один раз молча.
3. Верхние уровни подробно: та ли задача решена → что будет в проде → данные и запросы → совместимость и откат → безопасность.
4. Нижние уровни коротко: наблюдаемость, тесты, читаемость; стиль отдаю линтеру.
5. Как коммуницирую. Половина ответа: ревью про людей, а не про текст.
6. Один живой пример находки, он делает весь ответ достоверным.

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

• Начинать с именования и форматирования. Мгновенно читается как «ревьюил только учебные проекты».
• «Проверяю чистоту кода и SOLID». Лозунг вместо процедуры. Если говоришь про принципы, называй, какое конкретно нарушение и чем оно навредит.
• «Я всегда всё проверяю досконально». На PR в тысячу строк это неправда, и интервьюер это знает. Взрослый ответ звучит иначе: «я говорю, что не могу качественно отревьюить такой объём».
• Ни слова про коммуникацию. В ревью всегда двое; кандидат, который описал только техническую часть, выглядит как источник конфликтов.
• «Отклоняю PR, если не нравится подход». Без критериев это вкусовщина с правом вето. Нравится/не нравится тянет максимум на nit, а блокирует только то, что сломает прод или контракт.
• Ревью как способ показать, что ты умнее. Тон «а вот здесь ты не знаешь, как работает планировщик» для любого тимлида красный флаг.

Чем добить

Скажи, что часть замечаний нужно убирать из ревью в автоматику: если одно и то же повторяется третий раз, это не тема для комментария, а тема для линтера, шаблона PR или чек-листа. У нас так появилась проверка на опасные миграции в CI (DROP COLUMN, RENAME, CREATE INDEX без CONCURRENTLY), и эти замечания просто перестали существовать как ручная работа. Второй сильный ход: сказать, что ревью для тебя ещё и способ распространять знание о системе. Читая чужие PR, ты держишь в голове, что происходит в соседних частях CRM, и это окупается на инцидентах.

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

1. Метрика успеха: по чему поймём, что решили задачу.
2. Два-три реальных варианта, обязательно с самым дешёвым и с «ничего не делать».
3. Критерии выбора, среди них обязательно обратимость: односторонняя дверь или двусторонняя.
4. Данные вместо мнений: замер, прототип на день, EXPLAIN.
5. Запись решения: ADR или абзац в задаче, что выбрали, что отвергли и почему.
6. Условие пересмотра.
7. Перевод для бизнеса: те же варианты на языке денег, сроков и риска.

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

• «Я выбираю лучшее решение». Лучшего не бывает, бывает подходящее под ограничения. Ответ без слова «trade-off» звучит незрело.
• «Смотрю, как принято в индустрии» / «так делают в больших компаниях». Аргумент по авторитету вместо аргумента по контексту.
• Технические термины бизнесу. «Нам нужен шардинг, потому что вертикальное масштабирование упёрлось» гарантированно кончается репликой «делай как знаешь, только не мешай», а потом «почему это заняло два месяца».
• Слово «нет» без вариантов. Отказ без цены выглядит как нежелание работать.
• Решать всё в одиночку. Через односторонние двери идут вместе с командой, иначе это не зрелость, а самоуверенность.
• Пугать бизнес. «Всё упадёт, если не переписать» без цифр звучит как шантаж, и его быстро перестают воспринимать всерьёз.

Чем добить

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

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

1. Одна фраза благодарности прошлому месту: что оно тебе дало. Снимает подозрение в конфликте до того, как оно возникло.
2. Конкретная причина. Не эмоция, а факт: закончился рост, закрылось направление, упёрлись в потолок грейда, изменились приоритеты команды.
3. Что ты пробовал сделать внутри, если пробовал. Показывает, что ты не копишь недовольство молча.
4. Чего ты ищешь, сформулированное как требование к следующему месту.
5. Почему именно сюда. Замыкает ответ на эту вакансию и превращает уход в осознанный переход.

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

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

Чем добить

Скажи, что ты никуда не бежишь: «мне не срочно, я не в состоянии "лишь бы уйти" — поэтому и выбираю аккуратно». Кандидат, который не горит, воспринимается сильнее, чем кандидат в панике. Второй ход: упомянуть, что уходишь правильно, то есть доделываешь начатое, передаёшь дела, написал документацию по сервису. Лучшего сигнала о том, как ты когда-нибудь будешь уходить и отсюда, не бывает, а интервьюер думает об этом чаще, чем признаётся.

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

1. Показать, что ты знаешь рынок: отсюда и берётся уверенность.
2. Мягко вернуть вопрос: «какая вилка заложена по позиции?»
3. Если настаивают, назвать интервал: цель → амбиция. Минимум не произносится никогда.
4. Уточнить гросс или на руки, иначе разница в 15–16% на ровном месте.
5. Одна строка обоснования и пауза. Не оправдываться.
6. Про текущую зарплату либо вежливо уйти от ответа, либо назвать честно и сразу перевести разговор на рынок.
7. Оставить дверь открытой: готов обсуждать пакет целиком.

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

• «Сколько предложите» / «зарплата для меня не главное». Это приглашение предложить минимум по вилке. И звучит неправдой: деньги важны всем.
• Одно число вместо вилки. Одна цифра становится потолком, от которого будут торговаться вниз. Интервал оставляет пространство и выглядит как знание рынка.
• Оправдываться после названной суммы. «…но это обсуждаемо, я в целом гибкий, можно и меньше», и ты только что сам уронил свою цифру на сто тысяч.
• Аргументировать личными расходами. Ипотека, аренда, дети аргументом не считаются: платят за работу, а не за твои обязательства.
• Завышать текущую зарплату. Иногда просят подтверждение дохода, и это единственная ошибка, после которой оффер отзывают целиком.
• Называть цифру, не уточнив гросс или на руки. Разница в 15–16% выяснится в самый неподходящий момент.
• Соглашаться на «ниже, зато потом пересмотрим» без записанных критериев и даты. Устного пересмотра не существует.

Чем добить

Добавь одну фразу, которая переводит разговор из торга в деловой: «Готов обсуждать пакет в целом, а не только оклад». Она показывает, что ты взрослый переговорщик, и открывает компании путь дать тебе то, что у неё есть, когда вилка грейда упёрлась: срок пересмотра, грейд, дежурные выплаты, отпуск, технику. И держи в голове: обсуждать деньги выгоднее после оффера, чем до него. На скрининге ты одна строчка в списке, а после финала человек, на которого потратили несколько часов и которого ещё месяц искать заново.

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

1. Благодарность и выраженный интерес, и только потом просьбы.
2. Просьба о времени с конкретным днём: «отвечу в среду до конца дня».
3. Список того, что ты хочешь уточнить, коротко и по пунктам, чтобы собеседник видел, что это не затягивание.
4. Один раунд встречного предложения: число + обоснование + готовность закрыть сделку.
5. Если оклад упёрся, переключаешься на остальной пакет.
6. Фиксация в письме.
7. Реакция на давление: спокойная, с готовностью принять «нет».

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

• «Да» прямо в звонке. Согласие голосом связывает: торговаться потом уже неудобно, а деталей пакета ты ещё не видел.
• Торговаться по кругу. «А можно ещё чуть-чуть?» на третьем заходе запоминают надолго и пересказывают коллегам.
• Просить и не быть готовым согласиться. Назвал 700, тебе дали 700, значит, выходишь. Иначе ты не переговорщик, а человек, который тянет время.
• Блефовать чужим оффером. Иногда отвечают «тогда удачи», и отыграть назад нельзя. Настоящий оффер упоминать можно и нужно.
• Верить устным обещаниям. «Через полгода точно пересмотрим» без строчки в оффере остаётся разговором, а не обещанием.
• Исчезать молча. Если ждёшь другую компанию, скажи об этом прямо и назови дату. Неделя молчания рушит доверие ещё до выхода.
• Устраивать скандал из-за дедлайна. «Это манипуляция, я так не работаю»: по сути ты прав, по форме проиграл.

Чем добить

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

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

1. Показать, что вопросы подготовлены, а не придуманы на месте.
2. Три–пять вопросов из разных блоков, выбранных под роль собеседника.
3. Реагировать на ответы, а не читать список: уточняющий вопрос ценнее следующего пункта.
4. Одна фраза интереса с конкретной зацепкой из разговора.
5. Закрыть сомнение, если оно повисло по ходу интервью.
6. Спросить про следующий шаг и сроки обратной связи.

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

• «Нет, вы всё рассказали». Самый дорогой ответ в этом блоке: читается как «мне всё равно, куда идти». Даже если правда всё рассказали, спроси про успех через полгода или про следующий шаг.
• «А чем занимается компания?» Не открыл даже сайт.
• Отпуск, ДМС, обеды и переработки у технического интервьюера. Это к рекрутеру и к моменту оффера.
• «Когда меня повысят?» До того, как взяли.
• «Как я справился, какие у меня шансы?» Ставит собеседника в неловкое положение: решение принимает не он и не сейчас.
• Вопросы-экзамены. Попытка показать, что ты разбираешься лучше, проигрывает при любом исходе.
• Читать список, не слушая ответы. И тем более задавать то, о чём уже подробно говорили полчаса назад.
• Пятнадцать вопросов подряд. Финал не допрос: три–пять точных выглядят гораздо сильнее.

Чем добить

Лучший вопрос всего списка: «что было последним крупным инцидентом и что после него изменили». Рекламой на него не ответить: тебе либо расскажут про постмортем, выводы и изменённый процесс (и это отличная компания), либо начнут искать в рассказе виноватых, либо скажут «инцидентов у нас не бывает», а это значит, что мониторинга нет. Любой из трёх ответов тебе полезен. И маленькая деталь, которая работает всегда: задай уточняющий вопрос к ответу. Это превращает твой список в разговор и показывает, что ты действительно слушал. Именно это остаётся в фидбэке формулировкой «с ним было интересно разговаривать».