Вернуться в видеотеку

Пробное Senior C# собеседование (мок-интервью) №2

Пробное Senior C# мок-интервью с разбором теории и проектированием микросервисной inventory-системы. Во второй половине интервьюер даёт подробную обратную связь по техническим ответам и стилю архитектурного мышления кандидата.

Источник: DotNet Interview Preparation

Открыть на YouTube

Таймлайн

Коротко о видео

Это мок-интервью по Senior C#: кандидат отвечает на вопросы о многопоточности, профилировании .NET и SQL-запросов, DDD, Event Sourcing, CQRS и микросервисах. В практической части он проектирует систему управления товарами, складом и заказами с gRPC, RabbitMQ, MassTransit, API Gateway, аутентификацией и разделением сервисов на основной проект, Abstractions и Client. Затем интервьюер разбирает ответы: отдельно уточняет отличие Event Sourcing от event-driven архитектуры и советует не подставлять привычные архитектурные решения без проверки контекста задачи.

Затронутые темы

Что взять на заметку

  • Для проблем многопоточности кандидат называет корректную синхронизацию доступа к общим данным через Interlocked и примитивы синхронизации, а для снижения риска дедлоков — короткие критические секции и гарантированное освобождение ресурсов.
  • При оптимизации CPU-bound обработки полезно профилировать загрузку ресурсов и подобрать число потоков; в приведённом кандидатом примере обработка сократилась примерно с часа до 15 минут после настройки параллелизма.
  • Для Entity Framework и SQL стоит смотреть сгенерированный запрос, затем планы выполнения в БД, индексы, key lookup и структуру данных, а не ограничиваться только кодом приложения.
  • Event Sourcing не равен обмену событиями между сервисами: в обратной связи его определяют как хранение состояния через последовательность событий, из которой восстанавливается текущее состояние объекта.
  • Выбор между gRPC и RabbitMQ зависит от сценария: быстрые проверки и немедленный ответ пользователю могут требовать синхронного вызова, а длительные побочные процессы — событийной асинхронной обработки со статусами промежуточного состояния.
  • На интервью не стоит выдавать предположения вроде «чтений всегда больше записей» или «пользователь хочет» за условия задачи; сначала нужно обозначить зависимость решения от нагрузки, продукта и бизнес-требований.

Рекомендуем посмотреть