Собеседование по .NET идёт между C# как языком и рантаймом под ним — CLR, сборщиком мусора, тем, как на самом деле работает async/await, — а затем переходит к ASP.NET Core и Entity Framework Core, где живёт большинство прикладных вопросов. Ниже вопросы, которые задают чаще всего, каждый с эталонным ответом.
К каждому вопросу — эталонный ответ, с которым можно сравнить свой.
Value type (struct, int, bool, enum) хранит данные напрямую и копируется при присваивании; reference type (class, string, массивы) хранит указатель на данные в куче, и при присваивании копируется указатель, а не сам объект. Передача структуры в метод, который её меняет, молча работает с копией, если не передать её через ref. Структура, хранящаяся в поле класса, лежит в куче вместе с ним, а не на стеке.
Boxing оборачивает value type в объект в куче, чтобы с ним можно было работать как с object, — например, передать int туда, где ожидается object, или в нетипизированный ArrayList. Unboxing приводит его обратно и копирует значение наружу. Каждый box — это выделение памяти в куче и кандидат для сборщика мусора, поэтому цикл, боксящий миллионы int, создаёт реальную нагрузку на GC, которой дженерики полностью избегают.
До C# 8 string name и значение, которое могло быть null, выглядели одинаково, поэтому компилятор не мог предупредить, что метод, вернувший null, взорвётся тремя вызовами позже. С включёнными nullable reference types string значит «никогда не null», а string? — «может быть null», и компилятор предупреждает при разыменовании ?-типа без проверки. Гарантии на уровне рантайма это не даёт, но переводит большинство null-багов в предупреждения компиляции вместо NullReferenceException в два часа ночи.
var query = users.Where(u => u.Active) не трогает данные — строится конвейер, который выполняется, когда вы его перебираете через foreach, .ToList(), .Count() и подобное. Поэтому одна и та же переменная запроса может вернуть разные результаты, если исходная коллекция изменилась между построением и перебором, а вызов .ToList() слишком рано убивает дальнейшую фильтрацию, тогда как слишком поздний вызов на IQueryable означает повторный поход в базу при каждом переборе.
Компилятор переписывает метод в конечный автомат: код до await выполняется синхронно, а если ожидаемая задача ещё не завершена, метод сразу возвращает управление вызывающему коду, освобождая поток. Когда задача завершается, продолжение возобновляется — по умолчанию в захваченном SynchronizationContext в UI-приложениях, поэтому ConfigureAwait(false) в библиотечном коде избавляет от дедлоков. async не значит «выполняется в другом потоке» — это значит «не блокирует поток во время ожидания».
CLR группирует объекты в поколения 0, 1 и 2, исходя из наблюдения, что большинство объектов умирают молодыми — DTO в рамках запроса становится мусором за миллисекунды, а закэшированный конфиг живёт всё время работы приложения. Сборки gen 0 дешёвые и частые; выживший объект повышается до gen 1, потом до gen 2, а сборки gen 2 сканируют всю живую кучу и дороги. Объекты от 85 000 байт сразу попадают в Large Object Heap, который собирается вместе с gen 2 и по умолчанию не дефрагментируется.
Каждый запрос проходит через middleware, зарегистрированные в Program.cs, в порядке добавления — обычно обработка исключений, редирект на HTTPS, роутинг, аутентификация, авторизация, затем эндпоинт. Каждый middleware может действовать до вызова next(), после или и то и другое, и может оборвать цепочку, вообще не вызвав next(), — так аутентификация отклоняет запрос до контроллера. Порядок не косметика: авторизация до роутинга означает, что ещё нет найденного эндпоинта для проверки политик, и это бросает исключение.
Загрузка списка заказов, а затем обращение к order.Customer.Name внутри foreach без предзагрузки делает по запросу на каждый заказ — тот же N+1, что и в любом ORM. Include(o => o.Customer) чинит это через JOIN, а AsSplitQuery() — когда join размножил бы строки из-за нескольких включённых коллекций. Отслеживание изменений — смежная стоимость: EF Core делает снимок каждой отслеживаемой сущности для обнаружения изменений при SaveChanges(), что бессмысленно для списка на чтение, поэтому для чтения нужен AsNoTracking().
Transient создаёт новый экземпляр при каждом запросе. Scoped создаёт один экземпляр на HTTP-запрос и переиспользует его до конца этого запроса. Singleton создаёт один экземпляр на всё время жизни приложения. Классическая ошибка — внедрить scoped-сервис, например DbContext, в singleton: он захватывает scoped-экземпляр первого запроса и держит его вечно, что либо падает при последующем использовании, либо незаметно расшаривает состояние между несвязанными запросами.
На собеседовании ты говоришь вслух под давлением. Кем задаст эти же вопросы, оценит каждый ответ и покажет, что именно подтянуть.
Пройти интервью .NET Backend Developer →