С каким стеком Go библиотек знаком
Что проверяют
В Go ответ на этот вопрос сразу показывает школу. Проверяют, опираетесь ли вы на стандартную библиотеку или умеете работать только внутри фреймворка, по какому принципу выбираете зависимость и понимаете ли, что каждая тянет за собой свои транзитивные пакеты и свой ритм обновлений.
Как отвечать
Начните со стандартной библиотеки, в Go это не вежливость, а половина стека: net/http для сервера и клиента, context для отмены и таймаутов, encoding/json, database/sql, testing вместе с httptest, структурное логирование через log/slog.
Дальше внешние пакеты по слоям, с пояснением выбора.
- Маршрутизация: сторонний роутер или стандартный мультиплексор, который уже понимает метод и параметры пути.
- База: драйвер и пул для PostgreSQL, генерация кода по запросам или лёгкая обёртка вместо полноценной ORM.
- Конфигурация: чтение переменных окружения и разбор их в структуру.
- Тесты: библиотека утверждений, генерация заглушек по интерфейсам, поднятие зависимостей в контейнерах.
- Инфраструктура: клиент брокера сообщений, метрики, трассировка, кодогенерация для gRPC.
Заканчивая, назовите критерий выбора: живой ли проект, поддерживает ли пакет context, предсказуемо ли ведёт себя при отмене запроса и сколько чужого кода приносит с собой.
Где спотыкаются
Знают только фреймворк. Просьба написать обработчик и промежуточный слой на голом net/http ставит в тупик, хотя это ровно то, поверх чего построены все популярные роутеры.
Не пробрасывают context до самого низа. Клиент отключился, обработчик про это знает, а запрос в базу и вызов соседнего сервиса продолжают работать: отмена не доходит, ресурсы держатся, таймауты не действуют.
Называют библиотеку, не зная её состояния. Часть популярных пакетов давно передана сообществу или заменена форком с другим адресом модуля, и кандидат, который об этом не слышал, выдаёт, что читал старую статью, а не работал с кодом.