Используются ли RFC в проекте
Что проверяют
Работаете ли вы в команде, где решения обсуждают до кода, и участвует ли в этом тестирование. Под RFC здесь почти всегда имеют в виду внутренний документ с предложением изменения, а не стандарты IETF. Следом обычно спрашивают, что вы как QA делаете с таким документом.
Как отвечать
Коротко скажите, что такое RFC в продуктовой команде: автор описывает проблему, предлагаемое решение, отвергнутые альтернативы, риски и план выкатки, а команда комментирует документ до начала разработки. Принятое решение часто фиксируют отдельно в ADR.
Дальше главное, ваша роль:
- тестируемость: как проверить изменение, нужны ли тестовые данные, заглушки внешних систем, отдельный стенд;
- нефункциональные требования: нагрузка, обратная совместимость API, миграция данных, поведение при отказе зависимостей;
- выкатка: есть ли фича-флаг, как откатываться, какие метрики и логи покажут, что всё работает;
- раздел о тестировании: стратегия, уровни тестов, что автоматизируем, какие регрессионные зоны задевает изменение.
Опишите один реальный случай: какой документ, какой вопрос вы задали и что после этого поменялось в решении. Детали нужны свои.
Если в проекте RFC нет, так и скажите и назовите, что их заменяло: техническое описание в Confluence, дизайн-ревью на встрече, описание в эпике Jira. Покажите, на каком этапе вы включались.
Второе значение тоже стоит упомянуть: при тестировании API сверяются с настоящими RFC. Семантика HTTP и коды ответов описаны в RFC 9110, формат JSON в RFC 8259, дата и время в RFC 3339, JWT в RFC 7519.
Где спотыкаются
Отвечают только про стандарты IETF и не замечают, что вопрос про процесс в команде. Уточнить, какое значение имеет в виду интервьюер, нормально.
Говорят, что RFC пишут разработчики, а тестировщик получает готовую задачу. Для QA это слабая позиция: ошибку в решении дешевле всего найти ещё в документе.
Рассказывают общими словами «RFC улучшают коммуникацию» без примера. Интервьюеру нужен конкретный вопрос, который вы подняли, и то, к чему он привёл.