Как отвечать: определение → как работает внутри → где ловушка → пример. Отвечайте вслух до чтения ответа — собеседование это устный жанр, и «понимаю про себя» не равно «объясняю словами».
1. Как готовиться к собеседованию по Go: с чего начать и за сколько?
Проблема типичной подготовки — распыление: месяц чтения статей, а на интервью половина вопросов всё равно вызывает паузу. Работает обратный подход: сначала собрать список вопросов, потом чинить дыры по нему.
Порядок обычно такой. Первое: взять список тем, которые чаще всего спрашивают, и проверить себя на каждой. Проверка — не перечитать, а ответить вслух: сформулировать проблему, механизм и пример. Второе: написать код. Даже простой: пул воркеров, HTTP-хендлер, разбор JSON, тест с моком. На собеседованиях просят именно код, и человек, который год читал, часто не может написать тридцать строк без подсказки. Третье: перечитать свои провалы. Список тем, где вы застряли, и есть ваша программа подготовки.
По времени: на джуна это обычно пара недель, на middle — месяц, на senior — столько, сколько нужно закрыть конкретные пробелы в системном опыте. Привязка к неделям полезна, но важнее понимать, что за день подготовки даёт один час практики с кодом и ни минуты чтения.
Отдельно про формат: стоит проговаривать ответы вслух, стоя и с таймером. На интервью время давления, и мысль, которая «в голове есть», в этих условиях не находится. Отдельно стоит держать примеры из своего опыта: интервьюер почти всегда спрашивает про конкретную задачу, и ответ «в проекте мы использовали мьютекс, потому что…» звучит сильнее, чем описание мьютекса вообще.
// Тренировка: объяснить тему и записать, что не получилось // 1. Ответить вслух за 2 минуты // 2. Записать вопрос, где остановились // 3. Закрыть пробел и повторить через день
2. Какие вопросы спрашивают чаще всего на собеседовании Go-разработчика?
Проблема в том, что список «частых вопросов» из интервью в интервью почти не меняется: основа одна и та же, меняется только глубина. Здесь — рабочий набор, от которого стоит отталкиваться.
База для всех уровней: отличие горутины от потока, буферизованный и небуферизованный канал, close и его последствия, select с default и с таймаутом, гонка данных и детектор -race, WaitGroup и errgroup, контекст и отмена, defer и порядок выполнения, срезы: len, cap, append и общая память, карты: nil-карта, удаление, потокобезопасность, ошибки: оборачивание, errors.Is и errors.As, интерфейсы: nil-интерфейс, type assertion, неявная реализация.
Уровень middle добавляет: устройство планировщика в общих чертах, escape analysis, GC и GOGC, sync-примитивы и их границы, идемпотентность и обработка ошибок в API, проектирование структуры пакета, тестируемость кода и моки, вопросы про производительность и профилирование.
Уровень senior добавляет: модель памяти и happens-before, устройство канала и select внутри, pacer и write barrier, GOMAXPROCS и поведение в контейнерах, распределение ответственности в системе, обратная совместимость и миграции, эксплуатационные вопросы — graceful shutdown, лимиты, OOMKill.
Практический вывод: подготовьте не «все вопросы», а те, где ваш ответ заканчивается словом «ну, это зависит». Ответ «это зависит» без продолжения — это не знание, а способ уйти от ответа, и интервьюер это слышит.
Полезная метрика самопроверки: если на любой вопрос из базы вы можете за две минуты привести пример из своего кода, база закрыта.
// Шпаргалка для самопроверки — по одной строке на тему: // горутина: задача планировщика, стек в куче, мигрирует между ядрами // канал: передача владения, закрывает писатель // контекст: отмена и дедлайн по цепочке вызовов // срез: окно над массивом, append может переаллоцировать
3. Как отвечать на вопрос, на который вы не знаете ответа?
Проблема в том, что две крайности одинаково плохи. Первая — молчать: интервьюер записывает «не знает» и идёт дальше, вы теряете возможность показать ход рассуждений. Вторая — выдумывать: на Go это особенно плохо, потому что интервьюер знает предмет глубже вас и поймает несуществующий API.
Рабочий ответ состоит из трёх шагов. Первый: сказать прямо, что не помню деталь, но знаете, где искать. Второй: описать механизм так, как понимаете, и назвать то, в чём не уверены. Третий: предложить способ проверить — прочитать исходник рантайма, посмотреть документацию, написать маленький эксперимент.
Звучит это примерно так: «конкретное число байт в структуре g я не помню, но устройство я знаю: это заголовочный блок со стеком и ссылкой на функцию, и размер зависит от архитектуры; проверить можно через unsafe.Sizeof в сорок строк кода».
Почему такой ответ лучше: он показывает именно то, что проверяют на senior-секциях — способность разобраться в незнакомом. Часто интервьюер после такого ответа сам даёт подсказку, и дальше разговор идёт продуктивно.
Чего избегать. Не выдумывать API и не путать версии: «в Go 1.22 появилось» — неправда, если это было в 1.21. Не отвечать уверенно на смежную тему, в которой вы плаваете: «это примерно как с каналами» хуже, чем честное «не знаю, но догадываюсь так».
И последнее: если незнакомых вопросов много, это сигнал готовиться дальше, а не повод отчаиваться. На реальных интервью так бывает у всех.
// Шаблон ответа: // 1. Честность: «деталь не помню» // 2. Механизм: что знаю наверняка // 3. Проверка: как бы узнал точно
4. Как отвечать на вопрос про опыт: рассказывать про задачи или про технологии?
Проблема: перечисление технологий звучит как резюме, а интервьюер хочет понять, как вы принимали решения. «Использовал Redis для кэша» — это факт без содержания; «взяли Redis, потому что данные обновлялись раз в минуту, а invalidate требовал остановки всех подписчиков, и потеря кэша была допустима» — это инженерная мысль.
Рабочая структура ответа про задачу: контекст, решение, цена решения, что сделали бы иначе. Именно последний пункт отличает инженера от исполнителя, и интервьюер на него смотрит в первую очередь.
Что стоит подготовить заранее: три задачи, которые вы решали лично, в разных ролях — одна с архитектурой, одна с неочевидным багом, одна с конкурентностью или производительностью. По каждой достаточно двух минут и одного-двух абзацев.
Отдельно про язык ответов. На вопрос «как вы решили» нужен глагол действия: «я снял профиль», «я сузил область поиска», «я перенёс блокировку». На вопрос «почему» нужен trade-off: «выбрал канал, потому что данные передавались дальше, и мьютекс оставил бы владение неявным».
Чего избегать: пересказать документацию вместо своего опыта, обесценивать предыдущие решения («там всё было плохо, я переписал») — это говорит больше о вас, чем о задаче. И не прятать неудачные решения: рассказ «я сначала сделал так, оказалось неверно, поменял вот так» ценится выше, чем рассказ, где всё с первого раза получилось.
Хороший признак, что вас слушают: интервьюер начинает уточнять детали. Значит, вы попали в точку.
// Структура ответа про задачу: // 1. Контекст: что за система, какие ограничения // 2. Решение: что сделал и почему именно так // 3. Цена: чем заплатили за выбор // 4. Ретроспектива: что сделал бы иначе
5. Как проходит техническое задание и live-coding: что хотят увидеть?
Проблема: кандидат готовится к устным вопросам, а на интервью ему дают задачу и сорок минут. На задаче проверяется не знание, а процесс: как вы декомпозируете, как пишете, как проверяете и что делаете, когда застряли.
Что смотрят. Первое: уточняющие вопросы до начала работы. Хороший кандидат спрашивает про ограничения, входные данные, нужную точность и критерии готовности — и это не трата времени, а экономия. Второе: порядок работы. Сначала простой работающий вариант, потом улучшения; или сначала тест, потом реализация — но в любом случае сначала что-то работающее. Третье: проверка. Код, который написан и не запущен, половина работы не сделана: именно на этом чаще всего ломаются кандидаты, которые знают теорию. Четвёртое: реакция на застревание. Правильный ход — проговорить, где застрял, выбрать безопасный вариант (например, вернуть упрощённый результат с комментарием) и продолжить, а не сидеть молча.
Живое кодирование отличается от задания тем, что за вашей спиной смотрят в реальном времени. Совет простой: думайте вслух. Тишина во время кодирования читается как растерянность, а проговаривание («сейчас выберу структуру среза, потому что порядок сохранять не нужно») показывает ход мысли.
Отдельно про мелочи, которые бросаются в глаза: имя переменной, понятное без комментария; ошибки, которые не игнорируются; никакой магии и «просто хардкода» там, где должно быть обобщение.
// Порядок работы над задачей: // 1. Уточнить требования и ограничения // 2. Написать простейший работающий вариант // 3. Проверить на примерах, включая границы // 4. Улучшить: читаемость, производительность, тесты
6. Какие вопросы стоит задать самому кандидату?
Проблема: на собеседовании читатель часто задаёт вопросы только из заготовленного списка и не узнаёт ничего о реальной работе. Вопросы кандидату — не вежливость, а способ получить ту же информацию, что ищет и интервьюер: риски, объём и условия.
Что стоит спросить. Про задачи: какая сейчас главная задача команды и что будет, если её не решать полгода. Про процесс: как устроено ревью, сколько занимает цикл с нуля до продакшена, есть ли ревьюится всё подряд или только часть. Про качество: как ловят регрессии — тесты, мониторинг, алерты; что делали с последней аварией и как её разбирали. Про нагрузку: сколько сейчас пользователей, запросов в секунду, какого роста ждут в ближайший год. Про команду: сколько человек, как распределяются задачи, кто принимает технические решения.
Вопросы, которые стоит задавать с осторожностью: «как часто приходится перерабатывать» — прозвучит как претензия, «почему уволился» — личное, а «когда планируете нанять ещё» — слишком в лоб.
Что оценивать в ответах. Конкретика вместо общих слов: «деплой раз в неделю, откат автоматический, дежурство раз в месяц» — хороший знак; «у нас всё гибко и современно» — плохой. Совпадение ответов с тем, что вы уже услышали про задачи: если на вопрос про нагрузку отвечают «у нас десять пользователей», а потом выясняется, что продукт делают для enterprise-клиентов, стоит уточнить.
// Список вопросов кандидату (краткий): // — какая главная задача команды сейчас // — как устроен цикл работы: ревью, тесты, релиз, откат // — как ловите регрессии в проде // — сколько сейчас трафика и какого роста ждёте // — как принимаются технические решения в команде
7. Чем senior отличается от middle в Go: что проверяют на уровне выше?
Проблема: разница уровней часто сводится к стажу, но интервьюер проверяет другое — способность принимать решения и отвечать за их последствия. Middle отвечает за задачу, senior — за направление.
Что появляется в senior-секции. Первое: системное мышление. Вопросы уровня «вы подняли лимит соединений до десяти тысяч — что сломается раньше: база, пул, память или сеть» требуют связать несколько подсистем, а не назвать узкое место.
Второе: границы решения. Senior должен сказать, когда задача не решается его инструментом: «здесь нужен не кэш, а изменение схемы» или «это не проблема Go, это ограничение базы». Умение остановиться и сказать «это я не знаю, давайте проверим» ценится выше, чем универсальный ответ.
Третье: эксплуатационная зрелость. Как сервис переживает деплой, что происходит при недоступной зависимости, как устроен graceful shutdown, что покажет деплой в метриках. Это не про язык, но именно здесь разница между «написал код» и «владеет сервисом».
Четвёртое: работа с неопределённостью. Вопросы без готового ответа: «как бы вы спроектировали систему очередей для наших объёмов» — здесь оценивают ход рассуждения, а не финальную схему.
Практический совет: готовьтесь к senior-секции не по списку тем, а по историям из практики, где вы приняли решение, за которое потом отвечали. Ответ на вопрос «что бы вы сделали иначе» здесь ценится выше, чем на junior-секции, где достаточно назвать правильный инструмент.
// Разница уровней — не в том, что вы знаете, а в том, за что отвечаете: // junior: «как сделать правильно» // middle: «как сделать надёжно в этом сервисе» // senior: «какая форма решения верна для компании через год»
Прокачать тему в самоучителе
Читается быстро, запоминается практикой. Эти курсы закрывают тему с запуском кода прямо на странице:
- Язык Go с нуля: базовый синтаксис и конструкции — Интерактивный курс базового синтаксиса Go для начинающих: переменные, циклы, срезы, функции, структуры. 25 уроков с кодом в браузере, тестами и первым приложением.
- Продвинутые возможности языка Go — Продвинутый курс Go: замыкания, defer, горутины, каналы, контекст, интерфейсы, дженерики, рефлексия, тесты и JSON. 25 уроков с практикой в браузере.
- Testify: тестирование на Go с assert, require и mock — Интерактивный курс Testify для Go: assert и require, табличные тесты, suite, mock-объекты, Eventually, HTTP-тесты. 25 уроков с примерами и практикой в браузере.