Как ответить
В этом проекте я был fullstack-разработчиком в команде из четырёх человек. Мы делали внутренний сервис для автоматизации квартальных отчётов — чтобы аналитики не собирали данные вручную из трёх разных систем. Моя зона ответственности: бэкенд на Python (FastAPI) и немного админки на React. Первые два спринта я в основном писал эндпоинты и интеграцию с PostgreSQL, а к концу проекта подключался к фронтенду — формам загрузки файлов и визуализации статусов.
- Бэкенд-разработка. Реализовал 15 REST-эндпоинтов для CRUD-операций с отчётами и генерации выгрузки в Excel. Использовал SQLAlchemy, Alembic для миграций, Pydantic для валидации. Покрыл ключевые запросы юнит-тестами (pytest, ~40 тестов), чтобы не ломать логику при рефакторинге.
- Работа с БД. Спроектировал схему для хранения метаданных отчётов и ссылок на исходные файлы. Оптимизировал несколько медленных запросов (добавил индексы по дате и статусу) — время загрузки страницы со списком отчётов сократилось с 3 секунд до 0.4.
- Совместная работа. Каждый день участвовал в дейли-митингах (10 минут), раз в две недели — в демо. На код-ревью я проверял пул-реквесты коллег по бэкенду, обращал внимание на типизацию и обработку ошибок. В ответ получал замечания по стилю кода — это помогло быстрее привыкнуть к единому стандарту команды.
- Результат. Сервис запустили в продакшен через два месяца. Первые три квартала им пользовались пять аналитиков, ошибок в расчётах не было. После релиза я написал документацию по API для смежной команды — Swagger-спецификацию и краткую инструкцию по развёртыванию.
Главное, что я вынес из этого проекта — умение договариваться о границах задач и не бояться брать на себя ответственность за целый кусок функциональности, даже если это первый опыт с определённым инструментом.