Senior отвечает за решение, а не за мнение
Middle предлагает, как сделать задачу. Senior принимает решения, которые потом не стыдно объяснить: с вариантами, критериями, проверкой и пониманием, что будет, если он ошибся. Этот навык одинаков для бэкенда, фронтенда, данных и ИИ.
Минимум два варианта
Один вариант выглядит как готовое решение, которое трудно обсуждать. Поэтому предлагают минимум два, часто третий — «самое простое» или «ничего не делать». Для каждого:
- плюсы и минусы;
- стоимость — сейчас и в поддержке;
- риски;
- что изменило бы выбор: «если нагрузка вырастет в 10 раз — вариант Б».
Критерии сравнения — сроки, нагрузка, поддержка, опыт команды — договаривают до сравнения, иначе каждый выберет «свой». В конце — ваша рекомендация с обоснованием. Минусы любимого варианта не прячут: их всё равно найдут, но уже без доверия к вам.
Спор — в проверку
Когда у каждого своё мнение, спор переводят из мнений в факт:
- Сформулировать, какой факт решит вопрос: «выдержит ли PostgreSQL 5 тысяч записей в секунду на нашем железе?»
- Заранее договориться о критерии: «если да — остаёмся на нём».
- Получить факт маленьким прототипом или замером за часы или дни.
- Записать результат и вывод.
Проверяют самое рискованное допущение, а не всё. Время ограничивают — прототип не должен стать продуктом. Факты на своих данных весомее статей и чужого опыта.
Сколько времени тратить
Решения бывают двух видов:
| Примеры | Как решать | |
|---|---|---|
| Обратимые | библиотека внутри сервиса, формат логов, внутренний API | быстро, небольшой группой, пересматривать по фактам |
| Трудно обратимые | публичный API, схема данных у клиентов, основная база, договор с провайдером | варианты, прототипы, design doc, широкое обсуждение |
Типичная ошибка — неделями обсуждать обратимое и решать за минуту необратимое. Проверочный вопрос: «во что обойдётся передумать через полгода?» А хорошая инженерия делает решения обратимыми: абстракции, флаги, постепенные миграции. Скорость принятия решений — тоже ценность команды.
Своё или готовое
Готовое берут, когда задача не ядро продукта и хорошо решена другими: авторизация, платежи, очереди, генерация PDF. Своё пишут, когда это конкурентное преимущество, готовое не подходит по требованиям или зависимость дороже собственной простой реализации.
Библиотеку оценивают: поддерживается ли (релизы, реакция на issues), лицензия, документация, размер и транзитивные зависимости, безопасность, лёгкость замены. Каждая зависимость — код, за который вы отвечаете. Тонкая обёртка над внешним сервисом упрощает замену. Криптографию, платежи и авторизацию сами не пишут.
Как рассказать о решении на собеседовании
Вопрос «расскажите о сложном техническом решении» проверяет не результат, а то, как вы решали. История по STAR:
- ситуация и ограничения бизнеса;
- варианты и критерии сравнения;
- как проверили гипотезы — прототип, замеры;
- как договорились с командой и зафиксировали решение;
- чем кончилось, включая то, что пошло не так.
Сильный ход — рассказать, как вы пересмотрели своё решение, когда появились новые данные.
Что запомнить
- Два-три варианта с критериями и рекомендацией.
- Спор решают фактом, о критерии договариваются заранее.
- Обратимое — быстро, необратимое — тщательно.
- Каждая зависимость — ваш код.