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