Участвовал ли ты в оценке задач
Что проверяют
Умеете ли вы декомпозировать задачу до кусков, которые реально оцениваются, и видите ли за формулировкой «добавить поле» миграцию схемы, совместимость контракта и тесты. Это вопрос про инженерную зрелость, а не про методологию.
Как отвечать
Покажите разбор задачи по слоям: изменение модели и миграция базы, слой доступа к данным, бизнес-логика, контракт API и его версия, интеграция со смежным сервисом, модульные и интеграционные тесты, логи и метрики, выкатка. Оценка появляется после такого разбора, а не до него.
Сразу назовите то, что обычно съедает время помимо кода: согласование контракта со смежной командой, ожидание доступов, разворачивание стенда, ревью и правки после него. Отдельно стоит упомянуть совместимые миграции: добавили колонку без блокирующего дефолта, наполнили пачками, переключили чтение, и только потом убрали старое. Это несколько выкладок, а не одна строка в файле.
Формат оценки: относительные стори-поинты на покере планирования, и обсуждение расхождений как главная часть встречи. Для новых для команды технологий честнее заложить отдельное время на исследование, а не растворять его в общей оценке.
Полезно упомянуть привычку сравнивать оценку с фактом на ретроспективе: без этого команда годами ошибается в одну и ту же сторону.
Где спотыкаются
Оценивают только написание кода. Ревью, правки после ревью, тесты, накатка миграции и разбор падений на стенде в цифру не входят, и задача стабильно выезжает за спринт.
Дают уверенную одиночную цифру, а потом объясняют срыв изменившимися требованиями. Правильнее назвать допущения: контракт зафиксирован, схема без блокировок, смежный сервис отвечает.
Приносят придуманный результат вроде «точность оценок выросла на двадцать процентов». Такое не измеряют, и вопрос про методику замера топит ответ. Честнее сказать, что задачи перестали переезжать через спринт.