Какими инструментами генерировали отчеты
Что проверяют
Какую задачу вы решали отчётом и насколько глубоко были в процессе: писали запросы, верстали шаблон, думали про объём данных. Следом обычно спрашивают, как вы строили тяжёлый отчёт так, чтобы он не положил сервис.
Как отвечать
Начните с типа отчёта, от него зависит инструмент:
- файлы для выгрузки: Excel через ClosedXML или Open XML SDK, PDF через QuestPDF, Word через Open XML SDK. У EPPlus с пятой версии коммерческая лицензия, QuestPDF бесплатен только для небольших компаний, это стоит проверять заранее;
- отчётные серверы и дизайнеры: SSRS, FastReport. Удобны, когда шаблоны правят аналитики без релиза приложения;
- BI: Power BI или аналоги, если нужны интерактивные дашборды, а не файл;
- Crystal Reports: встречается в основном в старых проектах на .NET Framework, для новых его выбирают редко.
Затем процесс: агрегаты считаются в SQL, а не в LINQ поверх ToList(), большие выборки читаются потоково (AsAsyncEnumerable() в EF Core или небуферизованные запросы Dapper), тяжёлый отчёт строится в фоне через BackgroundService или Hangfire, а пользователь получает ссылку на готовый файл.
Пример берите свой и с цифрами, которые можете объяснить: «ежемесячная выгрузка на 200 тысяч строк падала по таймауту, перенесли её в фоновую задачу и писали файл через OpenXmlWriter». Если отчётов вы не делали, так и скажите и расскажите, как подошли бы к задаче. Это лучше выдуманной истории.
Где спотыкаются
Строят отчёт синхронно внутри HTTP-запроса. На больших периодах запрос упирается в таймаут, а память сервиса растёт на весь объём выгрузки.
Забывают про лицензии. Библиотеку подключили на прототипе, а перед релизом выясняется, что коммерческое использование платное.
Рассказывают только про инструмент. Интервьюеру интереснее, откуда брались данные, как проверялась правильность цифр и кто принимал отчёт.