Собеседование по .NET идёт между C# как языком и рантаймом под ним — CLR, сборщиком мусора, тем, как на самом деле работает async/await, — а затем переходит к ASP.NET Core и Entity Framework Core, где живёт большинство прикладных вопросов. Ниже вопросы, которые задают чаще всего, каждый с эталонным ответом. Middle: более глубокое понимание, оптимизацию и реальные рабочие ситуации.
Компилятор переписывает метод в конечный автомат: код до await выполняется синхронно, а если задача ещё не завершена, метод сразу отдаёт управление вызывающему коду и освобождает поток вместо блокировки. Продолжение возобновляется, когда задача завершится, по умолчанию в захваченном SynchronizationContext, поэтому библиотечный код вызывает ConfigureAwait(false), чтобы избежать дедлоков и лишних переключений контекста.
CLR повышает выживших объектов из поколения 0 в 1, потом в 2, собирая gen 0 дёшево и часто, а gen 2 — редко, но дорого. GC освобождает только управляемую память — неуправляемые ресурсы вроде файловых дескрипторов или соединений с базой требуют явной очистки, для чего и существуют IDisposable и финализатор как страховка: Dispose() освобождает их детерминированно, а финализатор ловит случай, когда вызывающий код забыл его вызвать.
По умолчанию каждая сущность, загруженная через DbContext, отслеживается — EF Core хранит снимок для обнаружения изменений при SaveChanges(). Для списка только на чтение это чистые накладные расходы, поэтому для чтения нужен .AsNoTracking(). Другая классическая проблема — N+1: обращение к навигационному свойству внутри цикла без Include() делает по запросу на строку.
Minimal APIs убирают церемонию контроллеров — одна лямбда app.MapGet(...) с параметрами, привязанными из маршрута, query или тела запроса, — этого достаточно для небольшого сервиса, и стартует быстрее за счёт меньшего использования рефлексии. Контроллеры отрабатывают своё, когда нужны соглашения model binding, валидация [ApiController], фильтры или большая поверхность API, где группировка действий по ресурсу держит код навигируемым.
xUnit — фреймворк по умолчанию: [Fact] для отдельного случая, [Theory] с [InlineData] для параметризованных. Зависимости заменяют моками Moq: Mock<IRepository> позволяет настроить возвращаемые значения через .Setup() и проверить вызовы через .Verify(), чтобы тест проверял класс изолированно, а не реальную базу. Ловушка — переизбыток моков: тест, который просто проверяет, что пять зависимостей были вызваны в нужном порядке, тестирует настройку моков, а не поведение.
На собеседовании ты говоришь вслух под давлением. Кем задаст эти же вопросы, оценит каждый ответ и покажет, что именно подтянуть.
Пройти интервью Middle .NET Backend Developer →