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

Начинается: «Ну... я рефакторил легаси‑модуль...», «оптимизировал запросы в базу...», «переводил сервис на новый фреймворк...».

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

И вот тут пролегает пропасть. Многие блестящие технари не могут получить заслуженное повышение просто потому, что не способны внятно артикулировать это влияние. Они думают, что их код говорит сам за себя. Не говорит.

Эта статья — про то, как перестать саботировать самого себя и научиться рассказывать о своей работе так, чтобы ее оценили по достоинству.

Алгоритм подготовки

Нельзя просто прийти на встречу и начать импровизировать. Импровизация — это хорошо подготовленный сценарий. Рассказ о проекте — это такой же инженерный продукт, как и сам проект. У него есть требования, архитектура и деплой.

Выбор проекта

Первая ошибка пытаться рассказать про всё. Не надо. У вас будет 30–40 минут в лучшем случае. Выберите один, максимум два, самых показательных проекта за отчетный период.

Какой проект считать «показательным»? Не обязательно тот, где вы написали 10 000 строк кода. Выбирайте по одному из критериев:

1. Проект с максимальным бизнес‑импактом.

2. Проект с максимальной технической сложностью.

3. Проект, где вы проявили лидерство.

Идеально, если все три пункта сошлись в одном. Но чаще всего приходится выбирать. Для перехода на грейд выше импакт и лидерство важнее, чем сложность.

Сбор фактуры

Это самый важный и самый нудный этап. Вам нужны цифры.

• Технические метрики:

  • Latency (p99, p95, p50). Было/стало.

  • RPS (requests per second), которые держит сервис.

  • Error Rate (количество 500-х ошибок).

  • Потребление ресурсов (CPU, Memory, IOPS).

  • Время CI/CD пайплайна.

• Бизнес‑метрики / Продуктовые метрики:

  • Конверсия.

  • Отвал пользователей.

  • Деньги.

  • Время выхода на рынок.

Пример плохого сбора фактуры: «Я оптимизировал эндпоинт».

Пример хорошего сбора фактуры: «Я заметил, что эндпоинт /api/v1/cart деградировал и его p99 latency вырос до 3500ms. Это приводило к 15% отвалов на шаге добавления в корзину. Я собрал метрики, нашел N+1 проблему в ORM, переписал логику с джоинов на батчинг. В результате p99 упал до 150ms. Отвалы в этой воронке снизились до 2%. По расчетам продукта, это сохранило компании N тысяч долларов в месяц».

Второй рассказ продает вас как инженера, который думает о бизнесе, а не просто о коде. Собирайте эту фактуру по ходу проекта.

Прогнать рассказать

Никогда не пропускайте этот шаг. Вы должны прогнать свой рассказ вслух. Не про себя в голове, а голосом.

• На ком тренироваться? Идеально на коллеге из другой команды или на своем тимлиде. Вам нужен человек, который не погружен в ваш контекст на 100% и сможет задавать «глупые» вопросы.

• Что тренировать? Тайминг. Уложитесь в отведенное время. Если вас прерывают вопросами (а вас будут прерывать), вы должны уметь быстро вернуться на рельсы своей истории.

Шаблон истории

Логичный и понятный шаблон, который покрывает все, что от вас хотят услышать.

Контекст

• Что болело? Начните не с «мне дали задачу», а с «у бизнеса/пользователей/команды была проблема».

• Пример: «Наш монолитный сервис биллинга не справлялся с ростом нагрузки в 'черную пятницу'. В прошлом году мы лежали 3 часа, потери составили N миллионов. Поддержка была завалена тикетами. Масштабировать его было невозможно из‑за...»

Цель

• Какого идеального результата мы хотели достичь? Цель должна быть измеримой.

• Пример: «Цель была не просто починить. Цель была в, том, чтобы разработать новую архитектуру, которая: 1) выдержит 5-кратный рост нагрузки (с 10k RPS до 50k RPS); 2) будет горизонтально масштабируемой; 3) снизит стоимость одной транзакции на 20% за счет более дешевой инфраструктуры».

Ограничения

• С чем пришлось работать? Это ваш шанс показать, что вы не в вакууме.

• Пример: «У нас было всего 3 месяца до следующей черной пятницы. Команда состояла из трех человек, включая меня. Мы не могли остановить старый биллинг, поэтому миграция должна была быть бесшовной. Плюс, легаси‑базу трогать было нельзя, только читать».

Архитектура

• Как вы это решили? Здесь интересно, но не увлекайтесь. Не надо показывать код (если не просят). Нужны схемы.

• Достаньте простую, понятную диаграмму.

• Getty Images

• Открыть

• Пример: «Мы применили паттерн Strangler Fig (Душитель). Старый монолит остался, но мы обернули его в прокси. Все новые запросы на X шли в новый сервис, написанный на Go. Старые запросы на Y в монолит. Для миграции данных мы использовали shadow writing, писали и в старую, и в новую базу, а для backfill использовали кастомный скрипт, который бежал по ночам, чтобы не нагружать прод».

Сложность

• Что было реально трудно? Выделите 1–2 самые сложные технические или организационные проблемы.

• Пример: «Самым сложным было обеспечить консистентность данных при 'shadow writing'. Были гонки. Если юзер менял данные, один запрос мог пойти в новую систему, другой‑ в старую. Мы решили это, внедрив версионировани' записей на стороне прокси и используя n стратегию.».

Решения

• Что конкретно вы сделали? Переходим от «мы» к «я», но аккуратно.

• Пример: «Я лично отвечал за дизайн и имплементацию прокси. Я провел исследование и сравнил 3 подхода к миграции. Я настоял на n стратегии и защитил ее перед архитектором. Я написал и провел нагрузочное тестирование нового сервиса, которое выявило боттлнек в...»

Результат

• И что в итоге? Возвращаемся к Цели и Фактуре. Это замыкание цикла.

• Пример: «В черную пятницу система отработала штатно. Мы держали пик в 60k RPS. Ни одного факапа. Latency p99 не превышал 200ms. Стоимость транзакции упала на 25%. Бизнес смог провести три промо‑акции вместо одной, что принесло...»

Импакт и лидерство

А теперь самое главное. Все, что было выше — это хороший рассказ сеньора. Чтобы прыгнуть выше, вам нужно сместить фокус с «я писал код» на «я принес пользу» и «я вел за собой».

Как подсветить импакт?

Связывайте свои технические действия с бизнес‑результатом. Задавайте себе вопрос: «И что?».

• Плохо: «Я перевел сервис на Kubernetes».

• Хорошо: «Я перевел сервис на Kubernetes (техническое действие). Это позволило нам использовать auto‑scaling, что сократило наши расходы на железо в непиковые часы на 40% (бизнес‑результат) и ускорило выкатку фич с 1 раза в неделю до 3 раз в день».

• Плохо: «Я отрефакторил старый модуль».

• Хорошо: «Я отрефакторил старый модуль, который никто не трогал 3 года. Я покрыл его тестами на 80%. Это снизило количество багов в этом модуле на 90% и сократило время онбординга новых разработчиков для работы с ним с месяца до недели».

Как подсветить лидерство?

Лидерство — это про ответственность, выходящую за рамки вашего тикета в Jira.

• Вы менторили? «Я взял под крыло нового джуна, провел с ним 10+ сессий код‑ревью, помог ему разобраться в домене. В итоге через 3 месяца он самостоятельно закрыл сложную фичу X».

• Вы решали кросс‑командные проблемы? «Я обнаружил, что API команды Y отдает нам данные в неоптимальном виде, что грузит нашу базу. Я не стал ждать, а сам пошел к ним, подготовил презентацию с метриками, договорился об изменении контракта API и помог им с имплементацией. Это ускорило наш сервис на 20% и их сервис на 10%».

• Вы улучшали процессы? «Я видел, что наши CI‑пайплайны постоянно красные. Я потратил два дня, проанализировал flaky тесты, нашел корень проблемы, вынес их в отдельный suite и настроил авто‑ретраи.»

• Вы принимали решения? «Когда мы выбирали между X и Y, команда разделилась. Я взял на себя ответственность, провел PoC обеих технологий, представил команде decision matrix с плюсами и минусами по 5 критериям. Команда согласилась с моим выбором Y, и это решение оказалось верным».

Это и есть лидерство. Вы не ждали, пока вам дадут задачу. Вы увидели проблему и сами ее решили. Вы взяли на себя ответственность.

Заключение

Умение рассказать о своей работе — такой же хард скилл, как и умение писать код на Go или деплоить в Kube. Перестаньте думать, что это хвастовство. Это‑ необходимая часть работы инженера.

Вы не хвастаетесь, вы артикулируете свою ценность.

Секция с кодом захватила Ru Big Tech

OTUS совместно с экспертами платформы algocode проведёт открытый онлайн-урок, посвященный прохождению секции про прошлый опыт.

Дата и время: 9 декабря в 19:00 по Мск
Формат: онлайн
Спикер: Даниил — Team Lead в крупной технологической компании, имеет более 5 лет опыта и провёл свыше 50 технических собеседований.

В эту секцию входят:

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

И именно данная секция часто решает: дать тебе middle или middle+, middle+ или senior. 

По итогам урока

1. Понимаешь устройство секции ОТ и ДО

2. Владеешь алгоритмом прохождения

3. Знаешь, как тебя будут оценивать

Также бонусом получишь чек-лист по прохождению секции.

Подробности доступны на странице урока.

Справочная информация:
Материалы algocode включены в программу курса OTUS «Golang Developer. Professional».