С какими Go библиотеками работал

Что проверяют

Знаете ли вы экосистему Go и, главное, умеете ли обходиться стандартной библиотекой. Сообщество ценит малое число зависимостей, поэтому длинный список сторонних пакетов без объяснения, зачем каждый, работает против вас.

Как отвечать

Разложите по слоям и на каждом скажите, что берёте из stdlib, а что снаружи.

• HTTP: net/http закрывает большинство задач, а начиная с Go 1.22 его маршрутизатор понимает метод и параметры пути, так что сторонний роутер нужен реже. Из внешних обычно chi (совместим с интерфейсами stdlib) или gin, если команда уже на нём.
• База: database/sql плюс драйвер, для PostgreSQL это pgx. Дальше выбор подхода: sqlx для удобного сканирования, sqlc для генерации кода из SQL, gorm, когда нужна полноценная ORM.
• Конфигурация и логи: viper или разбор переменных окружения своими силами; логи с Go 1.21 удобно вести через log/slog из stdlib, из внешних живые zap и zerolog.
• Тесты: testify для утверждений, gomock или mockery для заглушек, testcontainers-go для интеграционных.
• Остальное: grpc-go с protobuf, errgroup из golang.org/x/sync, golangci-lint в сборке.

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

Где спотыкаются

Тянут веб-фреймворк по привычке и не могут объяснить, что он даёт поверх net/http. Встречный вопрос «а что именно вам тут нужно от фреймворка» проваливают чаще всего.

Называют ORM и не знают её цены: сколько запросов уходит в базу на самом деле, почему автоматическая миграция схемы не годится для продакшена, как посмотреть сгенерированный SQL.

Перечисляют пакеты, но не говорят про идиомы, которые важнее: сквозной context.Context, оборачивание ошибок через %w и разбор через errors.Is и errors.As, отсутствие глобального состояния ради тестируемости.