Расскажите про опыт разработки сложного UI

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

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

Как отвечать

Назовите технологию и почему именно она: WPF или Avalonia для настольных приложений, WinForms в поддержке старого, MAUI и Blazor там, где нужен общий код. Дальше по существу:

• разделение через MVVM: вьюмодель хранит состояние и команды, представление только привязки. Тестируемость тут не лозунг, это возможность прогнать сценарий экрана без запуска окна;
• привязки: INotifyPropertyChanged, ObservableCollection, валидация через INotifyDataErrorInfo, преобразователи значений;
• длинные операции всегда асинхронно, результат возвращается в поток интерфейса, а на время загрузки у экрана отдельное состояние;
• большие списки живут на виртуализации, при массовом обновлении коллекция пересобирается одним присваиванием, а не сотней добавлений;
• стили, шаблоны и ресурсы вынесены, чтобы повторяющиеся блоки не копировались.

Про сложный экран интереснее всего услышать, как вы его разбирали на части: отдельные вьюмодели для областей, обмен через сервис или события, а не одна огромная вьюмодель на всё окно.

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

Блокируют поток интерфейса. Синхронное ожидание результата задачи прямо в обработчике подвешивает окно, а в связке с контекстом синхронизации ещё и приводит к взаимной блокировке, которую потом ловят неделями.

Второе: обновляют привязанную коллекцию поэлементно и отключают виртуализацию, чтобы «заработала прокрутка». Каждая операция тянет пересчёт разметки, и список на несколько тысяч строк перестаёт открываться.

Третье: пишут логику в code-behind, а вьюмодель заводят для галочки. Такой экран нельзя ни протестировать, ни переиспользовать, а ошибки привязок при этом нигде не видны: они молча гасятся и попадают разве что в окно вывода отладчика.