Работа в команде: процессы, роли, код-ревью, конфликты

Кратко о теме

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

Второе, что проверяется, — честность и калибровка. Вопросы намеренно дублируются и заходят с разных сторон («кто деплоил?» → «в prod мы деплоили или DevOps?» → «ответственность разработчика до какого момента сохранялась?»). Если процесс придуман на ходу, детали расходятся к третьему вопросу. Поэтому базовое правило: личный опыт не выдумывается. Если у вас не было SLO, on-call или менторства — так и говорите, но не останавливайтесь на «не было», а показывайте, что вы понимаете, зачем это нужно и как бы вы это устроили: «формальных SLO у нас не было, метрики и алерты на p99 и долю 5xx были; SLO я бы завёл на availability и latency, потому что …». Ответ «не было, но вот как это устроено и что я бы сделал» звучит сильнее, чем выдуманная история, которая рассыпается на уточняющих вопросах.

Третье — формат. Для любого вопроса про личный опыт работает STAR: Situation (контекст и ограничения), Task (что было вашей задачей и почему это было нетривиально), Action (что сделали именно вы, в первом лице единственного числа), Result (измеримый итог + чему научились). Идеальная длина устного ответа — 60–120 секунд; после этого стоит остановиться и спросить: «Развернуть какую-то часть подробнее?». Дальше в конспекте вместо выдуманных историй даются каркасы с плейсхолдерами вида <цифра> — их нужно заранее заполнить своими реальными фактами и проговорить вслух до собеседования.

Четвёртое — как говорить о людях. Три главных красных флага этого блока: (1) обвинение коллег и предыдущих работодателей («там были плохие разработчики», «фронты вечно всё ломали», «менеджер ничего не понимал»); (2) «конфликтов у меня не было» — это читается как «я не участвовал в принятии решений» либо «я не осознаю конфликты, значит, не умею их разруливать»; (3) пассивная позиция — «мне давали задачу, я делал». Зрелость показывается через механику: не «я был прав», а «мы разошлись в оценке, я предложил измерить, замер показал X, приняли решение и записали его в ADR».

И пятое, чисто прагматичное: NDA. Рассказывать про процессы, роли, инструменты и порядок величин можно почти всегда — это не коммерческая тайна. Не называйте выручку, поимённо клиентов, схемы антифрода и уязвимости. Формулируйте метрики относительно: «сократили p95 на 40 %» вместо «p95 был 812 мс».

Вопросы и ответы

Как у вас устроено взаимодействие фронта и бэкенда?

Коротко. Вопрос проверяет, работаете ли вы на границе системы: есть ли контракт, кто его владелец, как выкатываются несовместимые изменения. Отвечать надо не «мы общались в чате», а через контракт: «REST с OpenAPI-спекой (или gRPC с proto) в отдельном репозитории, кодогенерация клиента, проверка обратной совместимости в CI».

Глубже. Каркас ответа из шести пунктов, каждый — одно предложение: (1) протокол и формат — REST + OpenAPI, gRPC + protobuf, GraphQL, BFF-слой под мобилку; (2) где живёт контракт и кто его пишет — <репозиторий/каталог>, пишет бэкенд после обсуждения с фронтом, или пишут вместе на этапе груминга; (3) кодогенерация — клиент и серверные stubs генерируются, руками DTO не пишутся; (4) как ломаются контракты — только добавление опциональных полей, новые поля не обязательные, удаление через deprecation и версию /v2, проверка buf breaking или сравнение спек в CI; (5) как фронт не блокируется — мок-сервер по спеке, фича-флаги, заглушки; (6) единый формат ошибок и сквозной trace-id, чтобы при разборе инцидента не спорить, «у кого сломалось».

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

Каков был состав вашей команды?

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

Глубже. Шаблон на 30–40 секунд: «Продуктовая команда <N> человек: <K> бэкенд на Go, <K> фронтенд, <K> QA, тимлид, продакт/аналитик, дизайнер на <долю> ставки. DevOps/платформа — общий на <M> команд, не внутри команды. Ежедневно я работал с <кем>; смежные команды — <какие>, интеграция через <брокер/API>». Важно разделять: команда, в которой вы были, ≠ весь отдел ≠ вся компания. Если контекстов было несколько (продуктовая команда + дежурство в платформенной гильдии) — скажите это явно, это плюс.

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

Как устроена ваша команда? Сколько человек, какие роли, кто отвечает за принятие решений?

Коротко. См. выше про состав; отличие этого вопроса — в хвосте про принятие решений. Здесь проверяют, были ли вы субъектом решений или исполнителем, и понимаете ли вы разницу между продуктовыми и техническими решениями.

Глубже. Разделите три контура: продуктовые решения (что делаем и в каком порядке) — продакт/владелец продукта, вход разработки через оценку сложности и предложение более дешёвых альтернатив; технические решения в рамках сервиса — команда, автор решения тот, кто делает, крупные — через мини-RFC/ADR и обсуждение; кросс-командные и архитектурные — архитектурный комитет / гильдия / staff-инженеры, механизм — RFC с периодом комментариев. Отдельно назовите правило разрешения тупика: у тимлида есть право финального решения, дальше все работают по принципу disagree and commit.

Обязательно приведите один конкретный пример вашего влияния: «я предложил <решение>, оформил как ADR, собрал возражения <чьи>, сделали PoC, приняли/отклонили по критерию <какому>». Красные флаги в обе стороны: «решал тимлид, я просто делал тикеты» (пассивность) и «я решал всё сам» (отсутствие командной работы и проверки гипотез).

Как вы работали с git в команде?

Коротко. Вопрос про дисциплину, а не про команды git. Назовите модель ветвления, правила именования веток, размер PR, что защищает main, и как делались хотфиксы.

Глубже. Каркас: (1) модель — trunk-based (короткие ветки, живут < 1–2 дней, всё вливается в main, релизы из main по тегу) либо GitHub Flow, либо GitFlow с develop и релизными ветками (честно скажите какая, и главное — плюсы/минусы, которые вы на себе ощутили); (2) ветки — feature/PROJ-123-short-slug, имя тикета в ветке и в заголовке PR, чтобы трекер линковался автоматически; (3) main защищён: запрет прямого пуша, обязательный зелёный CI, обязательные <N> аппрува, CODEOWNERS на критичные каталоги; (4) история — rebase на main перед мержем, squash-merge, чтобы в main был один осмысленный коммит на задачу (или merge-commit — важно, чтобы вы могли объяснить, почему именно так); (5) сообщения коммитов — Conventional Commits, если из них генерируется changelog; (6) релизы — теги semver, хотфикс веткой от тега с последующим cherry-pick в main.

Полезно уметь ответить на уточнения: чем merge отличается от rebase и когда нельзя ребейзить (опубликованная ветка, на которую кто-то отвёл свою), как разруливали конфликт в общем файле (правильный ответ — созвониться с автором соседнего изменения, а не «взял свою версию»), зачем git bisect, что делать при случайном коммите секрета (ротировать секрет в первую очередь, переписывание истории — во вторую). Красные флаги: «коммитили в мастер», PR на 3000 строк, «конфликты решал так: брал свою версию».

Как выглядел флоу в команде? Когда задача считается завершенной?

Коротко. Ключевое здесь — Definition of Done. Сильный ответ: задача закрыта, когда изменение работает в проде, покрыто тестами и наблюдаемо, а бизнес-заказчик подтвердил результат, — а не когда PR смержен.

Глубже. Опишите путь тикета по колонкам доски и на каждой скажите критерий перехода: Backlog → Ready for dev (есть постановка и acceptance criteria, оценка, зависимости понятны) → In progress → Review (зелёный CI, <N> аппрува) → QA / stage → Ready for release → Released → Done. Дальше проговорите чек-лист DoD, лучше 5–7 пунктов: код в main; unit- и интеграционные тесты на новую логику; обновлены миграции и они обратимы; обновлены документация/OpenAPI; добавлены метрики и алерт, если появилась новая критичная операция; фича выкачена в прод (за флагом или полностью); проверено на реальном трафике по дашборду; тикет принят продактом/аналитиком.

Отдельно стоит назвать, что не входит в DoD, но всплывает: незакрытые TODO, «доделаю тесты потом», флаг, который никто не убрал через полгода. Упоминание про уборку старых фича-флагов — маленькая деталь, которая хорошо выделяет опытного инженера. Красный флаг: DoD = «смержили».

Кто деплоил?

Коротко. Проверяют зрелость CD и то, владеет ли разработчик своим кодом в проде. Оптимальный ответ: деплоит пайплайн, запускает разработчик — автор изменения, ручных шагов на проде нет.

Глубже. Честно назовите вашу схему из трёх типовых: (1) CD: мерж в main → автоматический прогон тестов → выкатка на stage → ручное подтверждение (кнопка в GitLab CI/Argo) → прод, нажимает автор; (2) релиз-менеджер/дежурный: собирается релиз из нескольких задач, катит дежурный по расписанию; (3) через DevOps/эксплуатацию: разработчик оформляет заявку, катит другая команда (типично для банков и регулируемых сред). Для своей схемы скажите, что в ней было хорошо и что раздражало — это показывает рефлексию: например, «через заявку было медленно, lead time на хотфикс — часы, поэтому мы протащили право катить самим для некритичных сервисов».

Полезные детали, которые стоит добавить: как выглядит откат (rollback одной командой / переключение флага / откат образа на предыдущий тег), сколько времени занимает выкатка, сколько релизов в неделю (это фактически DORA-метрика deployment frequency), кто смотрит на графики после выкатки. Красный флаг: «я не знаю, как выкатывался мой код».

Деплоили сразу по факту?

Коротко. Речь про continuous deployment против релизных поездов. Ответ: скажите вашу частоту («каждый мерж в main ехал в прод в тот же день», либо «релиз собирался по вторникам и четвергам») и объясните, чем это было продиктовано.

Глубже. Что важно показать — понимание trade-off. Частые мелкие релизы: меньше диффа на релиз, проще искать причину поломки, ниже change failure rate, быстрее откат; требуют автотестов, фича-флагов и наблюдаемости. Редкие большие релизы: проще согласовывать с внешними участниками, но каждая выкатка — риск, и разбирать инцидент дороже. Отдельно назовите механику, которая позволяет катить сразу, но включать не сразу: фича-флаги, dark launch (код исполняется, результат не показывается), canary/поэтапная раскатка по проценту трафика, expand-contract для миграций БД (сначала добавляем колонку и пишем в обе, потом переключаем чтение, потом удаляем старую) — это позволяет деплоить в любой момент, потому что деплой отвязан от релиза функциональности.

Назовите и ограничения: если у вас мобильный клиент, версия API живёт столько, сколько живут старые приложения; если есть тяжёлая миграция — окно; если релиз завязан на маркетинг — дата. Красный флаг: «катили сразу» без единого слова про то, что делали, когда сразу катить нельзя.

Были ли релизные даты?

Коротко. Проверяют, работали ли вы в среде с внешними обязательствами и умеете ли планировать под дату. Ответ по факту: были фиксированные окна/даты или поток; и что вы делали, когда становилось ясно, что в дату не попадаете.

Глубже. Типовые причины дат, которые полезно назвать: релизные поезда с фиксированным расписанием; code freeze в высокий сезон (чёрная пятница, отчётные периоды, новогодние праздники); регуляторные дедлайны (требование ЦБ/закон вступает в силу такого-то числа); релиз мобильного приложения, привязанный к ревью сторов; совместный запуск с маркетингом или партнёром. Дальше — самое важное: как вы вели себя при риске срыва. Правильная модель — эскалировать рано и с вариантами: «на середине спринта стало видно, что интеграция с <системой> даёт риск в <N> дней; я вынес это на дейли и предложил три варианта — урезать скоуп до MVP, выкатить за флагом только для внутренних пользователей, сдвинуть на неделю; выбрали <какой>».

Красные флаги: «мы всегда всё успевали» (не бывает), «сроки назвал менеджер, я просто делал» (нет участия в оценке), рассказ про переработки как про норму — «закрывали дату овертаймами» звучит как сигнал о плохом планировании, а не о героизме.

Ответственность разработчика до какого момента по задаче сохранялась?

Коротко. Правильный ориентир — you build it, you run it: ответственность не заканчивается на мерже, она заканчивается, когда фича работает в проде, метрики в норме и заказчик принял результат; а по инцидентам в своём сервисе — не заканчивается никогда, пока код ваш.

Глубже. Разложите на уровни: (1) до мержа — код, тесты, самопроверка диффа; (2) до выкатки — миграции, конфиги, фича-флаг, план отката; (3) первые <30–60> минут после выкатки — смотрю дашборд: доля 5xx, p95/p99, ошибки в логах, очереди, потребление ресурсов; (4) первые дни — реагирую на баги по своей фиче вне очереди; (5) постоянно — дежурство по сервису (on-call, если было; если не было — скажите честно), участие в разборе инцидентов, безвиновный постмортем с action items и их доведение до конца. Если у вас были on-call и постмортемы — это сильный сигнал, расскажите про механику: график дежурств, эскалация, runbook.

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

В prod мы деплоили или DevOps?

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

Глубже. Разница между схемами обычно объясняется не зрелостью, а требованиями: в регулируемых отраслях (финансы, медицина, PCI DSS, SOX-подобные требования) действует separation of duties — тот, кто пишет код, не должен единолично выкатывать его в прод, нужен второй человек и аудируемый след. Это не «отсталость», и умение это объяснить — плюс. Правильная формулировка: «выкатку в прод инициировал разработчик, подтверждал тимлид или дежурный — требование по разделению обязанностей; все действия шли через пайплайн, ручного kubectl apply на проде не было ни у кого».

Полезно назвать уровень доступов честно: был ли у вас read-only доступ к прод-логам и метрикам (это норма и нужно для дежурства), был ли доступ к прод-БД (в зрелых командах — только через аудируемый bastion/временный доступ по заявке и почти никогда на запись). Красный флаг: «у всех был рут на проде, катили руками с ноутбука» — сказать так можно, только если следом идёт «и это была проблема, мы её чинили тем-то».

Какие флаги бывают у команды kill?

Коротко. Вопрос попал в блок про команду по недоразумению — он про Unix-команду kill. По умолчанию kill PID шлёт SIGTERM (15); основные флаги: -l — список сигналов, -s SIGNAL / -SIGNAL / -НОМЕР — какой сигнал послать, -0 — ничего не слать, только проверить существование процесса и права на него.

Глубже. Детали, которые уместно добавить: отрицательный PID означает группу процессов (kill -TERM -1234 — всей группе), kill 0 — текущей группе; kill -l 9 печатает имя сигнала по номеру. Есть два разных kill: встроенный в shell (у него работает синтаксис %1 для job’ов) и /bin/kill из util-linux, у которого есть дополнительно -q value (послать через sigqueue с данными), --timeout (послать один сигнал, потом через время другой), -a, -p, --verbose. Рядом стоят pkill/killall — они выбирают процессы по имени и маске, а не по PID. SIGKILL (9) и SIGSTOP нельзя перехватить, заблокировать или проигнорировать — их обрабатывает ядро.

Практическая связка с Go и контейнерами, которая на собеседовании ценнее списка флагов: контейнерные рантаймы при остановке шлют процессу с PID 1 SIGTERM и через grace period (terminationGracePeriodSeconds в Kubernetes, по умолчанию 30 с) добивают SIGKILL. Поэтому сервис обязан ловить SIGTERM и корректно завершаться:

package main

import (
  "context"
  "errors"
  "net/http"
  "os/signal"
  "syscall"
  "time"
)

func main() {
  ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGINT, syscall.SIGTERM)
  defer stop()

  srv := &http.Server{Addr: ":8080"}
  go func() {
    if err := srv.ListenAndServe(); err != nil && !errors.Is(err, http.ErrServerClosed) {
      panic(err)
    }
  }()

  <-ctx.Done() // пришёл SIGTERM

  shutdownCtx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
  defer cancel()
  _ = srv.Shutdown(shutdownCtx) // дожидаемся активных запросов
}

Типичная ошибка в проде: процесс запущен через sh -c "...", shell становится PID 1, SIGTERM до приложения не доходит, и под всегда умирает по SIGKILL с обрывом запросов.

Расскажи сколько человек в команде? Какой формат команд?

Коротко. См. выше про состав команды; отличие — во второй части: спрашивают про формат, то есть кросс-функциональная продуктовая команда, компонентная команда или платформенная. Назовите формат словами и объясните, что было в зоне ответственности команды целиком.

Глубже. Полезная рамка — Team Topologies: stream-aligned (продуктовая команда, владеет куском пользовательской ценности end-to-end, внутри есть все компетенции), platform (делает внутренний продукт для других команд: CI, кластеры, общие библиотеки), enabling (временно подключается, чтобы прокачать другие команды), complicated-subsystem (узкая экспертиза — биллинг, поиск, ML). Скажите, к какому типу относилась ваша команда и как это влияло на работу: у stream-aligned зависимость от других команд минимальна и релизный цикл свой; у компонентной («команда бэкенда», «команда фронтенда») любая фича требует синхронизации двух-трёх команд, и это главный источник задержек.

Добавьте про масштаб: «команда владела <N> сервисами, границы — по бизнес-домену <какому>, чужие сервисы правили через PR в их репозиторий с ревью владельцев (inner source) или через задачу в их бэклог». Красный флаг: невозможность объяснить, где кончалась ответственность вашей команды и начиналась чужая.

Как выглядит флоу задачи? Кто ставит задачи? Через кого она проходит?

Коротко. См. выше про флоу и DoD; здесь дополнительно спрашивают про источник задач и цепочку согласований. Назовите все источники, а не только «продакт даёт тикеты».

Глубже. Источников обычно четыре, и хороший ответ перечисляет все: (1) продуктовые задачи — продакт/аналитик, попадают в бэклог через груминг; (2) баги и обращения поддержки — через триаж, с приоритетом по влиянию; (3) инциденты и их action items — попадают в спринт вне очереди; (4) техдолг и инициативы инженеров — свой бюджет в спринте, <10–20> %. Дальше цепочка: постановка → груминг (уточняем, декомпозируем, оцениваем, фиксируем acceptance criteria) → приоритизация продактом → спринт/доска → разработка → ревью → QA → релиз → приёмка автором постановки.

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

Как устроен code review?

Коротко. Расскажите механику и нормативы: сколько ревьюеров, какой SLA на ревью, какой размер PR считался нормальным, что проверяет CI, а что человек. Сильный ответ отделяет автоматизируемое (форматирование, линтеры, тесты) от того, ради чего ревью существует, — семантика, контракты, крайние случаи, читаемость через полгода.

Глубже. Каркас: (1) обязательность — <1–2> аппрува, CODEOWNERS на критичные пакеты, автор не мержит без зелёного CI; (2) SLA — ревью в течение рабочего дня, иначе PR протухает и конфликтует; это командная договорённость, а не вежливость; (3) размер — целимся в <200–400> строк диффа, большое разбиваем на стек PR или прячем за флаг; (4) автоматика — gofmt/goimports, golangci-lint (errcheck, govet, staticcheck, ineffassign), go test -race, govulncheck, проверка обратной совместимости контракта; (5) человеческое — правильность логики и обработка ошибок, границы (пустой список, отмена контекста, ретраи и идемпотентность), гонки и блокировки, влияние на БД (N+1, отсутствие индекса, длинная транзакция), обратная совместимость API и миграций, тесты на новый инвариант, имена и читаемость; (6) как разрешается спор — обсуждение в PR максимум в два круга, дальше созвон на 10 минут, если не сошлись — третий инженер или тимлид, решение фиксируется в ADR/гайдлайне, чтобы не спорить об этом снова.

Зрелость на ревью показывается формулировками. Полезные привычки: маркировать необязательные замечания — nit: (придирка, можно не править), question: (не понял, объясни), blocking: (без этого не мержим); писать «почему», а не только «как» — «здесь стоит обернуть ошибку через %w, иначе выше не сработает errors.Is и мы потеряем причину в алерте»; критиковать код, а не человека («этот метод делает две вещи», а не «ты опять намешал»); отмечать хорошее; при третьем круге замечаний переходить в голос. И обратная сторона — как вы принимаете замечания на своём коде: без спора ради спора, с явным «согласен, поправил» или «не согласен, вот аргумент, давай решим». Красные флаги: ревью как ворота («не пропущу, пока не сделаешь по-моему»), сарказм, споры о форматировании при живом линтере, «у нас ревью не было, доверяли друг другу».

Как в вашей команде выбираются технологии и библиотеки?

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

Глубже. Критерии, по которым стоит проходить вслух: решает ли задачу stdlib или существующая зависимость; активность проекта (последний релиз, число мейнтейнеров, скорость закрытия issue — «один автор и последний коммит два года назад» это риск); лицензия (MIT/Apache-2.0 против GPL/AGPL в проприетарном коде — обычно есть политика компании); размер и качество транзитивных зависимостей; наличие CVE, govulncheck в CI; стабильность API и версия (v0.x — сигнал о ломающих изменениях); насколько сложно уйти обратно (обёрнута ли зависимость своим интерфейсом); стоимость эксплуатации, если это инфраструктурный компонент — «поднять ClickHouse легко, дежурить по нему тяжело»; экспертиза в команде и на рынке найма.

Процесс: короткий RFC или ADR на страницу (проблема, варианты, критерии, решение, последствия и как откатимся), PoC на пару дней при существенных ставках, обсуждение с платформенной командой, если это влияет на инфраструктуру. Полезно упомянуть tech radar — список «используем / пробуем / только с обоснованием / не используем». Красные флаги: «взяли самый популярный фреймворк», «так решил тимлид» без критериев, притаскивание тяжёлой зависимости ради одной функции на двадцать строк, и обратная крайность — писать своё вместо зрелой библиотеки без обоснования.

Как было разграничено взаимодействие между разработчиками и DevOps?

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

Глубже. Типовая зрелая раскладка: на стороне разработчиков — Dockerfile, манифесты/Helm-чарт своего сервиса, значения ресурсов (requests/limits), пайплайн своего репозитория, свои дашборды и алерты, миграции, конфиг и фича-флаги; на стороне платформы/DevOps — кластеры и их обновление, базовые образы, раннеры CI, ingress и сеть, секреты и их ротация, общий стек наблюдаемости (Prometheus, Loki, Grafana, трассировки), бэкапы и DR, квоты и стоимость. Взаимодействие — не «заявка в никуда», а понятные каналы: самообслуживание через шаблоны и Terraform-модули, PR в репозиторий инфраструктуры с ревью платформы, задача в их бэклог для нестандартного, и отдельный канал для срочного в инциденте.

Полезно назвать анти-паттерн и как вы с ним жили: «DevOps как единственный человек с доступом» — узкое место, lead time растёт, разработчики не понимают прод. Признак зрелости в ответе — вы знали, как устроена ваша выкатка, могли сами прочитать логи и метрики, посмотреть события пода, и обращались к платформе не «у нас не работает», а с диагностикой. Красный флаг: «инфраструктура — не моя зона, я пишу код».

За что отвечает флаг -v в команде go test ?

Коротко. Ещё один технический вопрос, попавший в блок случайно. -v включает подробный вывод: печатаются строки === RUN / --- PASS / --- FAIL с именем и временем каждого теста и подтеста, а также весь вывод t.Log/t.Logf — без -v логи показываются только у упавших тестов, а у прошедших подавляются.

Глубже. Практические детали: с Go 1.14 вывод t.Log при -v печатается потоково по мере выполнения, а не копится до конца прогона, — это заметно при долгих и параллельных тестах. Флаг -v входит в набор «кэшируемых» флагов go test, то есть сам по себе не отключает кэш результатов (в отличие от, например, произвольных пользовательских флагов; принудительно сбросить кэш — go clean -testcache или -count=1). Команда go test -json включает подробный режим в машиночитаемом виде (внутри это -v=test2json), что удобно для CI и gotestsum. Не путайте с go build -v и go get -v, где -v печатает имена собираемых пакетов, — это другая семантика того же флага.

package sum_test

import "testing"

func TestSum(t *testing.T) {
  t.Log("этот вывод виден только с -v или при падении теста")
  if got := 2 + 2; got != 4 {
    t.Errorf("got %d, want 4", got)
  }
}

Ещё одна деталь для уточняющего вопроса: -v не влияет на то, какие тесты запускаются (для этого -run), и не делает тест «строже» — он только меняет вывод. При отладке гонок его обычно совмещают с -race, а при поиске плавающих тестов — с -count=N и -shuffle=on.

Какая была структура команды и инженерных процессов в проекте? Сколько человек входило в кросс-функциональную команду?

Коротко. Сводный вопрос: см. выше про состав, формат и флоу. Ответ стройте по схеме «структура за 30 секунд → процессы за 60 секунд → одна деталь, которой вы гордитесь или которую считали проблемой».

Глубже. Готовый скелет монолога: «Кросс-функциональная команда <N> человек: <состав>. Владели <M> сервисами в домене <каком>. Процессы: двухнедельные спринты (или канбан с WIP-лимитами), дейли <длительность>, груминг раз в неделю, ретро в конце спринта, демо заказчику. Задачи проходят <цепочка>. Ревью — <N> аппрува, CI гоняет <что>. Тестирование — пирамида: unit в каждом PR, интеграционные на testcontainers, e2e на stage ночью, ручная проверка QA на приёмке. Релизы <частота>, откат <как>. Техдолг — <доля> спринта, ведём отдельный реестр». Дальше — честная оценка: «слабое место было в <чём>, мы это чинили тем, что <что сделали>».

Про размер: типичная продуктовая команда — 5–9 человек (два-три бэкенда, один-два фронта, QA, продакт, шаредный дизайнер и DevOps). Если у вас было больше пятнадцати — это скорее отдел из нескольких команд, скажите это явно, иначе интервьюер решит, что вы преувеличиваете. Красный флаг: перечисление ритуалов без содержания — «у нас был скрам» без ответа на вопрос, что реально делали на ретро и менялось ли что-то после него.

Занимались ли вы менторством молодых сотрудников? Как оценивали их результаты, какие первые задачи давали?

Коротко. Если менторили — отвечайте по STAR с конкретикой: сколько человек, сколько времени, что с ними стало. Если не менторили — не выдумывайте: скажите, что формального наставничества не было, но перечислите смежное (онбординг-бадди, ревью джунов, внутренние доклады, документация) и как бы вы построили менторство.

Глубже. Про первые задачи есть содержательный правильный ответ, его и ждут: первая задача новичка должна быть маленькой, безопасной и проходящей через весь конвейер — правка текста ошибки, добавление поля в ответ API, метрика, тест. Смысл не в коде, а в том, чтобы человек за первые дни сам прошёл путь «получил тикет → поднял окружение → внёс правку → написал тест → открыл PR → получил ревью → увидел свой код в проде». Дальше — багфиксы в одном ограниченном модуле (учат читать чужой код и пользоваться логами), затем фича целиком с помощью в декомпозиции, затем самостоятельная декомпозиция. Явно назовите правило: задача с чётким критерием готовности, ограничение по времени («если через два часа не сдвинулся — приходи»), и запрет решать за него — задавать наводящие вопросы вместо готового ответа.

Как оценивать результат — не строками кода и не скоростью. Работающие критерии: уровень автономии (нужны пошаговые инструкции → нужна цель → сам приносит варианты решения); число кругов ревью на типовой задаче и повторяемость одних и тех же замечаний; предсказуемость — насколько его оценка близка к факту и вовремя ли он сигналит о проблеме; качество вопросов — «не работает» против «я проверил A и B, гипотеза C, как проверить?»; отзывы QA и смежников. Оформлять это удобно через матрицу компетенций и план на 3 месяца с 3–5 измеримыми целями, регулярные 1:1 раз в неделю на 30 минут с записью договорённостей. Красные флаги: «менторил всю команду» без конкретики, оценка через «нравится/не нравится», рассказ, из которого следует, что вы делали задачи за подопечного.

Какой у вас опыт менторинга и проведения code review? Как вы даете обратную связь?

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

Глубже. Работающая структура — SBI: ситуация («вчера в PR по биллингу»), поведение («ошибка из репозитория возвращалась наверх без контекста»), влияние («в алерте мы видим sql: no rows и не понимаем, какой заказ — на разборе инцидента это стоило нам получаса»), затем запрос и договорённость («давай оборачивать через fmt.Errorf("get order %s: %w", id, err); я добавлю правило в гайдлайн»). Общие правила: критика — приватно (личка, 1:1), похвала — публично (в канале команды); по горячим следам, а не раз в полгода на перформанс-ревью; отделять обязательное от вкусовщины; спрашивать, а не приказывать, когда не уверены в контексте; проверять, что человек услышал, — «как тебе такой вариант?»; на каждое «не так» давать «а как надо» и ссылку.

Отдельно — обратная связь наверх, менеджеру и тимлиду. Зрелая позиция: приносить проблему с вариантами решения и данными, а не жалобу; заранее сигналить о рисках, а не в день дедлайна; на 1:1 явно проговаривать ожидания и приоритеты, чтобы не оказалось, что вы полгода делали «не то»; уметь сказать «нет» через альтернативу — «в срок влезет либо A, либо B, что важнее?». Хороший ответ на этот вопрос почти всегда включает и умение принимать обратную связь: пример, когда вам сказали неприятное по делу, вы согласились и что изменили. Красные флаги: «я просто пишу, что не так», обратная связь только негативная, обсуждение чужих ошибок в общем канале с именами.

Что такое SLI, SLO, SLA в вашей команде? Как они определялись и измерялись?

Коротко. SLI — измеряемый показатель качества сервиса (доля успешных запросов, доля запросов быстрее порога); SLO — внутренняя цель по этому показателю на окне (99,9 % за 30 дней); SLA — внешнее обязательство перед клиентом с санкциями за нарушение, всегда мягче SLO. Если формальных SLO у вас не было — скажите честно и опишите, какие метрики и алерты были вместо них.

Глубже. Как это выглядит на практике: SLI формулируется как отношение хороших событий к общему числу — availability sum(rate(http_requests_total{code!~"5.."}[5m])) / sum(rate(http_requests_total[5m])), latency — доля запросов быстрее 300 мс, считается по гистограмме, а не по среднему. SLO выбирается от потребности пользователя, а не «побольше девяток»: каждая дополнительная девятка кратно дороже. Из SLO следует error budget: при SLO 99,9 % за 30 дней бюджет ошибок — примерно 43 минуты недоступности; пока бюджет не израсходован, команда катит фичи, когда сожжён — приоритет уходит в надёжность. Алертить правильно не на «сервис упал», а на скорость сжигания бюджета (multi-window multi-burn-rate), иначе получите или шум, или пропущенные деградации.

Дополнительно стоит уметь сказать: SLI меряется как можно ближе к пользователю (на балансировщике или синтетикой), потому что «сервис отвечает 200» и «пользователь видит страницу» — разные вещи; для очередей SLI — это лаг и время обработки, а не uptime; SLA обычно включает исключения (плановые работы, форс-мажор, вина клиента) и определяет только компенсацию, а не реальное качество. Красный флаг: путать SLA и SLO местами и заявлять «у нас было SLA 99,99 %» без единого слова о том, как это измерялось.

Как устроены процессы в команде от момента прихода задачи до релиза в продакшен? (есть ли дэйлики/ретры/груминги, скрам или канбан, кроссфункциональные команды или нет, девопсы в команде или нет, как тестируете, как работаете с техдолгом, как выглядит гит флоу)

Коротко. Это вопрос-чек-лист: интервьюер прямо перечислил, что хочет услышать, поэтому отвечайте по его пунктам по порядку и держитесь в пределах двух минут. Частичное содержание — см. выше про флоу задачи, git и разграничение с DevOps.

Глубже. Порядок ответа: (1) методология — скрам с двухнедельными спринтами или канбан с WIP-лимитами; назовите, что реально давало пользу, а что было формальностью; (2) ритуалы — дейли 15 минут (статус по доске и блокеры, а не отчёт менеджеру), груминг раз в неделю, планирование, ретро раз в спринт с 2–3 action items и проверкой прошлых, демо заказчику; (3) состав — кросс-функциональная или нет, есть ли DevOps внутри команды или платформа снаружи; (4) тестирование — пирамида: unit-тесты обязательны на новую логику, интеграционные на testcontainers с реальными Postgres/Kafka, контрактные тесты на API, e2e-набор на stage, нагрузочные перед крупными изменениями, -race в CI; кто пишет тесты (разработчик) и что делает QA (приёмка, исследовательское тестирование, автоматизация e2e); (5) техдолг — реестр с оценкой влияния, фиксированная доля спринта <10–20> %, крупные вещи оформляются как проект с обоснованием через метрики (время сборки, частота инцидентов, скорость разработки); правило бойскаута для мелкого; (6) git flow — trunk-based/GitHub Flow, защита main, squash, теги; (7) релиз — частота, канареечная выкатка, флаги, откат, наблюдение после релиза.

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

Как оценивали задачи в команде?

Коротко. Назовите метод (story points покером планирования, T-shirt, оценка в днях, трёхточечная, или вовсе поток без оценок с метрикой cycle time) и главное — что делали при расхождении оценки с фактом. Правильный акцент: оценка нужна для планирования и разговора о рисках, а не как норма выработки.

Глубже. Почему относительные оценки: людям плохо даётся абсолютное время и хорошо — сравнение («это как та задача, только сложнее»), поэтому story points сравниваются с эталонной задачей, а перевод в календарь делается через историческую velocity команды. Покер планирования полезен не цифрой, а расхождением: если один сказал 2, другой 13 — значит, они поняли задачу по-разному, и обсуждение этого расхождения ценнее самой оценки. Обязательные практики: декомпозиция до кусков в 1–2 дня (всё, что «неделя», на самом деле «не знаю»), отдельный spike с таймбоксом на исследование неизвестного, учёт в оценке ревью, тестов, миграций, выкатки и наблюдения, а не только написания кода, и буфер на неопределённость через трёхточечную оценку (оптимистичная, вероятная, пессимистичная).

Важное, что стоит сказать явно: velocity — инструмент планирования команды, а не KPI разработчика; как только по ней меряют людей, она мгновенно инфлируется. И механика обновления: как только вы поняли, что оценка не сходится, вы сообщаете сразу, а не в день сдачи, и приносите варианты (урезать скоуп, разбить, попросить помощь). Альтернативный честный ответ: «мы работали по канбану и не оценивали задачи, вместо этого смотрели на cycle time и throughput и обещали заказчику вероятностный срок» — это зрелый подход, если вы можете его объяснить. Красные флаги: «оценивали как чувствовали», «оценку называл менеджер», «я всегда укладывался в оценку».

Были ли конфликты среди других разработчиков и если дa, то как их решали?

Коротко. Отвечать «конфликтов не было» нельзя — это читается либо как неучастие в решениях, либо как неспособность их замечать. Возьмите реальное рабочее разногласие (архитектура, приоритеты, качество кода, границы ответственности), расскажите его по STAR и покажите механизм разрешения, а не свою правоту.

Глубже. Каркас с плейсхолдерами: S — «мы обсуждали <решение: например, синхронный вызов между сервисами против события в брокер>, сроки поджимали»; T — «нужно было выбрать вариант так, чтобы не сорвать релиз и не получить проблему через полгода»; A — «я предложил вынести обсуждение из переписки в 20-минутный созвон; попросил каждого сформулировать не решение, а требование, которое он защищает (<требование A: простота и скорость> против <требования B: устойчивость к пикам>); мы выписали критерии, по которым выбираем, признали, что данных не хватает, и сделали замер/PoC за <время>»; R — «выбрали <вариант> по критерию <какому>, зафиксировали в ADR, чтобы не возвращаться к спору; я был не согласен в части <чего>, сказал это вслух и дальше работал по принятому решению».

Что здесь считывается как зрелость: вы описываете чужую позицию честно и сильно (а не «коллега упрямился»), переводите спор из личного в проверяемое, переносите обсуждение в синхронный канал (переписка эскалирует конфликты), обращаетесь к тимлиду только после прямого разговора и не как жалобу, а как запрос на решение, и умеете сказать «disagree and commit». Хорошо, если в результате есть системное улучшение — гайдлайн, шаблон ADR, договорённость о правилах ревью, — то есть вы починили не случай, а причину. Красные флаги: любая версия «я был прав, он не понимал»; конфликт, решённый эскалацией через голову; рассказ про личную неприязнь без рабочей сути; и рассказ, в котором вы просто уступили, лишь бы не спорить.

Что такое конфликт, когда он образуется, что делать, если он возник?

Коротко. Конфликт — это столкновение интересов, позиций или требований, когда стороны считают их несовместимыми. Возникает он не от плохих людей, а от разной информации, разных целей и метрик, дефицита ресурсов и нечётких границ ответственности; лечится переводом с уровня позиций («делаем по-моему») на уровень интересов («какую проблему каждый из нас закрывает»).

Глубже. Полезно различать типы: предметный/задачный (спор о содержании решения) — при нормальной культуре он полезен и повышает качество решений; процессный (кто что делает, как работаем) — лечится договорённостями и явными зонами ответственности; межличностный (перешли на личности) — деструктивен, требует вмешательства и раннего разведения; ресурсный (сроки, люди, приоритеты) — решается не внутри команды, а с тем, кто владеет приоритетами. Динамика обычно такая: скрытое расхождение → первые сигналы (сарказм в комментариях, затянутое ревью, обходные решения) → эскалация и переход на личности → либо разрешение, либо тихий саботаж. Чем раньше вмешаться, тем дешевле.

Алгоритм на случай «конфликт уже есть»: (1) снизить накал — пауза, никаких ответов в переписке в эмоциях; (2) сменить канал на синхронный, лучше один на один; (3) отделить человека от проблемы, начать с того, в чём согласны; (4) выяснить интересы за позициями, задавая вопросы, а не защищаясь; (5) договориться о критериях выбора до обсуждения вариантов (замер, стоимость поддержки, риск, срок) — это переводит спор в проверяемую плоскость; (6) если данных не хватает — эксперимент/PoC с таймбоксом; (7) принять решение, записать его и причины (ADR, тикет, сообщение в канал команды); (8) если согласия нет — назвать явного решающего (тимлид, владелец сервиса) и дальше disagree and commit; (9) вернуться к решению через <время> и проверить по фактам. Из моделей уместно упомянуть Томаса–Килманна (соперничество, сотрудничество, компромисс, избегание, приспособление) с оговоркой, что стратегия выбирается по ситуации: сотрудничество — для важных долгоживущих решений, компромисс — когда время дороже идеала, приспособление — когда вопрос для вас маловажен, а для коллеги критичен, соперничество — только в инциденте, когда нужен один голос. Красный флаг: считать конфликт всегда злом и любой ценой его избегать — избегание в инженерной команде обычно превращается в тихую деградацию архитектуры.

Опишите состав команды и вашу роль в ней. Какие ключевые результаты вам удалось достичь?

Коротко. См. выше про состав; ключевая часть здесь — результаты. Возьмите два-три достижения, каждое опишите формулой «проблема → что сделал именно я → измеримый эффект», и обязательно разведите «мы» и «я».

Глубже. Каркас достижения: «Было <исходное состояние с цифрой> → проблема для бизнеса <какая> → я сделал <что конкретно, своя часть в командной работе> → стало <цифра> → эффект <деньги, время, надёжность, скорость команды>». Хорошие типы результатов для бэкендера: производительность и стоимость (p99 с <X> до <Y>, потребление CPU/памяти, счёт за инфраструктуру), надёжность (частота инцидентов, время восстановления, доля ошибок), скорость поставки (время сборки CI, lead time, частота релизов), продукт (запустил интеграцию/сервис, который обрабатывает <N> запросов), команда (онбординг, гайдлайны, менторство, снятие узкого места на ревью). Два-три пункта достаточно; десять расфокусируют.

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

Кто ставил задачи: тимлид или аналитик?

Коротко. Отвечайте по факту — правильного варианта нет. Важно другое: приходила ли к вам задача с ответом на вопросы «зачем» и «как проверить», и что вы делали, если не приходила.

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

Хорошая добавка, показывающая инициативу: «технические задачи (техдолг, надёжность, ускорение сборки) я заводил себе сам и защищал их приоритет на груминге цифрами — <пример>». Это отвечает на скрытый вопрос интервьюера: работаете ли вы только по указке. Красный флаг: ответ, из которого следует, что вы никогда не общались с постановщиком напрямую и не понимали бизнес-смысла своих задач.

Задачи давали готовыми или вы их дорабатывали?

Коротко. Здесь проверяют проактивность и умение работать с неполными требованиями. Сильный ответ: «постановки приходили разного качества; я всегда сам доводил их до состояния, когда понятно, что считается успехом, и фиксировал это письменно в тикете».

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

Отдельный сильный ход — рассказать, как вы удешевляли постановки: «часто предлагал более простую реализацию, закрывающую 90 % пользы за 30 % трудозатрат, и это принимали в <доле> случаев». Это ровно то поведение, за которое платят senior’у. Красные флаги: «мне давали готовое, я просто кодил», «требования были плохие, поэтому получилось плохо» — перекладывание ответственности.

Готовы ли работать без аналитиков, выполняя их роль?

Коротко. За вопросом почти всегда стоит факт: в команде нет аналитика и требования придётся вытаскивать самому. Отвечайте «да» — но с условиями, а не безусловно: нужен прямой доступ к заказчику, время на это в оценке и право письменно фиксировать решения.

Глубже. Развёрнутая формулировка: «Да, работал в таком режиме и он мне понятен: я иду к заказчику или в поддержку, выясняю, какую проблему решаем, описываю сценарии и критерии приёмки сам, согласую письменно и только потом начинаю. Три условия, без которых это не работает: (1) есть человек, принимающий решения по продукту, и я могу с ним говорить напрямую; (2) аналитическая часть учтена в сроках — это реальная работа, а не «в фоне»; (3) договорённости фиксируются в тикете или документе, иначе через месяц окажется, что имелось в виду другое». Полезно добавить, что вы понимаете границу: сбор требований и описание сценариев — да; глубокая предметная аналитика в сложном регулируемом домене или полноценное продуктовое исследование — это отдельная компетенция, и подменять её собой на постоянной основе неэффективно.

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

Частые ошибки на собесе

• «Конфликтов у нас не было» — самый частый провал этого блока. Читается как неучастие в решениях или неумение их замечать. Нужен реальный пример рабочего разногласия и механизм его разрешения.
• Обвинение коллег, менеджеров и прошлых работодателей. «Фронты вечно ломали», «там были слабые разработчики», «менеджер ничего не понимал» — интервьюер немедленно примеряет это на себя и свою команду. Про любой негатив говорите как про проблему процесса и что вы пытались с ней сделать.
• Выдуманный опыт. Процессы, SLO, on-call и менторство проверяются двумя уточняющими вопросами. «Не было, но вот зачем это нужно и как бы я это сделал» — сильный ответ; выдумка, рассыпающаяся на деталях, — фатальный.
• DoD = «смержил PR». Ответственность, обрывающаяся на мерже или на передаче в QA, — главный маркер джуниорского мышления в этом блоке, независимо от заявленного грейда.
• Пассивная позиция. «Мне давали задачи, я делал», «решал тимлид», «сроки называл менеджер». Даже если так и было, покажите, где вы влияли: оценка, альтернативы, техдолг, инициативы.
• Ритуалы вместо процесса. Перечисление «дейли, груминг, ретро, скрам» без содержания. Интервьюер спросит, что менялось после ретро, — и здесь всё становится ясно.
• Сплошное «мы» или сплошное «я». В первом случае не виден ваш вклад, во втором не верится и не видно команды. Правильно: «команда сделала X, моя часть — Y».
• Результаты без цифр и без базы сравнения. «Улучшил производительность» ничего не значит. Если цифр нет — скажите честно, что не мерили, это лучше выдуманных процентов.
• Код-ревью как ворота и споры о форматировании. При живом линтере обсуждать пробелы, требовать «сделай как я» без аргумента, писать замечания с сарказмом — всё это описывается одним словом «токсично» и закрывает оффер быстрее технической ошибки.
• Пренебрежение к легаси. «Там был ужасный код, писали до меня» — плохо. Зрелая формулировка: код, который я трогаю, становится моим; покрываю тестами изменяемый кусок, крупное фиксирую в техдолг с оценкой влияния, не переписываю всё разом.
• Слишком длинный ответ. Монолог на пять минут без остановки утомляет и съедает время на технические вопросы. 60–120 секунд, затем «развернуть подробнее?».

Что почитать

• Google, «How to do a code review» и «The Standard of Code Review» из Engineering Practices: https://google.github.io/eng-practices/review/
• Google SRE Book, главы «Service Level Objectives» и «Alerting on SLOs» (в SRE Workbook): https://sre.google/sre-book/service-level-objectives/ и https://sre.google/workbook/alerting-on-slos/
• DORA: четыре ключевых метрики поставки и State of DevOps: https://dora.dev/guides/dora-metrics-four-keys/
• Matthew Skelton, Manuel Pais, «Team Topologies» — типы команд и режимы взаимодействия: https://teamtopologies.com/key-concepts
• Trunk Based Development и сравнение git-воркфлоу: https://trunkbaseddevelopment.com/ и https://www.atlassian.com/git/tutorials/comparing-workflows
• Martin Fowler, «Feature Toggles (aka Feature Flags)» и «Blue Green Deployment»: https://martinfowler.com/articles/feature-toggles.html
• Kim Scott, «Radical Candor» — рамка для обратной связи; Thomas–Kilmann Conflict Mode Instrument — модель стратегий поведения в конфликте
• Документация Go по флагам тестирования (go help test, go help testflag): https://pkg.go.dev/cmd/go#hdr-Testing_flags и man-страницы kill(1), signal(7)