Как готовиться к собеседованию на Go

Давайте для начала разберемся, из чего состоит среднее собеседование:

1. Рассказ о себе, опыте и достижениях.
2. Проверка теоретических знаний и инженерного мышления.
3. Решение лайвкодинг-задач под давлением.

Если проседает хотя бы один пункт, оффер можно так и не увидеть. Поэтому готовиться стоит не только к вопросам по Go, но и к тому, как ты рассказываешь о себе, объясняешь решения и действуешь в стрессовой ситуации.

Рассказ о себе и своем опыте

Можно реально делать полезные вещи на работе, но на собеседовании рассказывать так:

Я работал над платежами, добавил туда логику, писал тесты и фиксил баги.

Смысл вроде есть, но впечатления почти нет. Интервьюер слышит общие слова, за которыми не видно ни задачи, ни сложности, ни твоего вклада.

А можно сказать сильнее:

Я завел новую логику возврата платежей. Если банк или внешний сервис отвечал ошибкой, мы автоматически оформляли пользователю возврат денег на счет. Основной базой был PostgreSQL, а Kafka помогала отслеживать жизненный цикл платежа. Отдельно я реализовал state machine, которая не давала платежу случайно перейти в невалидный статус.

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

На собеседовании важно уметь ответить:

• что ты делал;
• зачем это было нужно;
• какие были сложности;
• какие решения рассматривал;
• почему выбрал именно это решение;
• что бы сделал лучше сейчас;
• какие метрики использовали, чтобы понять, что фича работает нормально;
• как задача проходила путь от требований до прода.

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

Теоретические знания

Теория - это Go, базы данных, индексы, транзакции, Redis, Kafka, HTTP, gRPC, конкурентность, память, архитектура и другие темы, которые регулярно всплывают на backend-собеседованиях.

Как изучать теорию:

• сначала разобраться с базой технологии: синтаксисом Go, идеей индекса, простыми SQL-запросами;
• потом накладывать продвинутые темы: виды индексов в PostgreSQL, выбор блокировок, устройство планировщика Go;
• закреплять практикой: писать pet-проект, прогонять запросы к БД, разбирать реальные сценарии;
• смотреть и проходить мок-собеседования, например с партнером из @mock_find_bot.

Мок-собеседования особенно важны, потому что знать и уметь рассказать - это разные навыки.

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

Когда ты уже несколько раз проговаривал похожий вопрос, ситуация другая:

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

Лайвкодинг

Почти всегда на Go-собеседованиях есть хотя бы какой-то лайвкодинг. Это могут быть:

• задачи на слайсы;
• задачи на мапы;
• горутины и каналы;
• поиск бага в коде;
• небольшая продуктовая задача;
• ревью куска кода;
• вопрос "что тут не так и как пофиксить?".

В лайвкодинге нет волшебной таблетки. Чтобы лучше решать задачи, надо решать задачи. Еще лучше - подробно разбирать решения и просить LLM объяснить каждую строчку, если где-то непонятно.

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

Потом сравнить свое решение с нормальным, разобраться, что не так, и повторить цикл.

Пара примеров:

• если задача на слайсы, важно понимать не только синтаксис append, но и то, что происходит с len, cap и underlying array;
• если задача на конкурентность, важно не просто написать go func(), а понимать, где может быть deadlock, race condition, утечка горутин, кто и где закрывает канал.

Финальный чеклист подготовки

• Собираешь свою легенду и учишься нормально рассказывать про опыт.
• Закрываешь основные теоретические темы.
• Регулярно проходишь мок-собеседования.
• Решаешь лайвкодинг руками.
• После каждого собеседования выписываешь вопросы, где поплыл.
• Добиваешь слабые места и идешь на следующий заход.

Не стоит уходить только в одно направление: легенду, теорию или лайвкодинг. Лучше держать баланс. Так и подготовка получается сильнее, и от одного типа задач не начинает тошнить через неделю.

Оригинальный пост: t.me/go_for_us/40.