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 коду. Інкрементальний шлях — старе і нове працюють поруч за реверс-проксі, міграція маршрут за маршрутом — постійно приносить цінність замість заморожування команди на багатоквартальному переписуванні без результату до самого кінця.