По какой методологии работали и как ставили задачи?
Что проверяют
Вторая половина вопроса важнее первой. Смотрят, участвуете ли вы в постановке задач или получаете их готовыми, и что для вас значит «задача готова к работе».
Как отвечать
Про методологию коротко и по факту: длина итерации, доска, кто расставляет приоритеты. Дальше подробно про путь задачи.
Опишите, что делаете до кода: уточняете состояния экрана, которые дизайнер обычно не рисует (пусто, загрузка, ошибка, длинный текст, нет прав), договариваетесь о контракте с бэкендом до начала работы, режете крупное на куски, которые можно влить за день.
Хорошо звучат фронтендовые детали:
- критерии готовности: адаптив, работа с клавиатуры, поведение на медленной сети;
- договорённость о заглушках, чтобы не ждать готовый бэкенд;
- фиче-флаг для незаконченного экрана, чтобы вливаться в основную ветку мелкими частями;
- что считается сделанным: ревью, тесты, проверка на стенде, а не «у меня локально работает».
Если процесс выстраивали вы сами, скажите об этом: для небольшой команды это самая сильная часть ответа.
Где спотыкаются
Отвечают только про фреймворк и молчат про себя. Вопрос поведенческий, интервьюеру нужен ваш личный вклад, а не описание доски задач.
Второе: вставляют проценты ускорения из шаблона. Цифра без методики подсчёта работает против вас. Лучше конкретика: договорились о контракте заранее и перестали переделывать экран после каждого изменения ответа сервера.
Третье: признаются, что берут в работу задачу из одной строки без макета, а потом переделывают сделанное. Ждут обратного: что сырую задачу вы возвращаете с конкретными вопросами и фиксируете ответы в ней же, а не в личной переписке.