Мотивация и ожидания

Кратко о теме

Весь блок «мотивация» — это три вопроса, замаскированные под двадцать: почему ты уходишь, почему к нам и куда ты идёшь дальше. Интервьюер (HR или нанимающий менеджер) не проверяет «правильность» твоих ценностей — он проверяет две вещи. Первая: согласованность. Причина ухода, критерии выбора нового места, планы на 1–3 года и вопросы, которые ты задаёшь в конце, должны складываться в одну историю. Если человек говорит «ухожу за сложными задачами», а потом спрашивает только про переработки и грейды, история рассыпается, и это фиксируется как красный флаг быстрее любой технической ошибки. Вторая: риск оттока. Компания платит за найм и онбординг 3–6 месяцев, и её интересует, не уйдёшь ли ты через полгода по той же причине, по которой уходишь сейчас. Поэтому лучший ответ всегда содержит проверяемое условие: «мне важно X, у вас, насколько я понял, X есть — правильно?».

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

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

Зарплатные переговоры — часть того же блока, потому что вопрос «ваши ожидания?» почти всегда прилетает в конце HR-скрининга. Базовая рамка: вилку первым по возможности называет работодатель, но упираться в это до конфликта не стоит — на российском рынке HR обычно спрашивает первым, и жёсткий отказ отвечать читается как игра. Практичная стратегия — сначала вежливо вернуть вопрос («у вас наверняка есть вилка по грейду — назовите её, и я скажу, попадаю ли»), а если вилку не называют, дать не точку, а диапазон, нижняя граница которого — это сумма, за которую ты реально готов выйти, потому что дальше торг пойдёт от неё вниз, а не вверх. Диапазон обосновывается рынком и грейдом, а не личными нуждами: ипотека и расходы — не аргумент в переговорах, уровень задач и текущие офферы — аргумент. Сумму всегда называй как total: оклад gross, отдельно бонус/премия, отдельно опцион, отдельно ДМС и техника — иначе на этапе оффера окажется, что «вилка совпала», но половина суммы была квартальной премией по KPI.

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

Почему на проекте выбрали RabbitMQ, а не другую брокерскую систему?

Коротко. Вопрос про личный проект, поэтому конкретику придумывать нельзя — интервьюер проверяет, понимаешь ли ты, что выбор брокера это trade-off под нагрузку и модель доставки, а не «мы взяли то, что знали». Сильный ответ: назвать 2–3 требования проекта (объём, нужна ли реплейка истории, сложность роутинга, порядок сообщений) и показать, как из них следует именно RabbitMQ.

Глубже. Каркас: «У нас было <характер трафика: N сообщений/сек, всплески/ровный поток>. Ключевые требования: <нужна ли гарантия порядка, нужен ли повторный проигрыш истории, сложный ли роутинг, нужны ли отложенные сообщения и retry>. Kafka мы не взяли, потому что <причина>, NATS/Redis Streams — потому что <причина>. RabbitMQ закрыл <конкретные потребности>». Фактическая база, на которую опираются такие ответы: RabbitMQ — это брокер очередей с гибким роутингом (exchange типов direct/topic/fanout/headers), подтверждением каждого сообщения (ack/nack), dead-letter exchange под retry, per-message TTL, prefetch для управления нагрузкой на консьюмера; данные из очереди после ack исчезают, «перечитать вчерашний день» нельзя. Kafka — распределённый лог: сообщения хранятся по retention, читаются по offset, есть реплей и гарантия порядка внутри партиции, пропускная способность выше, но роутинг примитивный (топик + ключ партиционирования), а retry/DLQ надо строить руками. То есть типичное честное обоснование выбора RabbitMQ звучит как «нам нужны были task queue с ack на сообщение, DLQ и разный роутинг по типам событий, а не аналитический поток с реплеем» — и наоборот. Что нельзя говорить: «RabbitMQ быстрее Kafka» (неверно на больших объёмах), «Kafka сложная» без деталей, и «выбирал не я, не знаю» без продолжения — если решение принимал архитектор, скажи это прямо, но добавь, какие аргументы звучали при выборе.

Атомики: для чего нужны? Почему x++ вызывает гонку?

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

Глубже. Технически гонка тут двойная: помимо потери обновления, у неатомарного доступа нет ordering-гарантий, и компилятор с процессором вправе переупорядочить или закешировать значение в регистре — цикл for !done {} без синхронизации может не завершиться никогда. Модель памяти Go (go.dev/ref/mem) прямо объявляет программу с гонкой данных некорректной, а не «иногда неправильной». С Go 1.19 в sync/atomic есть типы atomic.Int64, atomic.Bool, atomic.Pointer[T] — их стоит предпочитать функциям вида atomic.AddInt64(&x, 1): тип не даёт случайно обратиться к полю неатомарно и сам решает проблему выравнивания на 32-битных платформах. Проверять гонки — go test -race / go build -race, детектор ловит только те гонки, которые реально произошли во время выполнения, поэтому нужны нагрузочные тесты.

package main

import (
  "sync"
  "sync/atomic"
)

func main() {
  var bad int64
  var good atomic.Int64
  var wg sync.WaitGroup
  for i := 0; i < 1000; i++ {
    wg.Add(1)
    go func() {
      defer wg.Done()
      bad++          // гонка: load-add-store не атомарны
      good.Add(1)    // корректно: одна атомарная RMW-операция
    }()
  }
  wg.Wait()
  // bad почти наверняка < 1000, good == 1000
}

Отдельно стоит сказать границу применимости: атомик защищает одну переменную, а не инвариант между несколькими. Если надо согласованно менять два поля или проверять условие перед изменением — это мьютекс или CompareAndSwap в цикле, а не набор независимых атомиков.

По какой причине вы покинули эту компанию?

Коротко. Проверяют не причину как таковую, а то, умеешь ли ты говорить о конфликте/неудаче без обвинений и делаешь ли выводы. Сильный ответ — одна ясная профессиональная причина, признание того, что ты пробовал изменить ситуацию изнутри, и переход к тому, что ищешь дальше; 3–4 предложения, без списка обид.

Глубже. Каркас с плейсхолдерами: «Я проработал там <срок>, отвечал за <зона ответственности>. Основная причина ухода — <структурный факт: проект законсервировали / команду сократили / стек и задачи перестали меняться / роль упёрлась в потолок / переезд-релокация-смена формата>. Я пробовал <что конкретно делал: просил другие задачи, инициировал X, обсуждал с руководителем рост>, это дало <результат>, но <почему структурно не решилось>. Поэтому решил искать место, где <критерий>». Что говорить нельзя: имена и характеристики людей («тимлид был токсичный»), деньги как единственную причину (даже если это правда — деньги идут вторым пунктом после содержательной причины, иначе ты уйдёшь за +10% от них же), жалобы на «легаси» и «бардак» без описания того, что ты с этим делал, и любые NDA-детали и внутренние цифры бывшего работодателя — их разглашение читается как прямой сигнал, что ты так же будешь рассказывать о них. Отдельный случай — увольнение не по своей воле или конфликт: врать не нужно, работает короткая фактическая формулировка + вывод («расстались по инициативе компании при сокращении отдела; выводы для себя сделал такие-то»). Если причина ухода деликатная (выгорание, конфликт с руководителем), сведи её к нейтральному описанию условий и не углубляйся: подробности здесь работают против кандидата, а не на честность.

Как вы относитесь к Linux? Какой дистрибутив используете на работе и лично? Почему выбрали именно его?

Коротко. Проверяют, живёшь ли ты в Linux каждый день или только через Docker Desktop, и есть ли за выбором инструмента осмысленная причина. Сильный ответ — назвать реальный дистрибутив, коротко обосновать выбор одним практическим аргументом и показать, что ты понимаешь, чем дистрибутивы отличаются между собой.

Глубже. Свой ответ подставляй сам, каркас: «На рабочей машине <дистрибутив/или macOS + Linux в контейнерах и на серверах>, дома <дистрибутив>. Выбрал из-за <причина>. На проде у нас <что>». Фактура, чтобы обоснование звучало осмысленно: Debian/Ubuntu LTS — предсказуемые релизы, самый широкий охват документации и пакетов, поэтому это де-факто база большинства Docker-образов; RHEL/CentOS Stream/Alma/Rocky — корпоративный контур, SELinux, длинный цикл поддержки; Arch — rolling release, свежие пакеты ценой ручного сопровождения; Alpine — musl вместо glibc и крошечный размер образа, из-за чего для Go-сервисов важен нюанс: cgo-сборка под glibc в Alpine не запустится, а CGO_ENABLED=0 статический бинарь запустится хоть в scratch, плюс в Alpine нет по умолчанию корневых сертификатов (ca-certificates) и DNS-резолвинг идёт через musl. Что не стоит делать: спорить о превосходстве дистрибутива, отвечать «мне без разницы, я в WSL» без продолжения (нормальный ответ — «работаю в WSL2/macOS, но прод у нас Linux, знаю systemd, journalctl, strace, ss»). Если ты реально мало работал с Linux напрямую — честно скажи и назови то, чем пользуешься уверенно (ps, top/htop, ss, lsof, journalctl, dmesg, perf); попытка изобразить опыт вскрывается следующим же вопросом.

Как пришел к Go и почему выбрал его?

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

Глубже. Каркас: «Пришёл из <язык/область>, попал на Go на <проект/задача>. Сначала <первое впечатление, можно и негативное — это честно>. Остался, потому что <конкретика>». Аргументы, которые звучат профессионально и проверяемы: быстрая компиляция и один статический бинарь без рантайма — простой деплой в контейнер; горутины и каналы дают конкурентность, которую можно читать глазами, без явных пулов потоков и колбэков; сильная стандартная библиотека (net/http, encoding/json, context, testing из коробки); встроенный тулинг — go test, go vet, -race, pprof, go mod; минимальный синтаксис, из-за чего чужой код читается почти без разгона, а онбординг в команду занимает дни. Хорошо, если упомянешь и цену этих решений — это отличает зрелый ответ от восторженного: многословная обработка ошибок, GC-паузы (пусть и субмиллисекундные), дженерики появились только в 1.18 и покрывают не всё, отсутствие sum-типов. Чего не надо: «Go простой, его можно выучить за неделю» (читается как «я знаю только синтаксис»), «Go быстрый как C» (неверно и легко ловится вопросом про GC и escape-анализ), и рассказ длиной в биографию.

что тебя драйвит в разработке?

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

Глубже. Придумывать за тебя нечего, но полезно знать, какие типы мотивации вообще существуют и как они звучат убедительно: (1) инженерный вызов — нагрузка, latency, конкурентность («драйвит, когда есть измеримый результат: было p99 X мс, стало Y»); (2) продуктовое влияние — видеть, как фича меняет метрику; (3) владение системой — отвечать за сервис целиком, от дизайна до дежурства; (4) люди — менторство, рост команды; (5) обучение — новый домен, новые технологии. Каркас: «Больше всего — <тип>. Например, <короткий кейс: задача, что сделал, измеримый результат>. Меньше энергии мне даёт <честная антимотивация>». Последняя часть сильно повышает доверие, но формулируй её так, чтобы она не отменяла вакансию (не говори «не люблю легаси», если идёшь чинить легаси). Что нельзя: «драйвит решать интересные задачи» без расшифровки — это пустая строка, интервьюер слышит её десять раз в день; «драйвят деньги» — честно, но не для этого вопроса; и списывание чужой мотивации, потому что следом идёт вопрос «приведи пример», и несоответствие видно сразу.

куда планируешь развиваться (техлим/техлид и т. п.)?

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

Глубже. Каркас: «В горизонте <1–2 года> хочу <направление>, потому что <что уже пробовал и понравилось/не понравилось>. Для этого мне нужно <конкретные навыки/опыт>. Как у вас устроен переход в <роль> — есть ли формальные грейды и что нужно закрыть?». Полезно понимать реальную развилку: экспертный трек (Senior → Staff/Principal) — глубина, архитектура, кросс-командные технические решения, влияние через дизайн-документы и ревью; менеджерский трек (Team Lead → Engineering Manager) — люди, найм, one-to-one, приоритизация, доля кода падает; и промежуточный техлид, который во многих российских компаниях означает «сеньор + ответственность за техрешения и часть процессов, без hr-функций» — уточни, что под этим понимает конкретно эта компания, определения различаются радикально. Что нельзя: «хочу в менеджеры, потому что надоело кодить» (сигнал бегства, а не роста), «мне всё равно, куда развиваться» (нет собственного вектора), и обещание «через год стать тимлидом» на позиции, где такого места нет — это претензия, которую вспомнят.

На какой проект хочется попасть? По каким критериям будешь выбирать? проект?

Коротко. Проверяют, есть ли у тебя осознанные критерии выбора или ты откликаешься веером. Сильный ответ — 3–4 приоритизированных критерия (именно с порядком важности) и сразу проверка их по этой вакансии.

Глубже. Каркас: «Первое — <критерий №1>, потому что <причина из опыта>. Второе — <критерий №2>. Третье — <критерий №3>. Дальше — деньги и формат, но они не на первом месте, если первые три закрыты. Расскажите, как с этим у вас?». Набор критериев, из которых обычно собирают ответ: доменная область и осмысленность продукта; технический масштаб (нагрузка, объём данных, распределённость); зрелость инженерной культуры (код-ревью, тесты, CI, дизайн-доки, посмертные разборы инцидентов); зона ответственности и автономия (владеешь сервисом или пилишь тикеты); команда и уровень коллег, у кого учиться; стадия проекта (greenfield против поддержки), формат работы и стабильность компании. Сила ответа — в приоритизации и честном признании, что критерии конфликтуют: greenfield редко сочетается со зрелыми процессами, высокая автономия — с подробным онбордингом. Что нельзя: перечислять критерии, которые эта вакансия заведомо не закрывает (значит, ты не читал описание), говорить «мне подойдёт любой проект» (нет позиции) и требовать «только новые технологии» — в 90% случаев работа состоит из развития существующей системы.

Почему решил выйти на рынок?

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

Глубже. Каркас: «На текущем месте <срок>, сейчас <что происходит: проект перешёл в поддержку / закрылся домен / роль стабилизировалась>. Мне не хватает <конкретика>. Внутри компании я <что пробовал: обсуждал переход в другую команду, просил новые задачи>, вариант <почему не сработал>. Поэтому смотрю рынок, ищу <критерий>». Здесь же обычно прилетает вопрос про деньги — практика: если HR спрашивает «на какую сумму ориентируетесь?» первым, корректный ход — вернуть вопрос один раз: «У вас наверняка есть вилка на этот грейд — назовите, пожалуйста, и я скажу, попадаю ли». Если вилку называют — отвечаешь, попадаешь ли, и не соглашайся сразу на нижнюю границу («интересен верх вилки, обосную на техническом этапе»). Если вилку не называют и вопрос повторяют — называй диапазон gross, где нижняя граница есть та сумма, за которую ты действительно готов выйти сегодня (её и предложат), а верхняя — рынок для твоего грейда с запасом на торг. Обоснование — только рынок, грейд и зона ответственности; не расходы, не «мне обещали столько же в другом месте», если это неправда. Отказываться называть цифру совсем — плохая тактика: HR-скрининг существует ровно для отсева по вилке, и «не готов обсуждать» часто просто закрывает воронку. Что нельзя: говорить «просто интересно, что на рынке» (мгновенно снижает приоритет твоей кандидатуры), называть сумму нетто без уточнения — на оффере она превратится в gross минус НДФЛ, и обещать «выйду за любые деньги, лишь бы задачи» — на оффере это используют.

Расскажи, почему рассматриваешь предложения?

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

Глубже. Каркас: «Ищу <критерий №1 и №2>. Сейчас в процессе компаний, финальные этапы ориентировочно <срок>». Это не давление, а нормальная синхронизация сроков, и она реально ускоряет воронку — но врать про несуществующие офферы нельзя: на этапе оффера просят подтверждение либо просто перестают торговаться, поймав несостыковку в сроках. Практика по контрофферу от текущего работодателя: он почти всегда приходит после того, как ты приносишь заявление, и почти всегда закрывает только деньги, а не причину ухода — если причина была содержательной (роль, задачи, потолок), контроффер её не решает, и через 3–6 месяцев ситуация повторяется, но теперь ты уже «человек, который собирался уходить». Разумный алгоритм: заранее для себя сформулировать, при каком изменении условий ты остался бы, и если контроффер этого изменения не содержит — отказываться сразу и вежливо. Внешней компании про контроффер говорить не обязательно; если спрашивают прямо — честный ответ «текущий работодатель предложил пересмотр, но моя причина ухода не в деньгах» работает лучше, чем использовать контроффер как рычаг: попытка устроить аукцион между двумя работодателями чаще всего заканчивается отзывом оффера.

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

Коротко. Здесь проверяют инженерную зрелость и то, как ты работаешь с людьми: junior говорит про стиль и линтеры, senior — про корректность, границы ответственности и читаемость через полгода. Сильный ответ — назвать приоритет проверок (сверху вниз: делает ли изменение то, что заявлено → корректность в конкурентности и ошибках → влияние на систему → читаемость → стиль) и отдельно сказать про тон комментариев.

Глубже. Порядок, который стоит проговорить: (1) соответствие задаче и границам изменения — не приехало ли в PR лишнее, не сломан ли контракт API/схема БД, обратная ли совместимость миграции; (2) корректность в опасных местах — обработка ошибок (не проглочены ли, есть ли контекст через fmt.Errorf("...: %w", err)), отмена и таймауты (context), гонки и утечки горутин, ресурсы (defer Close(), закрытие rows), поведение на границах и при повторной доставке (идемпотентность); (3) тесты — покрыт ли новый инвариант, а не просто «тесты есть»; (4) читаемость: имена, размер функции, уровень абстракции, отсутствие «умного» кода; (5) стиль и форматирование — это работа gofmt, go vet, линтера в CI, а не человека, и если ты тратишь ревью на пробелы, у тебя не настроен CI. Про людей: комментарии делить на блокирующие и необязательные (nit:), формулировать вопросом («что будет, если сюда придёт пустой слайс?») вместо приказа, хвалить удачные решения, а спор длиннее трёх сообщений уносить в звонок. Про размер: ревью PR на 1000 строк бесполезно, и правильный ответ включает «прошу разбивать крупные изменения». Что нельзя говорить: «главное, чтобы соответствовало нашему стайлгайду», «я обычно апрувлю, если тесты зелёные» и рассказы о том, как ты «заворачиваешь» чужой код — интервьюер услышит будущий конфликт в команде.

Почему вы решили стать программистом? Что вас драйвит в этой профессии?

Коротко. Первая половина — вопрос-разогрев, проверяют связность истории и то, что ты в профессии осознанно; вторая — та же мотивация, что и в вопросе «что тебя драйвит» (см. выше). Сильный ответ — короткая история входа (2–3 предложения, без детства и первого компьютера) и один настоящий источник драйва с примером.

Глубже. Каркас: «<Что было до: образование/другая профессия/первый опыт>. Попал в разработку через <точка входа: учёба, свой проект, смежная роль — тестирование, поддержка, аналитика>. Остался, потому что <что именно нравится в самой работе>. Сейчас больше всего драйвит <кейс с измеримым результатом>». Уместно назвать свойство профессии, а не только эмоцию: быстрая обратная связь (код либо работает, либо нет), возможность влиять на реальный сервис, постоянное обучение как часть работы, инженерное удовлетворение от упрощения сложного. Отличие от вопроса №6: там спрашивают о текущей мотивации, здесь — ещё и о происхождении, поэтому нужна причинно-следственная связка «пришёл → почему остался». Что нельзя: «потому что хорошо платят» как единственный ответ, «всегда любил компьютеры с 5 лет» (ни о чём), и слишком длинный рассказ — этот вопрос почти всегда открывающий, и растянув его, ты съедаешь время технической части.

Как вы оцениваете технические навыки кандидата на собеседовании? Что для вас важно увидеть?

Коротко. Вопрос задают, когда позиция предполагает участие в найме (сеньор, техлид). Проверяют, есть ли у тебя структура оценки и понимаешь ли ты, что цель собеседования — предсказать работу в команде, а не поймать кандидата на незнании. Сильный ответ — назвать 3–4 сигнала, которые ты снимаешь, и способ, которым ты их снимаешь.

Глубже. Рабочая структура ответа: смотрю (1) глубину в заявленном — беру то, что человек сам назвал сильной стороной, и иду вглубь до границы знания; важен не факт границы, а способность её честно обозначить («здесь я не уверен, проверил бы так-то»); (2) ход мысли на открытой задаче — уточняет ли требования, называет ли предположения, обсуждает ли trade-off, а не выдаёт готовый ответ; (3) практику вместо теории — не «что такое индекс», а «вот запрос и план, что не так»; (4) прикладной опыт эксплуатации — как отлаживал в проде, что делал при инциденте; (5) коммуникацию — понятно ли объясняет, реагирует ли на подсказку. Полезно упомянуть гигиену процесса: одинаковые вопросы для сравнимости кандидатов, письменный фидбек с фактами, а не впечатлениями, разделение «нет опыта» и «не может научиться», и отказ от головоломок и вопросов на память по стандартной библиотеке. И честная рамка: собеседование — шумный инструмент, поэтому вывод формулируется как «на какой позиции и с какой поддержкой этот человек будет успешен», а не «прошёл/не прошёл». Что нельзя: «сразу видно за пять минут», «спрашиваю алгоритмы, потому что так у всех», рассказ о том, как ты «валишь» кандидатов.

Почему решил уйти?

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

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

Что мастеришь в новой работе?

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

Глубже. Каркас: «Ищу <критерий>. Если говорить, что готов делать: первые <1–2 месяца> — разобраться в <домен и сервисы>, закрывать реальные задачи, чтобы понять систему изнутри; дальше — взять ответственность за <кусок системы> и подтянуть <что умею: наблюдаемость, тесты, производительность, дизайн новых сервисов>». Полезно спросить, какая задача первого квартала стоит перед этой позицией — ответ покажет, совпадают ли ожидания, и одновременно продемонстрирует, что ты мыслишь в терминах результата. Что нельзя: обещать «навести порядок и всё переписать» — это самое частое, чего боятся нанимающие менеджеры от новичка-сеньора; и заявлять конкретные изменения в системе, которую ты ещё не видел.

Кем видишь себя через 1, 3, 5 лет, чтобы помогло стать им?

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

Глубже. Каркас: «Год — <измеримо: закрыть онбординг, взять ответственность за сервис X, довести до прода Y>; для этого нужны <ревью от сильных коллег, доступ к проду, менторство>. Три года — <роль/трек: экспертный или лидерский> в <домен>; для этого нужен опыт <проектирования систем с нуля / ведения команды / работы с нагрузкой>. Пять — <направление, честно с оговоркой, что горизонт длинный: например, отвечать за архитектуру направления или растить команду>». Хорошо звучит фраза, что пятилетний план в индустрии — это скорее вектор, чем план, при условии, что годовой у тебя действительно конкретный. Что нельзя: «через 5 лет вижу себя в вашей компании на позиции CTO» (лесть, читается насквозь), «не знаю, не планирую так далеко» без вектора (нет управления карьерой), и планы, никак не связанные с вакансией — «через 3 года хочу в ML» на позиции backend-инженера прямо сообщает интервьюеру срок твоего ухода.

Что ищешь в новой работе, что привлекает?

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

Глубже. Каркас: «Ищу <критерий №1: например, нагруженный сервис с реальными SLA> и <критерий №2: зона ответственности за сервис целиком>. В вашей вакансии меня зацепило <конкретика из описания или из того, что рассказал интервьюер: домен, масштаб, стек, задача>. Хочу уточнить: <вопрос, проверяющий критерий №1>». Вторая часть — обязательная: «что привлекает» — это вопрос про то, читал ли ты вообще, куда пришёл. Одно предметное упоминание продукта или задачи здесь стоит больше, чем абзац про ценности. Что нельзя: комплименты бренду («вы известная компания»), «привлекает возможность развиваться» (пустое), перечисление только льгот и удалёнки, и критерии, противоречащие тому, что ты назвал причиной ухода — несостыковку интервьюер держит в голове весь разговор.

Почему вы выбрали Go? Что повлияло на переход с C++?

Коротко. См. выше «Как пришёл к Go». Отличие: здесь ждут сравнения именно с C++, и проверяют, был ли переход осознанным. Сильный ответ — 2–3 конкретных отличия, которые ты почувствовал в работе, и признание того, что ты потерял при переходе.

Глубже. Что реально меняется при переходе C++ → Go и звучит убедительно: время сборки (минуты/десятки минут против секунд), отсутствие ручного управления памятью и целого класса ошибок с ним связанных (use-after-free, двойное освобождение), встроенная модель конкурентности вместо потоков и разнородных библиотек, один способ сборки и зависимостей (go mod) вместо зоопарка CMake/Conan/vcpkg, единый форматтер и отсутствие споров о стиле, радикально более простой язык — меньше времени уходит на чтение чужого кода и на споры о том, какую из пяти возможностей языка применять. Что теряется, и это честно назвать: контроль над памятью и предсказуемость без GC (Go не подходит для hard real-time и очень чувствительных к латентности систем), zero-cost абстракции и шаблонная метапрограммирование, RAII и деструкторы (в Go — defer, который срабатывает на выходе из функции, а не из блока), богатство constexpr-вычислений на этапе компиляции. Ссылки на факты по языку: официальный FAQ (go.dev/doc/faq) прямо описывает мотивацию создателей — скорость сборки, простота зависимостей и конкурентность в многоядерном мире. Что нельзя: говорить «в C++ слишком сложно, я не потянул», обесценивать C++ («устаревший язык»), и утверждать, что Go сопоставим по производительности с C++ во всех сценариях.

Почему вы начали изучать Go?

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

Глубже. Каркас: «Триггер — <что именно: сервис на проекте переписывали на Go / нужен был инструмент, где нужен один бинарь / команда переходила / изучал под вакансии>. Начал с <Tour of Go, Effective Go, книга, свой сервис>. Первым, что делал на Go — <проект>. Что оказалось непривычным — <честная деталь: обработка ошибок, отсутствие исключений, интерфейсы удовлетворяются неявно, работа со срезами и aliasing>». Признание конкретной трудности при старте — сильный сигнал, что опыт настоящий: выдуманные истории изучения всегда гладкие. Если Go был вынужденным выбором (так решили за тебя), так и скажи — важно, что было дальше и почему ты остался.

Почему выбрали Go?

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

Глубже. Если этот вопрос задают уже после того, как ты рассказал историю прихода, интервьюер обычно проверяет одно из двух: либо переспрашивает для сверки (совпадёт ли формулировка), либо хочет технический разворот. Ответ безопаснее строить как «свойство → следствие в работе»: статическая типизация и компиляция → ошибки ловятся до прода; один бинарь без зависимостей → простой деплой и маленький образ; горутины → конкурентный код без коллбэков; стандартная библиотека и тулинг → меньше внешних зависимостей и предсказуемый CI. Если следом спрашивают «а что в Go тебе не нравится» — это не ловушка, а проверка зрелости: назови реальное (многословный if err != nil, отсутствие sum-типов и Result, ограничения дженериков, nil-интерфейс с ненулевым типом внутри) и скажи, как с этим живёшь на практике.

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

• Негатив про прошлого работодателя, коллег или руководителя — интервьюер экстраполирует это на будущий отзыв о нём самом; любую претензию нужно переводить в описание процесса и своих попыток его починить.
• Несостыковка истории: причина ухода не совпадает с критериями поиска, планы на 3 года противоречат вакансии, а финальные вопросы кандидата — обоим ответам.
• Пустые формулировки — «интересные задачи», «хочу развиваться», «сильная команда» — без единого проверяемого критерия и примера.
• Монолог на 5–10 минут в ответ на разогревочный вопрос: съедает время технической части и читается как неумение структурировать мысль.
• Деньги как единственная причина ухода без содержательной части — сигнал, что кандидат уйдёт от следующего работодателя за +10%.
• Ошибки в зарплатном разговоре: точная цифра вместо диапазона, названная нижняя граница ниже приемлемой, сумма нетто без уточнения, обоснование через личные расходы, блеф про несуществующие офферы.
• Использование контроффера как рычага и торг между двумя работодателями — частая причина отзыва оффера; контроффер обычно закрывает деньги, но не причину ухода.
• Выдуманный опыт и мотивация: следующий же вопрос «приведи пример» или уточнение вглубь вскрывает несоответствие, и обнуляется весь разговор, а не один ответ.
• Обещание «прийти и всё переписать» на новом месте — главный страх нанимающего менеджера от сильного кандидата.

Что почитать

• Go FAQ — почему язык устроен именно так — источник корректных аргументов «почему Go».
• The Go Memory Model и пакет sync/atomic — для вопроса про атомики и гонки.
• Data Race Detector — как ловить гонки на практике.
• RabbitMQ: Which protocol/broker to use и Kafka Documentation: Introduction — фактура для сравнения брокеров.
• Google Engineering Practices: Code Review Developer Guide — эталонная структура ответа про код-ревью.