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