Какие инструменты и подходы CI/CD вы применяли

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

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

Как отвечать

Отталкивайтесь от одного реального проекта и пройдите пайплайн по стадиям, называя инструменты:

• проверки: go vet, golangci-lint с конфигом в репозитории, gofmt или gofumpt, govulncheck для уязвимых зависимостей;
• тесты: go test -race ./... с покрытием через -coverprofile, интеграционные тесты с базой в контейнере, например через testcontainers-go;
• сборка: статический бинарник с CGO_ENABLED=0, версия и коммит через -ldflags "-X main.version=...", многоэтапный Dockerfile с финальным образом scratch или distroless;
• кэш: GOMODCACHE и GOCACHE между запусками, иначе каждая сборка заново качает модули и компилирует всё с нуля;
• доставка: GitLab CI или GitHub Actions собирают образ и кладут в registry, дальше Helm или Argo CD выкатывают его в Kubernetes.

Отдельно скажите про подход: trunk-based или ветки, ревью через merge request, раздельные окружения, стратегия выката (rolling, canary, blue-green) и как устроен откат. Цифры давайте свои: сколько шёл пайплайн до и после, что именно его ускорило. Если сами пайплайн не писали, так и скажите, и объясните, какие стадии понимаете и что меняли в чужом .gitlab-ci.yml.

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

Перечисляют Jenkins, GitLab CI, CircleCI и Terraform одной строкой. Интервьюер спросит про любой пункт, и список без опыта рассыпается.

Забывают про -race. Для Go это самая дешёвая проверка на гонки, и её отсутствие в пайплайне говорит о небольшом опыте с конкурентным кодом.

Путают CI и CD или считают, что CD это обязательно автоматический выкат в прод. Непрерывная доставка допускает ручное подтверждение перед продом, непрерывное развёртывание обходится без него.