С чего начать выполнение задачи?
Что проверяют
Есть ли у вас дисциплина до кода. Новичок открывает редактор, опытный разработчик сначала выясняет, что считается готовым, и находит противоречия, пока их дёшево исправить.
Как отвечать
Разложите по шагам и покажите, что именно уточняете:
- условие готовности: что должно работать, чтобы задачу приняли, и кто принимает;
- макет и состояния: загрузка, пустой список, ошибка, длинный текст, узкий экран. Нарисовано обычно одно удачное состояние, остальные додумывает разработчик, и лучше договориться заранее;
- данные: есть ли контракт API, что приходит при ошибке, кто владелец эндпоинта, можно ли идти параллельно с бэкендом по согласованной схеме;
- проект: нет ли готового компонента, как сделано на соседних экранах, какие правила приняты в репозитории;
- объём: разбить на части и назвать, что войдёт в первую итерацию, если работы больше чем на пару дней;
- проверка: что покрывается тестами, что смотрится руками, нужны ли доступность и вторая локаль.
Только после этого ветка и код. Отдельно скажите, что на длинной задаче показываете промежуточный результат, не дожидаясь готовности: ранняя обратная связь дешевле переделки.
Где спотыкаются
Начинают с кода и через день узнают, что ответ сервера устроен иначе или макет успели обновить. Пятнадцать минут вопросов экономят день работы.
Видят в задаче противоречие и решают его молча. Решение почти всегда расходится с ожиданием заказчика, а обнаруживается это на демонстрации.
Не смотрят, что уже есть в проекте, и добавляют третий вариант кнопки со своим поведением. Интерфейс расползается, а ревью превращается в спор о том, что следовало переиспользовать.