Умеешь ли настраивать CI/CD?

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

Вопрос «умеешь ли» выясняет, собирали ли вы пайплайн сами или только смотрели, как он зеленеет. Следом обычно просят нарисовать стадии вашего пайплайна и рассказать, что делать, если тесты на CI падают, а локально проходят.

Как отвечать

Отвечайте через конкретный пайплайн, который вы собирали или правили. Типичный каркас для Python-сервиса:

• инструмент: GitHub Actions (.github/workflows/*.yml) или GitLab CI (.gitlab-ci.yml), в старых компаниях Jenkins;
• окружение: actions/setup-python или astral-sh/setup-uv с кешем зависимостей. Ставить их из lock-файла (uv.lock, poetry.lock), а не из плавающего requirements.txt;
• проверки: ruff check и ruff format --check, типы через mypy или pyright, тесты pytest с pytest-cov. Для библиотек матрица версий Python, например с 3.12 по 3.14;
• интеграционные тесты: Postgres или Redis поднимаются как services в job, а не подменяются SQLite, у которого другие типы и блокировки;
• сборка и доставка: многоэтапный Dockerfile, образ с тегом по коммиту в registry, выкатка на окружение. Миграции Alembic идут отдельным шагом до новой версии кода;
• секреты: в переменных CI или через OIDC к облаку, никогда в репозитории.

Добавьте свои цифры: сколько длился прогон, что ускорили, какой сбой пайплайн поймал до прода. Если с нуля вы ничего не настраивали, скажите прямо: «пайплайн собирал DevOps, я добавлял шаги с линтером и тестами и разбирался с падениями». И покажите, что понимаете, как собрали бы его сами.

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

Отвечают «да, работал с Jenkins» и замолкают. Без стадий и примера это звучит как «видел кнопку Build».

Путают continuous delivery и continuous deployment. В первом случае релиз готов к выкатке и уходит по решению человека, во втором каждый зелёный коммит сам едет на прод.

Не думают о миграциях при выкатке. Если новая версия удаляет колонку, а старые экземпляры приложения ещё работают, они падают. Схему меняют в два шага: сначала совместимое изменение, потом удаление.