Расскажите про опыт взаимодействия с базами данных

Что проверяют

Писали ли вы что-то сложнее выборки по идентификатору и понимаете ли, что происходит между вашим кодом и базой.

Как отвечать

Разложите ответ по темам, а не по местам работы.

• СУБД и почему она: PostgreSQL, SQL Server, что использовали и какие её особенности задействовали;
• способ доступа: EF Core для основной логики, Dapper там, где нужен точный контроль над запросом и скоростью. Скажите, почему выбирали каждый: EF даёт миграции, отслеживание изменений и типизацию, Dapper даёт предсказуемый SQL без сюрпризов;
• миграции: как накатываются, как ведёте себя при несовместимых изменениях, применяете ли отдельным шагом выкладки или из приложения;
• производительность, и это ключевая часть: как находили медленные запросы (план выполнения, счётчик обращений), что чинили. Назовите проблему N+1 и как её ловите, AsNoTracking для чтения, проекции через Select вместо загрузки полной сущности, ExecuteUpdate и ExecuteDelete для пакетных операций вместо цикла с сохранением;
• транзакции и конкурентность: уровни изоляции, оптимистичная блокировка через rowversion, что делали при конфликте;
• тестирование: Testcontainers с настоящей базой. Тут же стоит сказать, почему провайдер в памяти вводит в заблуждение: он не проверяет ни SQL, ни ограничения, ни транзакционное поведение;
• эксплуатация: пул соединений и его исчерпание, таймауты, что делать с блокировками.

Обязательно дайте один конкретный случай: был запрос на несколько секунд, посмотрел план, увидел полное сканирование, добавил составной индекс, время упало до десятков миллисекунд. Такой эпизод убеждает сильнее списка технологий.

Где спотыкаются

Называют технологии, но не могут описать ни одной решённой задачи.

Не знают, как посмотреть сгенерированный EF запрос.

Не слышали про N+1 или не умеют его обнаружить.

Тестируют репозитории на провайдере в памяти и считают это проверкой работы с базой.