Співбесіда з .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 →