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

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. Это три ступени одной лестницы: измеряемая величина, внутренняя цель по ней и обещание клиенту в договоре, за нарушение которого платят. Мидл эту тройку различает.