Можно ли локально поднять систему

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

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

Как отвечать

Опишите конкретный проект по шагам, со своими цифрами:

• SDK и пакеты: нужная версия .NET SDK (её фиксирует global.json), dotnet restore, приватный NuGet-фид, если он был;
• инфраструктура: база, брокер и кэш поднимаются через docker compose up, для SQL Server, PostgreSQL, RabbitMQ и Redis есть готовые образы. В новых проектах эту роль берёт .NET Aspire: проект AppHost описывает сервисы кодом, запускает их одной командой и показывает логи и трассировки в дашборде;
• схема и данные: миграции через dotnet ef database update или при старте, плюс сид тестовых данных;
• конфигурация: appsettings.Development.json, ASPNETCORE_ENVIRONMENT=Development, секреты через dotnet user-secrets, а не в репозитории;
• внешние сервисы: платёжные шлюзы и чужие API подменяются заглушками вроде WireMock.Net, а интеграционные тесты сами поднимают контейнеры через Testcontainers.

Сильный ответ содержит результат: «новый разработчик запускал систему за час по README» или «свёл первый запуск к одной команде». Если локального запуска не было, так и скажите, но объясните, как вы работали: общий dev-стенд, один сервис локально, остальные на стенде, и что бы вы сделали иначе.

Этот же вопрос полезно задать работодателю самому. Ответ «только на стенде, очередь на него неделя» говорит о зрелости процессов больше, чем описание вакансии.

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

Отвечают «открываю в Visual Studio и жму F5». Это показывает, что вы не знаете, что стоит за запуском и откуда берутся зависимости.

Хранят строки подключения и ключи в appsettings.json в репозитории и рассказывают об этом как о норме.

Говорят общими словами без своих примеров. Интервьюеру нужен ваш опыт: сколько было сервисов, что мешало, что вы починили.