В каком виде аналитики передают требования
Что проверяют
Как вы, фронтенд-разработчик, получаете задачу и что делаете, если в ней дыры. Интервьюер проверяет, читаете ли вы требования критически, а не только верстаете по картинке. Следом спрашивают, что вы делаете, когда макет и текст задачи противоречат друг другу.
Как отвечать
Назовите форматы, с которыми работали, и что из каждого берёт фронтенд:
- пользовательская история с критериями приёмки: «как покупатель, я хочу...», а под ней проверяемые условия, часто в виде Given/When/Then. Из критериев вырастают ваши тесты и e2e-сценарии;
- макеты в Figma: состояния компонентов, адаптив, Dev Mode с отступами и токенами дизайн-системы. Проверяйте, нарисованы ли пустое состояние, загрузка и ошибка;
- спецификация API: OpenAPI, из которой генерируют типы для TypeScript (openapi-typescript, orval) и поднимают моки через MSW до готовности бэкенда;
- функциональная спецификация или ТЗ: бизнес-правила, валидации, права ролей, тексты ошибок;
- диаграммы: BPMN для процессов, диаграммы последовательности для сложных сценариев, диаграммы состояний для многошаговых форм.
Хороший ответ показывает, что вы не пассивный получатель. Вы приходите на рефайнмент, задаёте вопросы до оценки и договариваетесь о Definition of Ready: без макета всех состояний и контракта API задача не берётся. Приведите свой пример: какую дыру в требованиях нашли до разработки и сколько времени это сэкономило.
Отдельно назовите нефункциональные требования, которые аналитики часто не пишут: доступность, поддерживаемые браузеры, производительность, локализация. Их лучше уточнить самому, иначе они всплывут на приёмке.
Где спотыкаются
Перечисляют форматы как в учебнике и ни слова не говорят о своём участии. Вопрос про взаимодействие, а не про определения.
Верстают «как нарисовано» и узнают о состояниях ошибки и пустого списка только на тестировании.
Ждут готового бэкенда, чтобы начать. Если контракт согласован, фронтенд идёт параллельно на моках, и это стоит сказать вслух.