Senior .NET Backend Developer — Вопросы на собеседовании .NET

В чём разница между workstation и server GC и когда её настраивать?

Workstation GC выполняет сборки на потоке, который их вызвал, и настроен на низкие паузы для нагрузки, близкой к UI; Server GC поднимает по куче и потоку на ядро, ориентирован на пропускную способность и является умолчанием для ASP.NET Core в большинстве сценариев хостинга. Concurrent (фоновый) GC позволяет сборкам gen 2 идти параллельно с приложением ценой части пропускной способности. За dotnet-counters и dotnet-trace идут смотреть частоту сборок и паузы, прежде чем трогать любую настройку, — настройка вслепую меняет одну проблему на худшую.

Чем Native AOT жертвует по сравнению со стандартной JIT-моделью деплоя?

Native AOT компилирует заранее в самодостаточный нативный исполняемый файл — без прогрева JIT, почти мгновенный старт, меньший размер, что важно для контейнеров, масштабирующихся до нуля, или функций, где холодный старт — ключевая метрика. Плата в том, что рефлексия в рантайме, динамическая генерация кода и некоторые сторонние библиотеки, построенные вокруг семантики JIT, либо ломаются, либо требуют явных аннотаций для trimming, а сборка становится платформозависимой. Это оправдано для чувствительного к задержкам сервиса с известным, совместимым с AOT деревом зависимостей, а не по умолчанию.

Как вы подходите к контейнеризации и деплою сервиса на ASP.NET Core в продакшн?

Многоэтапный Dockerfile собирает в SDK-образе, публикует и копирует только результат в runtime-образ ASP.NET, что заметно сокращает размер образа и убирает SDK из поверхности атаки. Конфигурация приходит из переменных окружения и менеджера секретов — Azure Key Vault, AWS Secrets Manager, — никогда не зашита в образ. В продакшне важнее самого Dockerfile — graceful shutdown через IHostApplicationLifetime, health-check эндпоинты для оркестратора и структурированные логи, отправляемые куда-то с возможностью поиска, потому что docker logs у мёртвого контейнера — не стратегия отладки.

Джуниор в вашей команде выкатил сервис, который проходит все тесты, но падает по таймауту под продакшн-нагрузкой. Как вы ведёте расследование?

Начинают с того, чем продакшн отличается от тестов, — обычно это конкурентность и объём данных, которые однопоточный прогон xUnit по умолчанию полностью скрывает. Берут dotnet-trace или APM-данные вместо догадок, потому что «похоже на базу» — так теряют часы; голодание пула потоков из-за блокирующего вызова асинхронного кода (.Result или .Wait() внутри запроса) выглядит идентично медленному запросу, пока не посмотришь на самом деле. После фикса ценнее превратить это в то, что команда может проверять автоматически — правило анализатора или пункт чек-листа код-ревью, — чтобы такой класс багов не выкатился дважды.

Как вы оцениваете, стоит ли переносить legacy-приложение на .NET Framework на современный .NET?

Начинают с того, что реально мешает — хостинг только под Windows, библиотека, вышедшая из поддержки, или настоящий потолок производительности, — потому что миграция ради миграции сжигает месяцы, не двигая продукт вперёд. .NET Framework и современный .NET расходятся сильнее всего вокруг Web Forms, WCF и некоторых библиотек, плотно завязанных на рефлексию, — ни у одной из них нет чистой замены один-в-один, поэтому реальная стоимость в инвентаризации именно этих мест, а не в основной массе обычного ASP.NET MVC/Web API кода. Инкрементальный путь — старое и новое работают бок о бок за реверс-прокси, миграция маршрут за маршрутом — постоянно приносит ценность вместо заморозки команды на многоквартальном переписывании без результата до самого конца.