Как подготовиться к архитектурному собеседованию?

Тема вопросов с собеседований актуальна всегда и для всех, в частности ко мне обратился один из подписчиков, поэтому с его разрешения публикую вопрос. Ему назначили архитектурный собес, который состоит из двух частей: 1 — «Есть компания (рандомная сфера). Нужно придумать модель для их БД. 6-8 таблиц. Попутно объясняя, почему делаешь так или иначе»

2 — «Дают готовую схему БД и просят спроектировать витрину. Задание дают специально очень расплывчатое, чтобы проверить навык, как ты общаешься и собираешь требования (четкого ТЗ нет). После сбора требований пишешь sql запрос для витрины»

Как бы я готовилась и отвечала на такие вопросы?

По первому вопросу — точно повторила бы нормализацию данных и шла бы по ней, рассказывая для чего нужна та или иная таблица, что в ней содержится, как одна таблица связана с другой (какой вид связи, по какому ключу). Далее, в зависимости от удовлетворенности слушателей, разгоняла бы тему в сторону улучшения БД через разные архитектурные подходы. Например, при увеличении количества запросов к одной из таблиц, при увеличении объема данных и т.п. Тут повторила бы про OLAP/OLTP, Data Warehouse (Data Vault, Anchor). Совет! Обратите внимание, что в вакансии указано в качестве архитектурного подхода или, может быть, где-то в их блогах была статья про это, и стройте свой рассказ, уделяя больше времени этому подходу.

По второму вопросу — начала бы с вопросов про источник данных. Необходимо узнать, где лежат данные: какая БД / какой слой данных, схема/таблицы, как запросить доступы, частота обновления, партиционирование данных. Далее узнала бы про доступность данных и их обновление: кто ответственный за данные, есть ли оповещения, если данные «сломались» или не собрались. Далее, как правильно обращаться к данным: есть ли справочники, узнать ключ и как выбирать актуальную запись (вдруг там есть версионирование). Запросила бы глоссарий, чтобы лучше разбираться в значениях нейминга полей. После того, как с источником разобрались, приступила бы к сбору требований по тому, как должна выглядеть витрина: какие поля она должна содержать, какой уровень агрегации, за какой период необходимы данные. Также важно узнать, какие запросы планируют к ней выполнять, например, собирать месячную или дневную статистику (тут продумываем, что будет отдаваться, если у нас нет значений 0/null, поле партиционирования). Достаточно ли вывести идентификаторы в витрину или необходимо заранее предусмотреть вывод значений из справочника/другой таблицы. Что планируется делать с витриной дальше: одноразовый сбор или необходимо поставить на обновление? Тут уточняем, как часто необходимо обновлять данные и каким образом (инкремент, полная перезапись), необходимо ли настройка оповещений.

Как бы вы подготовились к архитектурному собеседованию и что бы вы ответили на такие вопросы? 👀