Как подготовиться к архитектурному собеседованию?
Тема вопросов с собеседований актуальна всегда и для всех, в частности ко мне обратился один из подписчиков, поэтому с его разрешения публикую вопрос. Ему назначили архитектурный собес, который состоит из двух частей: 1 — «Есть компания (рандомная сфера). Нужно придумать модель для их БД. 6-8 таблиц. Попутно объясняя, почему делаешь так или иначе»
2 — «Дают готовую схему БД и просят спроектировать витрину. Задание дают специально очень расплывчатое, чтобы проверить навык, как ты общаешься и собираешь требования (четкого ТЗ нет). После сбора требований пишешь sql запрос для витрины»
Как бы я готовилась и отвечала на такие вопросы?
По первому вопросу — точно повторила бы нормализацию данных и шла бы по ней, рассказывая для чего нужна та или иная таблица, что в ней содержится, как одна таблица связана с другой (какой вид связи, по какому ключу). Далее, в зависимости от удовлетворенности слушателей, разгоняла бы тему в сторону улучшения БД через разные архитектурные подходы. Например, при увеличении количества запросов к одной из таблиц, при увеличении объема данных и т.п. Тут повторила бы про OLAP/OLTP, Data Warehouse (Data Vault, Anchor). Совет! Обратите внимание, что в вакансии указано в качестве архитектурного подхода или, может быть, где-то в их блогах была статья про это, и стройте свой рассказ, уделяя больше времени этому подходу.
По второму вопросу — начала бы с вопросов про источник данных. Необходимо узнать, где лежат данные: какая БД / какой слой данных, схема/таблицы, как запросить доступы, частота обновления, партиционирование данных. Далее узнала бы про доступность данных и их обновление: кто ответственный за данные, есть ли оповещения, если данные «сломались» или не собрались. Далее, как правильно обращаться к данным: есть ли справочники, узнать ключ и как выбирать актуальную запись (вдруг там есть версионирование). Запросила бы глоссарий, чтобы лучше разбираться в значениях нейминга полей. После того, как с источником разобрались, приступила бы к сбору требований по тому, как должна выглядеть витрина: какие поля она должна содержать, какой уровень агрегации, за какой период необходимы данные. Также важно узнать, какие запросы планируют к ней выполнять, например, собирать месячную или дневную статистику (тут продумываем, что будет отдаваться, если у нас нет значений 0/null, поле партиционирования). Достаточно ли вывести идентификаторы в витрину или необходимо заранее предусмотреть вывод значений из справочника/другой таблицы. Что планируется делать с витриной дальше: одноразовый сбор или необходимо поставить на обновление? Тут уточняем, как часто необходимо обновлять данные и каким образом (инкремент, полная перезапись), необходимо ли настройка оповещений.
Как бы вы подготовились к архитектурному собеседованию и что бы вы ответили на такие вопросы? 👀
· 03.12.2025
Судя по контенту поста мне уже понятно почему медицинский софт лагает безбожно, выдержки врачей из техподдержки ЕМИАС приводить не буду...
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 04.12.2025
А можно подробнее? Я не работала с медицинскими данными, хотела бы узнать про контекст проблемы
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён