Вопросы на собеседовании .NET-разработчика

Пример сильного ответа

Значимые типы — это структуры: значение хранится прямо в переменной или внутри объекта, при присваивании копируется целиком, и по умолчанию это не ссылка на общий объект. Ссылочные типы живут в управляемой куче, переменная держит ссылку, а копирование передаёт только ссылку. Упаковка — это приведение значимого типа к object или к интерфейсу: среда создаёт объект в куче и копирует туда значение, а распаковка возвращает копию обратно. Это лишние аллокации и давление на сборщик мусора, поэтому в горячем коде я держу generic-коллекции и избегаю object. На обработке 500 000 записей переход с ArrayList на List<int> снизил потребление памяти примерно на треть.

• Показана модель памяти, а не заученное определение
• Упаковка объяснена через последствия для производительности
• Есть личный пример с измеримым результатом

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Выбор зависит от того, нужно ли переиспользовать общее состояние и реализацию. Интерфейс беру, когда важен только контракт: несколько несвязанных типов должны его реализовать, нужна подмена в тестах и слабая связанность. Абстрактный класс — когда есть общие поля и каркас алгоритма, а наследники уточняют отдельные шаги; но наследование в языке только одно. В одном проекте базовая обработка отчётов отличалась лишь форматом вывода, и общий алгоритм с абстрактным методом сериализации убрал дублирование, а интеграции с внешними сервисами мы оставили интерфейсами: четыре реализации подменяются в тестах, покрытие выросло до 80%.

• Дан критерий выбора, а не формальный ответ
• Учтено ограничение одиночного наследования
• Подкреплено примером из практики

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Метод с async компилятор превращает в конечный автомат. Дойдя до await, среда проверяет задачу: если она уже завершена, продолжение идёт синхронно, если нет — управление возвращается вызывающему, поток освобождается, а продолжение ставится в очередь к контексту синхронизации. Обращение к .Result блокирует поток: в приложениях с контекстом синхронизации это даёт взаимную блокировку, а в пуле потоков — их голодание и падение пропускной способности. Поэтому я провожу async по всей цепочке, использую Task.WhenAll и ConfigureAwait(false) в библиотеках. После перевода синхронных HTTP-вызовов на async при 300 одновременных запросах время отклика сократилось примерно втрое.

• Объяснена механика конечного автомата и контекста
• Названы обе причины опасности .Result
• Есть практики и цифра результата

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Сборщик мусора в .NET трассирующий и поколенческий: он определяет живые объекты по ссылкам от корней, а не по счётчикам, и уплотняет память. Поколение 0 — короткоживущие объекты, собирается часто и дёшево; поколение 1 служит буфером; поколение 2 — долгоживущие объекты, его сборка дорогая. Крупные объекты попадают в отдельную кучу больших объектов, которая по умолчанию не уплотняется, поэтому там возможна фрагментация. На практике я сокращаю аллокации: переиспользую буферы через пулы, избегаю временных больших массивов. На сервисе с нагрузкой около 2000 запросов в секунду это заметно снизило частоту длинных пауз.

• Раскрыты поколения, куча больших объектов и уплотнение
• Показано, как кандидат снижает давление на GC
• Есть цифра нагрузки и наблюдаемый результат

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

IEnumerable описывает перечисление объектов в памяти: LINQ к нему компилируется в делегаты и выполняется на стороне приложения. IQueryable хранит дерево выражений, и провайдер транслирует его в запрос к источнику, например в SQL, поэтому фильтрация и проекция выполняются на сервере. Отложенное выполнение означает, что запрос строится, но не исполняется, пока его не начнут перечислять: foreach, ToList, Count. Отсюда риск случайно вытянуть всю таблицу, если после запроса к базе добавить свой метод или фильтр в памяти. В одном проекте мы перенесли фильтрацию до ToList и добавили проекцию в Select: вместо десятков тысяч строк приходит около 200, ответ ускорился с секунд до десятков миллисекунд.

• Чётко разделены модель памяти и провайдер запросов
• Объяснено отложенное выполнение и его риск
• Пример с конкретным ускорением

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Во встроенном DI-контейнере .NET есть три времени жизни: Transient, Scoped и Singleton. Transient создаётся при каждом запросе, Scoped — один экземпляр на область, обычно на HTTP-запрос, Singleton — один на всё приложение. На практике я чаще всего использую Scoped для репозиториев и DbContext, Singleton — для кэшей и конфигурации, Transient — для лёгких stateless-сервисов. В проекте при переходе с Transient на Scoped для сервиса доступа к базе число открытых соединений удаётся сократить примерно на 30 процентов, нагрузка заметно снижается. Главное — не внедрять Scoped в Singleton напрямую, иначе получаем captive dependency.

• Чётко перечислены все три времени жизни и их назначение.
• Приведён практический пример с измеримым результатом.
• Показано понимание captive dependency — типичной ошибки.

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Запрос приходит на сервер, дальше идёт цепочка middleware в порядке регистрации: обработка исключений, HSTS, статика, аутентификация, авторизация, маршрутизация. UseRouting сопоставляет путь с endpoint, UseEndpoints его выполняет. Затем подключаются фильтры: authorization, resource, action, exception и result — они привязаны к конкретному действию и умеют работать с его аргументами. Внутри — model binding, валидация, вызов действия, формирование результата. Ключевой момент: middleware видит только HttpContext, а фильтры — контекст действия. Поэтому замер времени выполнения действия ставлю фильтром, а не middleware.

• Порядок конвейера изложен корректно и по шагам
• Чётко разделены middleware и фильтры
• Есть практический вывод про логирование

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Ориентируюсь на область действия и на то, нужен ли доступ к контексту действия. Middleware — когда логика касается всего трафика и не знает про MVC: CORS, сжатие, сквозной correlation-id, обработка исключений, ограничение частоты запросов. Фильтры и атрибуты — когда важно знать действие, его аргументы, модель или результат: валидация входных данных, проверка прав на конкретную операцию, кэширование ответа, единый формат ошибок. В одном проекте перенос части проверок из middleware в фильтр убрал дублирование в сорока действиях и сократил код почти вдвое.

• Дан чёткий критерий выбора между middleware и фильтрами
• Приведены уместные примеры для каждого варианта
• Подкреплено измеримым результатом

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Это когда на запрос списка сущностей приходится ещё по запросу на каждую связанную сущность вместо одного join. Нахожу по логам: включаю логирование EF Core и смотрю, сколько SQL уходит на одну операцию. Ещё помогает профилировщик на стенде с реалистичным объёмом данных. Устраняю через Include и ThenInclude, проекцию в DTO через Select, а для сложных выборок — split query, если один join раздувает результат. На одном отчёте такая правка снизила число запросов с нескольких сотен до трёх, а время ответа — примерно в пять раз.

• Верно объяснена суть проблемы
• Названы конкретные способы диагностики
• Есть измеримый результат до и после

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Работаю по схеме обратно совместимых изменений и раскатываю их этапами. Сначала аддитивный шаг: добавляю новую колонку или таблицу как nullable, при необходимости с дефолтом, и заполняю данные отдельным скриптом батчами. Дальше приложение учится писать в оба места, потом переключается на новое. И только на следующем релизе удаляю старое. Миграции применяю отдельным шагом деплоя, а не на старте приложения, и перед этим снимаю бэкап. Так на таблице в несколько десятков миллионов строк переезд обошёлся без простоя и без потери данных.

• Описан безопасный поэтапный подход к изменениям схемы
• Учтены бэкап и отдельный шаг применения миграций
• Есть результат на большом объёме данных

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Обычно начинаю с плана выполнения: смотрю, где оптимизатор ошибается — сканирование вместо поиска, лишние сортировки, неверная оценка числа строк. Дальше проверяю статистику и индексы, ожидания сессии и блокировки, при необходимости снимаю трассировку через Extended Events. В одном проекте отчёт тормозил на 8 секунд из-за отсутствующего покрывающего индекса: после его добавления время упало до 200 миллисекунд. Отдельно проверяю, не изменился ли план после обновления статистики и не вырос ли объём данных. Выводы фиксирую в тикете, чтобы похожие запросы не всплывали снова.

• Показан системный порядок диагностики, а не гадание
• Есть конкретные метрики до и после оптимизации
• Упомянуты инструменты, знакомые любому .NET-разработчику

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Транзакция — это набор операций, который либо применяется целиком, либо откатывается. Уровни изоляции задают, какие аномалии чтения допускаются: грязное чтение, неповторяющееся чтение, фантомы. По умолчанию чаще всего работает read committed, но для критичных участков мне приходилось применять snapshot и явные блокировки. Без транзакций не обойтись там, где деньги, остатки на складе, бронирования: списание и зачисление должны быть атомарны. Но важнее не выбрать уровень, а держать транзакции короткими: сокращение длинной транзакции с 3 секунд до 50 миллисекунд убрало блокировки при пиковой нагрузке.

• Сначала определение, потом практика — логичный порядок мысли
• Показано понимание компромисса между изоляцией и блокировками
• Есть измеримый результат оптимизации

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Версионирую через URL-сегмент, например v1 и v2: так проще и клиентам, и логированию. Валидацию делаю декларативно, через атрибуты и FluentValidation, с единым форматом ответа об ошибке — код, сообщение, список полей. Исключения ловлю в middleware: бизнес-ошибки превращаются в понятные коды 4xx, неожиданные — в 500 с correlation id для поиска в логах. Наружу отдаю только отдельные DTO, модели базы не публикую. В одном проекте такой подход сократил число обращений в поддержку по интеграции примерно на треть. Документацию держу в Swagger с примерами.

• Названы все четыре зоны: версии, валидация, ошибки, контракты
• Есть бизнес-эффект, а не только технические детали
• Упоминаются понятные инструменты из экосистемы .NET

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Делю не по слоям, а по бизнес-возможностям: у каждого сервиса своя зона ответственности и своя база, чтобы не было общих таблиц. Границы определяю по домену, спорные места сначала разбираю на схеме взаимодействия. Связь строю асинхронно через брокер для событий и синхронно по HTTP только там, где ответ нужен сразу. Чтобы не тянуть распределённые транзакции, использую саги и идемпотентные обработчики. В проекте с 6 сервисами такой подход позволил командам выпускать изменения независимо, и релизный цикл сократился с двух недель до нескольких дней.

• Показано понимание границ по домену, а не по технологиям
• Есть ответ на главную боль — распределённые транзакции
• Результат измерен в скорости релизов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Первое — таймауты: без них зависший вызов держит потоки. Дальше повторные попытки с экспоненциальной задержкой и джиттером, и только для идемпотентных операций. Circuit breaker разрывает поток к упавшей зависимости, а bulkhead ограничивает число одновременных вызовов, чтобы отказ одной интеграции не утянул весь сервис. Плюс кэш на время недоступности и осознанная деградация: показать частичные данные вместо ошибки. Обязательны метрики и алерты по ним. После внедрения такого набора в одном проекте доля неуспешных запросов к внешней интеграции упала с 4% до 0,3%.

• Перечислены конкретные паттерны устойчивости, а не общие слова
• Упомянута идемпотентность — ключевая деталь для повторов
• Есть измеримое улучшение надёжности

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В .NET чаще всего применяю двухуровневое кеширование: локальный IMemoryCache для самых горячих данных и распределённый Redis через IDistributedCache — для того, что должно быть общим для всех инстансов. Кеширую справочники, результаты тяжёлых агрегаций и каталог. Инвалидацию решаю комбинацией приёмов: короткий TTL, версионирование ключей и событие в шине — при изменении данных сервис публикует сообщение, и все инстансы сбрасывают свои ключи. Плюс отдельно слежу, чтобы у кеша были лимит по размеру и метрики попаданий. На одном сервисе это дало hit rate около 95% и снизило p95 ответа каталога с 400 до 30 миллисекунд.

• Показаны два уровня кеша и конкретные инструменты .NET
• Инвалидация раскрыта через TTL, версии и события
• Есть измеримый результат: hit rate и p95

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Начинаю не с профилировщика, а с метрик и трейсов: смотрю p95 и p99, работу сборщика мусора, потребление CPU и количество запросов к базе по операциям. Для .NET беру dotnet-counters и OpenTelemetry, дальше — dotnet-trace и dotnet-dump, когда нужно понять распределение времени по методам или состояние кучи. Микробенчмарки делаю через BenchmarkDotNet, а нагрузочные проверки — на staging, чтобы гипотезу можно было подтвердить до прода. Чаще всего узкое место — N+1 в EF Core или лишние аллокации. В одном случае AsNoTracking с проекцией в DTO убрало N+1: p95 упал с 1,2 секунды до 250 миллисекунд.

• Назван конкретный стек инструментов для .NET
• Видна логика: метрики, затем профилирование, затем проверка
• Есть числовой результат оптимизации

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

У нас многоэтапная сборка: отдельный образ SDK компилирует и публикует приложение, а в финальный образ копирую только результат — на базе aspnet-runtime, с непривилегированным пользователем и без лишних слоёв. Сначала копирую только файлы проектов, чтобы кешировались слои восстановления пакетов. В CI на каждый коммит идут сборка, юнит- и интеграционные тесты, статический анализ, затем сборка образа и пуш с тегом по хешу коммита. Дальше авто-деплой на staging, смоук-тесты и раскатка на прод скользящим обновлением с health-check. Откат — возврат предыдущего тега образа. Полный цикл занимает около шести минут.

• Раскрыты и Docker, и CI/CD, а не что-то одно
• Показано понимание кеша слоёв и непривилегированного пользователя
• Есть план отката и время цикла

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.