О чем нужно рассказать, когда спрашивают про архитектуру проекта/приложения?
Вопрос сам по себе слишком общий. В ответ обычно надо задавать уточняющие вопросы. Про технологический стек, тип приложения, уровень детализации, слои и т.п. спросить. А уж на том, что действительно интересно собеседнику и делать акцент. Можно ещё рассказать обо всём поверхностно и по реакции понять, что действительно интересно, но спросить всё-таки лучше.
Самая серьезная ошибка на технических собеседованиях: начать отвечать на вопрос без полного понимания того, о чём вас спросили. Задавайте уточняющие вопросы, вовлекайте собеседника, рассуждайте вслух и т.д. Нормальное техническое собеседование проверяет вашу способность думать.
Вообще, универсальный рецепт при любой дискуссии, и не только на собеседовании: определить о чем и зачем вообще дискуссия. Т.е. определиться в терминах, уточнить граничные условия, уровни детализации, к чему хотим прийти и т.п. Но, предупреждаю сразу, люди вас за это любить не будут :)
Отвечай "мы стараемся придерживаться чистой архитектуры, но у нас столько легаси кода..." )))
Вообще Роберт Мартин писал, что основное преимущество ООП, что это позволило разбивать систему на части-плагины. Т.е. систама разбита на довольно независимые части которые, которые взаимодействуют  между собой через довольно устойчивые интерфейсы. 
Архитектура это как эти плагины разметить в системе.
Например чистая архитектура имеет узнаваемую структуру
в ценре бизнеслогика, вокруг вещи которые предоставляют логике данные, сохранение этих данных... вокруг различные сервиса, отображение в ui, работа с сетью, с базой данных и т.п. 
Т.е. получается слои. Важный момент, что внутренний слой не зависит от слоя который внешний. Поэтому появляется независимость от реализации от внешних слоев. И к этому появляется сравнительное простое тестирование частей системы.
Т .е. (на примере чистой архитектуры, описанной здесь совсем не точно и очень сумбурно)
Рассказ об архитектуре должен быть об разбивании системы на части и как эти части зависят друг от друга. И какие выгоды или проблемы такое разбиение дает.
Так же часто сопутствуют вопросы "как организовано взаимодействие слоя А со слоем/компонентой Б". Там скорее проверяется знаете ли вы решение типовых проблем. И шаблонов. например MVP,  MVC, MVVM, Repository и проч.