Кто формулировал задачи и как они декомпозировались
Что проверяют
Как был устроен процесс на прошлом месте и какую роль в нём играли вы: получали готовые тикеты или сами участвовали в разборе требований и оценке. Интервьюер хочет понять, насколько вы самостоятельны. Следом часто просят разобрать одну конкретную задачу: как её разбили и почему именно так.
Как отвечать
Опишите цепочку честно, с ролями:
- источник задач: продакт-менеджер, аналитик, техлид или заказчик. Скажите, в каком виде приходило: эпик в Jira, ТЗ, пользовательская история с критериями приёмки;
- обсуждение: груминг или refinement, где команда задаёт вопросы и оценивает в стори-поинтах или часах, затем планирование спринта;
- ваше участие: писали ли вы технический дизайн, оценивали, разбивали эпик на задачи, заводили задачи на технический долг.
Дальше покажите декомпозицию на Java-примере. Скажем, «приём платежа»: миграция схемы через Liquibase или Flyway, сущность и репозиторий на Spring Data JPA, клиент к платёжному API с таймаутами и повторами, REST-эндпоинт, обработка вебхука с идемпотентностью, публикация события в Kafka, интеграционные тесты на Testcontainers, метрики и алерты. Хороший принцип: каждая задача законченная, её можно проверить и влить отдельно, при необходимости за фича-флагом, и она укладывается в пару дней.
Закончите результатом своими словами и своими цифрами. Если процент придумать нечем, лучше без него: сдали к релизу, откатов не было, задачу параллельно вели три человека.
Если задачи всегда приходили готовыми, так и скажите, но добавьте, где вы уточняли требования или сами находили в них пробелы.
Где спотыкаются
Отвечают «задачи ставил менеджер, я их делал». Это сигнал о пассивной позиции, даже если процесс действительно был таким.
Декомпозируют по слоям: «сначала весь бэкенд, потом весь фронт». Такие задачи нельзя проверить по отдельности, а проблемы интеграции всплывают в самом конце.
Приводят выдуманную метрику вроде «заказы выросли на 20%». Первый же вопрос о том, как это посчитали, разваливает рассказ.