Общие HR-вопросы: обязанности, процессы, инструменты, поведенческие кейсы

Кратко о теме

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

Второе, что стоит понимать: HR-этап в Go-командах в 2024–2026 годах почти всегда содержит лёгкую техническую часть — не «расскажите про GMP-планировщик», а верификацию резюме: с чем реально работали, какого масштаба нагрузки, кто писал SQL, кто катил в прод, пользовались ли профайлером и дебаггером, как работаете с AI-инструментами. Ответы «да, работал» без деталей на этом этапе стоят дороже всего: их проверят на техническом интервью, и расхождение прочитается как приукрашивание.

Рабочий каркас для любого поведенческого вопроса — STAR (Situation, Task, Action, Result), но с двумя поправками под инженерную специфику. Первая: в Action говорите своими глаголами первого лица единственного числа («я сделал», а не «мы сделали»), иначе непонятно, что делали лично вы. Вторая: в Result нужны числа или хотя бы порядок величин (p99 упал с 1.2 с до 180 мс; 40 инстансов вместо 120; релиз занимал 3 часа, стал 20 минут). Если чисел нет — назовите наблюдаемое последствие («перестали приходить ночные алерты по этой очереди»). Хорошая длина устного ответа — 60–120 секунд; дальше интервьюер сам задаст уточняющий вопрос, и это как раз то, чего вы хотите.

Третье. Часть вопросов в этом наборе — не вопросы к вам, а вопросы, которые кандидат задаёт компании («есть ли дежурства?», «какое годовое премирование?»). Их не надо «отвечать» — их надо уметь корректно задать и правильно разобрать ответ. Отдельный блок с такими вопросами есть ниже, после раздела Q&A.

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

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

Что входило в ваши обязанности на предыдущем проекте?

Коротко. Отвечайте не должностной инструкцией, а «зоной ответственности + типовым потоком работы»: за какие сервисы/домены вы отвечали, какую часть цикла закрывали сами (от постановки до прода и поддержки), и что делали регулярно. Формула: <роль и место в команде> → <за что отвечал единолично> → <что делал в общем потоке> → <что за пределами кода>.

Глубже. Каркас на 60–90 секунд, который стоит написать и отрепетировать:

Контекст. «Команда из <N> человек: <состав: бэкенд/фронт/QA/DevOps>, продукт — <что делает система, кто пользователь>, нагрузка — <RPS / объём данных / SLA>.»
Личная зона. «Я отвечал за <сервис(ы) / домен>: <что он делает>. Это значит: я вёл его от задачи до прода и разбирал по нему инциденты.»
Типовой цикл. «По задаче: уточнял требования у <аналитик/продакт>, декомпозировал, оценивал, писал код и тесты, отправлял в ревью, катил через <CI/CD>, смотрел <дашборды/алерты> после релиза.»
Сверх кода. «Плюс: код-ревью <сколько PR в неделю>, дежурства <формат>, <менторинг / собеседования / написание ADR / работа с алертами>.»
Дифференциатор. Одна вещь, которая была именно вашей: «отдельно я <вынес общую библиотеку X / перевёл сервис на Y / разобрал класс инцидентов Z>».

Что интервьюер считает сильным ответом: понятны границы ответственности, видно самостоятельность (не «мне давали таски»), есть масштаб в числах, названы не только фичи, но и эксплуатация. Что считается слабым: перечисление технологий вместо обязанностей («Go, Postgres, Kafka, Docker, k8s» — это стек, а не обязанности); ответ только в «мы»; отсутствие любого упоминания того, что происходило после мержа PR.

Отдельная ловушка — уровень. Junior описывает задачи, middle описывает сервисы, senior описывает решения и их последствия. Если претендуете на senior/lead, в ответе обязана быть хотя бы одна фраза про влияние за пределами своих задач: контракты между командами, стандарты, найм, разбор инцидентов, планирование.

Созвон с HR (с тех вопросами);

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

Глубже. На таком созвоне обычно спрашивают: сколько лет коммерческого Go и что было до него; какие версии/стек; какие БД и кто писал запросы; брокеры; Docker/Kubernetes — «пользовались» или «настраивали»; тестирование; английский; текущий процесс (Scrum/Kanban, размер команды, релизный цикл); ожидания по деньгам и формату работы. Технические вопросы на этом этапе поверхностные и закрытые: «работали ли с gRPC», «знаете, что такое горутина», «использовали ли контекст». Ошибка — отвечать на них развёрнутой лекцией: рекрутер не оценивает глубину, он сверяет чек-лист и следит за тем, чтобы вы не плавали в собственном резюме.

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

Финал с HR и лидами.

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

Глубже. К финалу готовьте три вещи. Первое — 3–4 отрепетированные истории по STAR, которые перекрывают большинство поведенческих вопросов: конфликт/разногласие в команде, сорванный или спасённый срок, ошибка в проде по вашей вине, ситуация, где вы что-то инициировали сами. Одна и та же история может обслуживать несколько вопросов, если менять акцент. Второе — внятная версия «почему уходите» и «почему сюда»: без критики бывшего работодателя, с формулировкой в терминах роста, а не бегства. Третье — свой список вопросов к команде (см. блок ниже); отсутствие вопросов на финале читается как отсутствие интереса и регулярно упоминается в фидбэках как минус.

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

Рассказ о себе и обязанностях.

Коротко. Стандартный открывающий блок: 2–3 минуты, структура «сейчас → путь → релевантный опыт → зачем я здесь». Это не биография, а сжатое доказательство соответствия вакансии.

Глубже. Каркас, который работает почти всегда:

Заголовок (1 фраза). «Бэкенд-разработчик на Go, <N> лет коммерческого опыта, последние <M> — в <домен: финтех / e-commerce / телеком / observability>.»
Настоящее (30–40 с). Текущая компания, продукт, ваша зона, масштаб в числах. Это самая важная часть — сюда интервьюер будет возвращаться.
Путь (20–30 с). Только опорные точки: как пришли в бэкенд, почему Go, какой был предыдущий стек. Без школы и первых курсов, если это не первая работа.
Два-три сильных пункта. «Из релевантного вашей вакансии: <X>, <Y>, <Z>» — подбирается под текст вакансии, а не рассказывается одинаково везде.
Переход. «Сейчас ищу <что именно: масштаб / продуктовую разработку / больше архитектурной ответственности>, поэтому откликнулся к вам.»

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

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

Несколько behavioral вопросов;

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

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

Каркас для каждой: S — 1–2 предложения контекста (что за система, кто участники, почему это было важно); T — что конкретно нужно было получить и в каких ограничениях (срок, люди, риск); A — 3–5 ваших действий подряд, от первого лица, с указанием альтернатив, которые вы рассмотрели и отбросили; R — измеримый или наблюдаемый исход плюс что вы из этого вынесли и что делаете иначе теперь.

Три правила, которые отличают сильный поведенческий ответ. Первое: история должна быть настоящей и вашей — интервьюеры на уточняющих вопросах («а как отреагировал тот коллега?», «а почему не сделали проще?») мгновенно ловят сконструированные сюжеты. Второе: в истории про конфликт или ошибку не должно быть героя и злодея; ответ «я был прав, а они не поняли» закрывает вопрос не в вашу пользу. Третье: рефлексия обязательна — на вопрос про факап без ответа «что я изменил в своей работе после» история засчитывается как незакрытая.

Какими LLM-инструментами пользуешься? Что получается, что нет?

Коротко. Отвечайте конкретно и с границами: назовите инструменты, назовите классы задач, где они реально экономят время, и честно — где ломаются. Вопрос проверяет не лояльность к AI, а инженерную зрелость: понимаете ли вы, что за сгенерированный код отвечаете вы.

Глубже. Каркас ответа: <чем пользуюсь> → <как встроено в рабочий цикл> → <где выигрыш> → <где не работает и что делаю вместо> → <как проверяю результат> → <политика компании по данным>.

Инструменты, которые реально встречаются в ответах Go-разработчиков в 2025–2026: Claude Code, Cursor, GitHub Copilot, JetBrains AI Assistant в GoLand, ChatGPT/Claude в вебе, локальные модели через Ollama там, где нельзя отправлять код наружу. Называйте только то, чем пользовались.

Где обычно получается: бойлерплейт (структуры под JSON/протобуф, повторяющиеся хендлеры, моки, конверторы между слоями), первый черновик табличных тестов, разбор незнакомой кодовой базы («объясни, что делает этот пакет»), перевод и вычитка текста, регулярки и однострочники на bash/jq, ускорение работы с незнакомой библиотекой, генерация SQL-миграций по описанию, ускоренное чтение чужих PR.

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

Как проверяю: компиляция и go vet, тесты (написанные мной, а не сгенерированные под тот же код), go test -race для всего конкурентного, линтеры, чтение диффа целиком перед коммитом, никогда не отправляю в ревью то, что не могу объяснить построчно. Плюс организационное: не отправляю в облачные модели код и данные, если это запрещено политикой компании.

Сильный ответ звучит как «инструмент ускоряет мне рутину процентов на <X>, но ответственность за код остаётся моей, и вот конкретные места, где я ему не доверяю». Провальные варианты — оба края: «не пользуюсь, это игрушки» (читается как негибкость) и «пишу всё через AI, почти не проверяю» (читается как риск).

Сначала кратко про свой опыт спросили, потом гоняли по разным вопросам;

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

Глубже. Это управляемо, и этим стоит пользоваться. Всё, что вы упомянули в самопрезентации, становится легальной мишенью: сказали «Kafka» — спросят про партиции, ребаланс, идемпотентность и exactly-once; сказали «оптимизировал» — спросят, чем мерили и что показал профиль; сказали «Kubernetes» — спросят про probes, ресурсы и graceful shutdown. Поэтому упоминайте только то, по чему готовы к трём уровням уточнений, и наоборот — сознательно вставляйте якоря на темы, которые знаете глубоко.

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

Есть ли дежурства?

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

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

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

Пользуешься ли дебаггером?

Коротко. Да — и назовите чем: Delve (dlv) напрямую или через GoLand/VS Code, включая dlv attach к запущенному процессу и dlv test для отладки тестов. Полезно добавить, что дебаггер — один из инструментов, и рядом стоят логи, go test -race, профайлер и runtime/trace.

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

Что стоит упомянуть как признак опыта: условные точки останова и точки с логированием вместо остановки; отладка тестов (dlv test ./pkg/... -- -test.run TestX); подключение к процессу в контейнере через dlv --headless --listen=:2345 --api-version=2 attach <pid>; необходимость собирать бинарь с -gcflags="all=-N -l" — без отключения инлайнинга и оптимизаций отладка «прыгает» по строкам; ограничения при отладке горутин и то, что дебаггер не заменяет -race; для утечек и зависаний — net/http/pprof (/debug/pprof/goroutine?debug=2) даёт стеки всех горутин быстрее, чем пошаговая отладка.

// в проде вместо брейкпоинтов чаще спасает это:
import _ "net/http/pprof"

// go tool pprof http://localhost:6060/debug/pprof/heap
// curl 'http://localhost:6060/debug/pprof/goroutine?debug=2'   // стеки всех горутин

Ответ «дебаггером не пользуюсь, хватает логов» проходит, если объяснить почему (например, распределённая система, где важнее трассировка), но безоговорочное «не умею» на middle+ читается как пробел в базовой гигиене.

Проводили ли вы код-ревью?

Коротко. Отвечайте цифрой и процессом: сколько PR в неделю смотрели, обязательно ли ревью для мержа, сколько апрувов требовалось, на что смотрели в первую очередь. Вопрос проверяет и вовлечённость в командные процессы, и умение давать обратную связь без конфликта.

Глубже. Каркас: <объём и формат> → <на что смотрю по порядку> → <как формулирую замечания> → <как разрешаю споры> → <что автоматизировано>.

Порядок проверки, который звучит убедительно: сначала — решает ли PR заявленную задачу и туда ли положен код (границы пакетов, слои); потом — контракт и обратная совместимость (публичные API, схема БД, формат событий); потом — корректность в опасных местах (обработка ошибок и их оборачивание, context и таймауты, конкурентность и возможные гонки, транзакции и идемпотентность, границы запросов к БД, N+1); потом — тесты: покрыт ли новый путь и негативные сценарии; и только в конце — стиль, именование, читаемость. Всё, что проверяется автоматически (форматирование, go vet, golangci-lint, покрытие), должно проверяться CI, а не человеком в комментариях — это отдельный плюс к ответу.

Про формулировки: разделяйте блокирующие замечания и пожелания (префиксы вида blocker: / nit: / question:), пишите про код, а не про автора, объясняйте «почему», предлагайте альтернативу, а не только диагноз. Если спор затянулся на 2–3 круга комментариев — переводите в 10-минутный созвон; если разногласие принципиальное и не сходится — фиксируйте позиции и эскалируйте к лиду/архитектору, не блокируя PR неделями. Полезно упомянуть размер PR: ревью крупного диффа деградирует, и требование «дели на части» — часть культуры ревью.

Если ревью в вашей практике не было, честно скажите так и добавьте, что вас ревьюили и что вы из этого вынесли — это лучше, чем натягивать опыт.

Использовали ли вы AI при кодировании? Для каких задач? Как проверяли результат?

Коротко. См. выше про LLM-инструменты. Отличие этого вопроса — акцент на третьей части: проверка. Отвечая, отдайте примерно треть времени задачам и две трети — тому, как вы валидируете сгенерированный код и где вы его не применяете.

Глубже. Развёрнутая схема проверки, которую стоит проговорить явно: (1) читаю диффа целиком и не коммичу то, что не могу объяснить; (2) компиляция + go vet + golangci-lint; (3) тесты — причём тесты пишу или как минимум продумываю сам, потому что модель, сгенерировавшая код, склонна сгенерировать тесты, которые повторяют её же ошибочные допущения; (4) go test -race обязательно, если тронута конкурентность; (5) для производительности — бенчмарк или профиль, а не «выглядит быстрее»; (6) сверяюсь с официальной документацией пакета, когда модель предлагает незнакомый API — галлюцинации сигнатур встречаются регулярно; (7) обычное код-ревью коллегой — сгенерированный код проходит его на общих основаниях, и в описании PR я не скрываю, что часть написана с помощью AI.

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

На каком уровне вы владеете английским? Как читаете техническую документацию, участвуете в созвонах, пишете комментарии к коду?

Коротко. Называйте уровень по CEFR и сразу разбивайте по навыкам, потому что у разработчиков они почти всегда разные: чтение выше, речь ниже. Формула: <чтение — свободно/со словарём>, <письмо — какое>, <speaking — какой реальный опыт>, <listening — понимаю ли живые созвоны и акценты>.

Глубже. Ориентиры уровней, чтобы не завышать: A2 — читаете со словарём, говорить не можете; B1 — читаете документацию, письменно переписываетесь, устно с трудом и с подготовкой; B2 — участвуете в рабочих созвонах, можете объяснить решение, ошибки не мешают пониманию; C1 — свободно ведёте обсуждение, спорите, проводите демо. Завышать опасно: во многих компаниях есть отдельная секция или как минимум пара вопросов на английском прямо на интервью, и разрыв между заявленным B2 и реальным A2 стоит оффера.

По подпунктам вопроса отвечайте предметно: документация — читаю в оригинале, включая исходники и issue-треды на GitHub, русские переводы не использую (это стандартное ожидание для Go, где вся первичная документация английская); созвоны — <есть ли реальный опыт: ежедневные стендапы с носителями / переписка с вендором / нет опыта>; комментарии и коммиты — <на каком языке было принято в команде>; в Go-проектах комментарии к экспортируемым идентификаторам почти всегда пишут по-английски в формате // FuncName does X., и это стоит упомянуть; переписка — issues, PR-описания, поддержка внешних библиотек.

Если английский слабый, скажите прямо и добавьте, что делаете: <курс / регулярные занятия / чтение документации ежедневно>. Честный B1 с планом лучше, чем заявленный C1, который развалится на первом же уточняющем вопросе, заданном по-английски.

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

Коротко. Вопрос про системность самообучения, а не про эрудицию. Сильный ответ = 3–5 конкретных источников + как это доходит до практики (пет-проект, внедрение на работе, доклад команде) + один свежий пример того, что вы недавно узнали и применили.

Глубже. Конкретика, которая звучит достоверно для Go-разработчика: официальный блог go.dev/blog и release notes к каждой версии (это самый сильный ответ — по release notes видно, что человек реально следит за языком); go.dev/doc/effective_go и раздел Go Wiki; рассылки Golang Weekly и Go Newsletter; конференции — GopherCon, а из русскоязычных GolangConf/HighLoad++; подкасты и YouTube-каналы; чтение исходников стандартной библиотеки и предложений в репозитории golang/go (папка design, обсуждения в issues); Reddit r/golang и Gophers Slack; книги и статьи по смежным темам (Kleppmann по данным, документация PostgreSQL, Kafka docs).

Не перечисляйте всё подряд — назовите то, чем реально пользуетесь, и обязательно приведите пример. Хороший пример со свежими версиями Go: изменение семантики переменной цикла в Go 1.22 (каждая итерация получает свою переменную — это убрало классический баг с захватом переменной в замыкании и в горутине), переход map на реализацию в духе Swiss Tables в Go 1.24 с уменьшением накладных расходов, появление math/rand/v2, инструмент go tool и директива tool в go.mod (Go 1.24), генерация тестовых итераторов и пакет iter с range-over-func (Go 1.23). Достаточно одного пункта, но рассказанного точно: «в 1.22 поменяли семантику переменной цикла, поэтому мы смогли убрать из кодовой базы конструкции x := x перед запуском горутины» — это доказывает, что чтение release notes доходит до кода.

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

Расскажи подробнее про каждый. В каких сиутациях использовал?

Коротко. Это follow-up-вопрос: интервьюер берёт список, который вы только что перечислили (инструменты, технологии, источники), и просит развернуть каждый пункт с привязкой к ситуации. Проверяется ровно одно — стоял ли за перечислением реальный опыт.

Глубже. Формат ответа на каждый пункт — три предложения: что это и зачем нужно (одна фраза своими словами, не из документации) → конкретная ситуация: <какая задача / какая проблема> → что получилось и чем это лучше альтернативы, которую вы рассматривали. Если по какому-то пункту опыт слабый — скажите об этом прямо на этом же пункте («пробовал на пет-проекте, в проде не применял») и переходите дальше; попытка растянуть три знакомых слова на минуту заметна мгновенно.

Практический вывод, который надо усвоить до интервью: не перечисляйте то, что не готовы развернуть. Каждое слово в вашем списке — это заявка на follow-up. Лучше назвать три инструмента и рассказать про каждый предметно, чем восемь и посыпаться на пятом. И держите порядок: отвечайте по пунктам в том же порядке, в каком перечисляли, — это выглядит как структурное мышление и не даёт интервьюеру ощущения, что вы уходите от неудобных пунктов.

Какие негативные вещи ты бы не хотел видеть на рабочем месте?

Коротко. Называйте не людей и не эмоции, а процессы: 2–3 конкретных антипаттерна, каждый — с пояснением, почему он мешает делать работу, и с тем, как вы на него реагируете. Вопрос проверяет ваши границы и заодно то, не станете ли вы источником токсичности сами.

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

Каркас на каждый пункт: <что именно> + <почему это ломает работу, а не «мне неприятно»> + <как я реагирую: сначала обсуждаю с лидом / предлагаю изменение процесса / принимаю как временное, если есть причина и срок>. Последняя часть — самая важная: она отличает взрослую позицию от списка претензий.

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

Хорошее завершение — перевернуть вопрос в позитив одной фразой: «а что мне важно видеть — <понятные приоритеты / нормальное ревью / возможность спорить по технике>». И задать встречный вопрос о том, как это устроено у них.

Бывали ли случаи, когда переоценил задачи?

Коротко. Да — и здесь важно уточнить, о чём речь: переоценка (заложил больше времени, чем нужно) и недооценка (не уложился) проверяют разное. Отвечайте честной историей по STAR и обязательно закончите тем, как изменился ваш способ оценивать.

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

Что считается сильным финалом: конкретный метод, а не декларация «стал внимательнее». Например: декомпозирую на подзадачи не крупнее одного дня и оцениваю их, а не целое; даю диапазон (оптимистично/реалистично/пессимистично) вместо одной цифры; отдельной строкой закладываю тесты, ревью, миграции и выкатку; перед оценкой трачу таймбокс (<час-два>) на разведку кода и только потом называю срок; фиксирую допущения вслух («оцениваю при условии, что API смежников уже готов»); при первом же признаке отклонения сообщаю сразу, а не в день дедлайна; сверяю оценки с фактом ретроспективно, чтобы видеть свой систематический коэффициент.

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

Что если стоит жесткий дедлайн и надо успеть доделать фичу до пятницы без вариантов?

Коротко. Проверяют, умеете ли вы управлять объёмом вместо того, чтобы молча героически перерабатывать. Правильный скелет: как можно раньше сообщаю о риске → предлагаю варианты сокращения scope → фиксирую, что именно урезано и когда доделаем → выкатываю безопасно (флаг/поэтапно) → после релиза возвращаю технический долг в план.

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

Что не режем ни при каком дедлайне: необратимые вещи. Схема БД и миграции, формат внешнего контракта, обработка денег/платежей, безопасность и доступы, логирование и метрики, необходимые для разбора инцидента. Резать можно UI-полировку, редкие сценарии, автоматизацию административных операций, часть оптимизаций, объём тестов на некритичных путях — но каждый такой срез должен быть записан в задачу с датой возврата, иначе это не компромисс, а тихое накопление долга.

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

Провальные ответы: «буду работать ночами, но сделаю» (обещает выгорание и не решает системную проблему) и «дедлайн нереальный — значит, не сделаю» (снимает с себя ответственность за поиск варианта).

Какой идеальный руководитель для тебя?

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

Глубже. Каркас из 3–4 пунктов, каждый — с пояснением «зачем мне это в работе»:

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

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

Чего избегать: «идеальный — который не мешает» (звучит как неготовность к взаимодействию); «который всегда со мной согласен»; критики прошлых руководителей; и другой крайности — «мне нужен наставник, который всё объяснит», если вы претендуете на senior.

Что если попался сложный кусок кода, в котором невозможно разобраться, что делать?

Коротко. Ответ должен показать метод и таймбокс: сначала самостоятельно и системно (наблюдение, а не чтение подряд), с ограничением по времени; если не сдвинулось — иду к автору или к тому, кто владеет доменом, с конкретным вопросом и списком уже проверенного; итог фиксирую в документации/комментариях, чтобы следующий человек не проходил тот же путь.

Глубже. Разверните метод по шагам — именно это отличает сильный ответ от «спрошу коллегу»:

Определить цель. Мне нужно понять весь кусок или только поведение на моём сценарии? Чаще второе, и это резко сокращает задачу.
Смотреть снаружи внутрь. Кто вызывает, какие входы/выходы, какие сайд-эффекты (БД, очередь, файлы). Тесты — лучшая документация: если их нет, пишу характеризационный тест, который фиксирует текущее поведение на реальных данных.
Наблюдать, а не угадывать. Дебаггер (dlv), временное логирование, трассировка, go tool pprof/trace, если вопрос в производительности или зависании.
История. git log -p, git blame — и не столько ради автора, сколько ради коммит-сообщений, тикетов и причин: почти всегда странный код — это застывший баг-фикс или требование, которого больше нет в голове ни у кого.
Записывать по ходу. Схема потока, список инвариантов, вопросы. Через час это станет заметкой в README или ADR.
Таймбокс и эскалация. «Копаю <полдня / до конца дня>, дальше иду к <автору / владельцу домена / лиду> с готовым вопросом: вот что делает код по моим наблюдениям, вот что не сходится, вот две гипотезы.»
Не переписывать сходу. Соблазн «проще переписать» почти всегда обманчив: в непонятном коде обычно живут неочевидные требования. Сначала тесты, фиксирующие поведение, потом изменение маленькими шагами.

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

Какое у вас годовое премирование?

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

Глубже. Что именно спрашивать: (1) какая часть дохода фиксированная, а какая переменная (в процентах от годового); (2) на чём основан бонус — личные цели, результат команды, финансовый результат компании, или сочетание; (3) кто и как ставит цели, можно ли увидеть пример; (4) периодичность — годовой, полугодовой, квартальный; (5) исторический факт: «за прошлый год бонус выплатили в полном объёме?» — самый информативный вопрос, потому что схема на бумаге и практика расходятся часто; (6) есть ли требование быть в штате на дату выплаты; (7) индексация и пересмотр оклада — как часто, по какому процессу; (8) есть ли отдельные премии за дежурства, переработки, найм (реферальные), участие в собеседованиях.

Формулировка, которая не звучит меркантильно: «Хочу правильно сравнить предложения — подскажите, как устроена переменная часть: от чего зависит, когда выплачивается и как это работало по факту в прошлом году?» Важно: не задавайте этот вопрос на первом техническом интервью — там его задают HR, и уместнее вернуть его им. И считайте total compensation целиком: оклад × 12 + бонус + ДМС + компенсации (обучение, техника, спорт) + опционы, если они есть, с обязательным уточнением условий вестинга.

Как вы относитесь к девопс-задачам?

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

Глубже. Вопрос почти всегда задают, когда в вакансии есть реальная доля инфраструктурной работы, и хотят понять две вещи: не убежите ли вы через три месяца и какой уровень самостоятельности можно на вас положить. Полезно разложить по слоям.

Что для бэкендера на Go считается нормальным «своим»: Dockerfile (multi-stage, минимальный образ, distroless/scratch), сборка и CI-пайплайн (GitLab CI/GitHub Actions: линт, тесты, -race, сборка, публикация образа), манифесты Kubernetes или Helm-чарт своего сервиса — probes (liveness/readiness/startup), requests/limits, graceful shutdown по SIGTERM, конфигурация через env/секреты; observability — метрики Prometheus, структурные логи (log/slog начиная с Go 1.21), трассировка OpenTelemetry, дашборды Grafana и алерты на свой сервис; работа с миграциями БД в пайплайне.

Что обычно уже зона платформенной команды: сам кластер, сеть и ingress-контроллер, service mesh, хранилища, стоимость и capacity, IaC на Terraform уровня инфраструктуры. Здесь честная формулировка «читаю и правлю чужой Terraform по образцу, но проектировать инфраструктуру с нуля не приходилось» лучше расплывчатого «работал с Terraform».

Каркас ответа: <принцип: you build it, you run it — сервис мой до прода и в проде> → <что делаю сам, с примерами> → <где граница и с кем работаю в паре> → <чему хочу научиться> → встречный вопрос: «а какая доля таких задач ожидается в этой роли?» Последнее особенно важно: если окажется, что «девопс-задачи» — это 60% времени, лучше узнать это до оффера.

Пользовался Jira или аналогами? Насколько активно?

Коротко. Да, и отвечайте через процесс, а не через кнопки: какой методологией жили (Scrum/Kanban), как задача проходила путь от постановки до закрытия, что делали лично вы — заводили ли задачи, декомпозировали, оценивали, вели ли доску, писали ли постановки и критерии приёмки.

Глубже. Каркас: <инструмент: Jira / YouTrack / Redmine / GitLab Issues / Linear / Trello / Kaiten> → <процесс: спринты по N недель, груминг, планирование, ретро / Kanban с лимитами WIP> → <моя роль в трекере> → <связка с кодом> → <что считаю полезным, а что бюрократией>.

Детали, которые показывают реальную включённость: статусы и переходы, которыми вы пользовались; декомпозиция эпик → стори → сабтаск; оценка в стори-поинтах или часах и участие в покере планирования; описание Definition of Ready / Definition of Done и критериев приёмки; связка веток и коммитов с номером задачи (feat: PROJ-123 ...), автоматический переход задачи в «на ревью» при открытии MR; фильтры и JQL, если вы правда ими пользовались; дашборды и burndown; работа с багами и приоритетами; заведение технического долга отдельными задачами, чтобы он был виден в планировании.

Сильный ответ добавляет позицию: трекер полезен как общая память команды и способ не потерять контекст (особенно для легаси — «почему так сделано» часто находится именно в задаче), но превращается во вред, когда в нём заводят по пять статусов на каждую мелочь и требуют почасовых списаний. Формулируйте это спокойно: «пользуюсь активно, комментирую ход работы, чтобы не пересказывать статус на каждом стендапе; из бюрократии не люблю <X>, но если это принято в команде — делаю».

Если опыта с трекерами не было (только доска в Notion/таблица) — так и скажите, добавив, что инструмент осваивается за день, а важен процесс. Проблема этого ответа не в незнании Jira, а в риске, что человек не работал в командном процессе вообще.

Что спросить самому в конце интервью

Отсутствие вопросов от кандидата — регулярный минус в фидбэке. Подготовьте 5–7, задайте 3–4 (остальное — на следующий этап), выбирайте адресно: технические — лиду, процессные — менеджеру, про деньги и оформление — HR.

Про команду и людей

Сколько человек в команде и какой состав: бэкенд, фронтенд, QA, аналитик, DevOps? Есть ли выделенный тимлид и техлид?
Это новая команда или замена ушедшего человека? Если замена — что не сложилось у предшественника?
Какой опыт у людей в команде — на кого можно опереться в первые месяцы?
Как принимаются технические решения: единолично лидом, консенсусом, через ADR/RFC? Что происходит, если я не согласен?
Как часто бывают 1:1 и в каком виде даётся обратная связь?

Про процессы и разработку

Scrum или Kanban, какая длина спринта, кто ставит задачи и приоритеты? Кто пишет постановки и есть ли критерии приёмки?
Как выглядит путь задачи от идеи до прода? Сколько времени в среднем проходит от мержа до релиза?
Как устроено код-ревью: обязательно ли, сколько апрувов, какой типичный размер PR, сколько времени PR ждёт ревью?
Что в CI: линтеры, тесты, -race, интеграционные тесты? Какое покрытие и есть ли к нему требования?
Как выкатываете: canary, blue-green, фича-флаги? Как быстро можно откатиться?
Есть ли тестовые окружения и как в них попадают данные?

Про кодовую базу и легаси

Сколько лет проекту, какие версии Go, есть ли сервисы на других языках?
Какая доля времени уходит на новую функциональность, а какая — на поддержку и легаси? (Ответ «легаси нет» — либо очень молодой проект, либо неточность.)
Какая самая большая техническая боль прямо сейчас и есть ли план с ней что-то делать? Как технический долг попадает в спринт?
Есть ли документация и ADR? Как новый человек разбирается в системе?
Какие нагрузки, объёмы данных, SLA? Что чаще всего ломается?

Про дежурства и эксплуатацию

Есть ли дежурства, как устроена ротация и сколько людей в ней? Оплачиваются ли они или компенсируются отгулами?
Сколько ночных срабатываний было за последний месяц по факту? Много ли шумных алертов?
Есть ли runbook по типовым инцидентам и на кого можно эскалировать ночью?
Обязателен ли постмортем и практикуется ли безобвинительный (blameless) разбор?
Кто чинит первопричину алерта — дежурный или владелец сервиса?

Про испытательный срок и ожидания

Какова длительность испытательного срока и по каким критериям принимается решение? Есть ли формальный чек-лист?
Что должно произойти за первые 1–3 месяца, чтобы вы сказали «взяли правильного человека»? Что считается провалом?
Как устроен онбординг: есть ли бадди/ментор, за сколько обычно человек катит первую задачу в прод, есть ли доступ к окружениям с первого дня?
Будет ли промежуточная обратная связь до конца испытательного срока или только в конце?
Что дальше после испытательного: как устроен пересмотр зарплаты, грейды, есть ли карьерная матрица?

Финальный процедурный вопрос — всегда задавайте его последним: сколько ещё этапов, в какие сроки ждать ответ и в каком виде будет обратная связь при отказе.

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

Отвечать на «расскажите об обязанностях» перечислением стека вместо зоны ответственности и типового рабочего цикла; говорить только «мы» и не показывать личный вклад.
Давать поведенческие ответы без результата и без выводов: история заканчивается на «в итоге сделали», без цифр и без «что я поменял в своей работе после этого».
Упоминать в самопрезентации технологии, по которым не готов к трём уточняющим вопросам, — весь дальнейший разговор строится именно по этому списку.
Завышать уровень английского: заявленный B2/C1 проверяется прямо на месте, а расхождение бьёт по доверию ко всем остальным ответам.
На вопрос про AI-инструменты уходить в крайности — «не пользуюсь, это игрушки» или «пишу всё через AI» — вместо описания конкретных задач, границ применимости и процедуры проверки сгенерированного кода.
На вопрос про жёсткий дедлайн обещать переработки вместо управления объёмом; резать необратимые вещи (схема БД, контракты, безопасность, логи и метрики) вместо откладываемых.
Отвечать «нет» на вопрос о переоценке сроков и ошибках — это не бывает правдой и читается как отсутствие рефлексии.
На вопрос про непонятный код говорить «буду разбираться сколько нужно» (нет таймбокса) или «сразу спрошу автора» (нет самостоятельности); не упоминать тесты, фиксирующие текущее поведение, и запись выводов в документацию.
Ругать бывших коллег, руководителей и «ужасное легаси» — легаси есть везде, и такой ответ читают как нежелание делать половину реальной работы.
Приходить на финал без единого вопроса к команде и не уточнять дежурства, испытательный срок и структуру бонуса до подписания оффера.
Придумывать личные истории: интервьюер разбирает их уточняющими вопросами («а как отреагировал коллега?», «почему не сделали проще?»), и сконструированный сюжет разваливается быстрее, чем честное «такого опыта не было, но действовал бы так».

Что почитать

Go Release Notes — https://go.dev/doc/devel/release — минимальный обязательный источник для ответа на вопрос «как следите за новинками»; смотрите заметки к 1.22 (семантика переменной цикла), 1.23 (iter, range-over-func), 1.24 (tool в go.mod, новая реализация map).
Delve — https://github.com/go-delve/delve/tree/master/Documentation — команды dlv debug/test/attach, условные брейкпоинты, headless-режим для отладки в контейнере.
Google Engineering Practices: Code Review Developer Guide — https://google.github.io/eng-practices/review/ — лучший источник формулировок для вопроса про код-ревью (что смотреть, как писать замечания, как разрешать споры).
Google SRE Book, главы «Being On-Call» и «Postmortem Culture» — https://sre.google/sre-book/table-of-contents/ — язык, на котором стоит обсуждать дежурства, эскалацию и разборы инцидентов.
Effective Go и Go Code Review Comments — https://go.dev/doc/effective_go, https://go.dev/wiki/CodeReviewComments — то, на что имеет смысл ссылаться, объясняя свои критерии на ревью.
CEFR self-assessment grid (Council of Europe) — для честной калибровки уровня английского по навыкам чтения, письма, речи и восприятия на слух.