Как начать работу над UI без готовых данных и фич?

Что проверяют

Умеете ли вы двигаться, когда бэкенд и требования ещё не готовы, и не блокируете ли команду ожиданием. От разработчика ждут не дизайн-процесса, а инженерного подхода: как отвязать интерфейс от данных, которых пока нет. Следом спросят, что вы делали, когда реальный API оказался не таким, как договаривались.

Как отвечать

Опирайтесь на свой случай и называйте конкретные решения. Каркас обычно такой:

• договориться о контракте: вместе с бэкендом зафиксировать DTO и эндпоинты, лучше в OpenAPI. Даже черновой контракт позволяет обеим сторонам работать параллельно;
• спрятать данные за интерфейсом: экран зависит от IProductService, а не от HttpClient. Пока API нет, в DI регистрируется фейковая реализация с правдоподобными данными, потом её заменяют одной строкой при регистрации сервисов;
• заглушка сервера: если нужен настоящий HTTP, поднимают мок-сервер (например, WireMock.Net) по тому же контракту, и клиент не знает, что говорит с заглушкой;
• превью без запуска: в WPF design-time данные подключаются через d:DataContext и d:DesignInstance, в Blazor страницу собирают на фейковом сервисе. Экран виден без поднятия всего приложения;
• состояния заранее: загрузка, пустой список, ошибка, очень длинные строки. На фейковых данных их легко проверить, а с живым API до них часто не доходят;
• флаги: незаконченный экран уходит в main за фиче-флагом и не мешает релизу.

Если такого опыта не было, скажите честно и опишите, как поступили бы, по тому же каркасу. Своя история с цифрами (сколько дней выиграли, сколько правок вызвала смена контракта) звучит сильнее общей схемы.

Где спотыкаются

Отвечают как дизайнер: персоны, вайрфреймы, Figma. Для разработчика на C# это мимо вопроса.

Хардкодят тестовые данные прямо во ViewModel или в разметку. Потом их выковыривают по всему проекту, и что-то обязательно уезжает в прод.

Ждут окончательного API и начинают только после него. Интервьюер слышит в этом пассивность и сорванные сроки.