Коллега поделился тренажером для кодинга и прохождения собесов на основе ИИ — https://app.heychar.ai/

Будет полезным, если хотите проверить себя, освежить знания или узнать насколько вы «в рынке».

Также ребята сейчас планируют листиться на Product Hunt, поэтому если будут мнения или идеи, то можно оставить фидбек тут: @info_hey_char

Bare Minimum Monday

Половина рабочего дня уже позади, а еще ничего не сделано? Предлагаю еще немного почиллить и почитать эту статью.
Вкратце, в статье психолог приводит преимущества "понедельника с минимальными усилиями" (Bare Minimum Monday). Он предлагает начать неделю с выполнения только самых необходимых задач, чтобы снизить уровень стресса и избежать выгорания. Такой подход помогает лучше распределить энергию и повысить продуктивность в течение всей недели.
Основные идеи:
— Снижение стресса: Начав понедельник с простых дел, можно уменьшить чувство перегрузки и тревожности.
— Улучшение настроения: Постепенное погружение в рабочие задачи позволяет настроиться на более позитивный лад.
— Управление энергией: Сохраняя силы для важных дел позже, человек может быть более эффективным в долгосрочной перспективе.
— Предотвращение выгорания: Постепенный вход в рабочую неделю снижает риск эмоционального истощения.
— Психологическая подготовка: Легкий старт помогает легче адаптироваться к рабочим обязанностям после выходных.

Вообще согласна, что после выходных бывает сложно войти в рабочий ритм, практически невозможно сразу же сесть и, например, начать писать код (только в случае, если что-то сломалось 😐). Поэтому мой лайфхак не зря потраченного понедельника - это запланировать несколько чилловых встреч для разгона. Так и рабочая повесточка восстановится, и не совсем бесполезно день пройдет.

Как быстро вливаетесь в рабочий процесс после выходных? 🥺

Привет! Сегодня настроение пятничное и совсем неижнереное, поэтому делюсь свежими рекомендациями 🥰.

Из художественной литературы: буквально на днях закончила читать «К востоку от Эдема» и открыла для себя Джона Стейнбека. Вообще познакомилась с ним по книге «Неведомому богу», но она меня не сильно впечатлила. Но, что касается «К востоку от Эдема», то, пожалуй, эта книга одна из лучших за последнее время. Мне сложно кратко сформулировать ее суть, потому что история очень всеобъемлющая и масштабная. Но если вы любите что-то философское про свободу выбора, судьбу человека с библейскими аллюзиями и семейные разборки, как основу, то тогда highly recommended.

Из подкастов: в реках spotify обнаружен подкаст СОБЕС от Либо Либо (вроде есть в яндекс музыке тоже). Истории про собеседования в среднем по 40 минут, так что самое то послушать в дороге или на дорожке. Я послушала пару последних выпусков за ноябрь 24, звучит интересно. Оставляю ссылочку на выпуск с дата инженером.

Из культурно-развлекательного: «Чагин» в Современнике по Евгению Водолазкину. Сразу же предупреждаю, что постановка идет почти 4 часа, что очень сложно пережить после рабочего дня 🥴. Но! Это сто процентов того стоило, потому что за это время удалось прожить маленькую жизнь вместе с героями, и вообще эта история не выходит у меня из головы уже который день.

5 шагов как перестать бояться shuffle в spark

Про shuffle в spark часто спрашивают на собеседованиях и мучают вопросами в стиле: где смотреть, куда копать. Обычно такие вопросы идут в связке с проблемой data skew, которую я ранее разобрала тут.

Шаг 1. Разбираемся, что такое shuffle
Shuffle - это процесс перераспределения данных между партициями и нодами кластера. Он возникает, когда данные нужно сгруппировать, отсортировать или объединить (например, при join, groupBy, orderBy).

Почему он происходит?
Данные физически разбросаны по нодам и для их обработки нужно собрать их по ключу. Пример: чтобы посчитать сумму продаж по каждому региону (`groupBy("region").sum()`), spark должен собрать все записи одного региона в одну партицию.

Шаг 2. Узнаем, когда shuffle неизбежен
Операции, которые вызывают shuffle:
— groupBy, reduceByKey, distinct (агрегация).
— join (если данные не колокализованы, т.е. физически не расположены в одних и тех же партициях или на одних нодах).
— orderBy, repartition.

Шаг 3. Уверенно оптимизируем shuffle
3.1. Как уменьшить объем shuffle?
— Broadcast Join для маленьких таблиц. Если одна из таблиц помещается в память, её можно разослать на все ноды, избежав shuffle.
— Ранняя фильтрация и агрегация. Удаляем ненужные данные до операций с shuffle - это снизит нагрузку.

3.2. Настройка партиций
Вспоминаем чем отличается repartition и coalesce:
df.repartition(200, "key") # Увеличивает число партиций
df.coalesce(100) # Уменьшает без Shuffle

Правильное партицирование ускоряет Shuffle, распределяя данные равномерно.

3.3. В любой непонятной ситуации применяем AQE

Шаг 4. Контролируем процесс
▫️Что смотреть в Spark UI:
— Shuffle Read/Write Size: показывает объем данных, перемещенных между нодами.
— Disk Spills: Если высокий — увеличивайте память экзекуторов.
— Время выполнения этапов: этапы с shuffle обычно самые долгие.

▫️Что проверить в параметрах:
— spark.sql.shuffle.partitions: указывает, на сколько партиций делятся данные при shuffle.
Меньше партиций → меньше накладных расходов, но выше риск перегрузки памяти. Больше партиций → лучше параллелизм, но больше мелких файлов.
— spark.sql.autoBroadcastJoinThreshold: задает максимальный размер таблицы (в байтах) для автоматического Broadcast Join.
Если таблица меньше порога, spark автоматически использует Broadcast Join, избегая shuffle.

▫️Что смотреть в плане выполнения через df.explain():
— Ищите Exchange - это метка shuffle.
— Определите, на каких этапах данные перемещаются между нодами.
Совет: если в плане много Exchange, проверьте, можно ли заменить join на Broadcast или перепартицировать данные заранее.

Пример вывода:
== Physical Plan ==
*(3) Project [...]
+- *(3) SortMergeJoin [...]
:- *(1) Sort [...]
: +- Exchange hashpartitioning(user_id, 200) ← Shuffle!
: +- Scan parquet
+- *(2) Sort [...]
+- Exchange hashpartitioning(user_id, 200) ← Shuffle!
+- Scan parquet

Шаг 5. Знать, что спросят на собеседовании (и как отвечать)

Мой топ вопросов:
1 — Что такое Shuffle?
«Это перераспределение данных между нодами для группировки или сортировки. Он возникает при wide transformations, таких как groupBy или join. Данные перемещаются между партициями, что требует сетевых и дисковых операций».

2 — Как избежать Shuffle?
«Использовать broadcast join, фильтровать данные заранее, применять AQE».
Также можно понтануться в стиле: «я всегда анализирую Spark UI после запуска задачи. Если вижу высокий Shuffle Read, проверяю, можно ли заменить join на broadcast или перепартицировать данные заранее».

3 — Что такое skew и как с ним бороться?
«Skew - это неравномерное распределение данных (например, 90% данных в одной партиции). Решения: salting (добавление случайных префиксов), увеличение числа партиций, AQE».

4. Чем опасен Shuffle?
«Сетевые издержки, риск нехватки памяти (disk spills), skew».

Подробнее читать тут. Было полезно? 👀

Как продакт выбирает инженера

На днях состоялся интересный разговор со знакомым PO, у которого в команде несколько инженеров. Я попросила письменно зафиксировать несколько ответов на мои вопросы, чтобы поделиться с вами. Далее все ответы представлены в исходном виде.

Что важно продакту при найме инженера?
— Чтобы задачи решались, а как - продакт даже не знал. Стало быть, инженер должен уметь спроектировать решение подобрать нужные инструменты, решить возникающие по пути вопросы.
— Чтобы продукты были надежными. Все эти аварии и упавшие ДАГи никак не соотносятся с прекрасным продуктом, который менеджер уже намечал. А значит инженер должен быть ответственным, мыслить системно, а главное - не быть похуистом равнодушным.
— Чтобы инженеры, дата сайентисты, аналитики и кто там еще водится в команде решали технические вопросики на стыке зон ответственности между собой сами. А для этого члены команды должны ладить и нормально коммуницировать.
— Чтобы не было провалов в сроках, а самое страшное для рабочего процесса - уход сотрудника. Искать раз в год нового инженера и передавать задачи - сущий кошмар, поэтому к прогнозированию срока жизни сотрудника в компании продакт подойдет самым тщательным образом.

Что спрашиваешь у инженеров на собеседовании?
Исходя из вышеперечисленных задач и строится беседа. Без понимания целей менеджера вопросы могут показаться странными. Например, далекие от инженерии вопросы про бизнес, в котором трудился инженер - они одновременно про вовлеченность и про готовность погружаться в бизнес-контекст (а без этого каждую задачу придется разжевывать и держать для перевода на инженерный отдельного аналитика). Как было построено взаимодействие в команде, какая культура, неформальные практики - тут между строк про коммуникацию. Также могут последовать странные lifestyle вопросы с целью определить совместимость с командой по темпераменту и ценностям.
Ваша амбициозность и желание расти будут к месту, если такие же амбиции к росту имеются у команды, которую вы приходите, а в противном случае для менеджера это скорее будущая головная боль и риск текучки.
Ну а несколько интервалов работы длиной год-два в резюме - это прямо ред флаг, стоит основательно подготовить объяснение, как ваша компания сгинула в пучину морскую, похоронив все проекты.
Если только отдельная технология не является альфой и омегой продукта, менеджеру не интересно углубляться в технику (а в идеале вообще переложить техническое интервью на лидера экспертизы), а вот дизайн-мышление, умение спроектировать общий процесс - это важно. Поэтому будьте готовым услышать: “А как бы вы подошли к такой задаче”. Кстати, если упомянуть инструменты мониторинга и отказоустойчивости, сердце PO оттает и пошлет вам жирный лайк.

Какого инженера точно не возьмешь к себе в команду?
— Токсика, который будет напрягать команду (если будет хоть намек на это на собеседовании)
— Карьериста, который настроен не решать мои задачи, а заниматься саморазвитием, качать новые скилы и продаться подороже через год
— Узконаправленного, не готового вникать в вопросы вне своей технической сферы. Во-первых, у такого низкая автономность, во-вторых, начнутся разборки в команде, чей вопрос.

Рассматриваешь ли инженеров без опыта?
Только если у меня уже есть мидл+|сеньор, в помощь.



Как относитесь к такому подходу найма инженеров? Какой вопрос вы бы еще задали продакту? 👀

А еще в честь праздника было бы супер приятно получить бустов и звездочек 🥰

Всем привет! Искала в честь праздника интересные циферки, а нашла золото. Представляю вашему вниманию два калькулятора оценки шансов найти идеального парня или девушку на основе американской статистики:
— Female Delusion Calculator
— Male Reality Calculator

P.S. что-то шансов маловато 🫠

Один из классических вопросов для инженера уровня middle и выше - это что такое Data Skew, как его выявить и как с ним бороться?

Я, как человек, который обычно полагается на AQE 😐, ответила бы так:

Во-первых, кратко дала бы определение понятия. Data Skew - это дисбаланс в распределении данных между партициями, когда некоторые ключи содержат значительно больше записей, чем другие. Это приводит к тому, что отдельные задачи в spark выполняются дольше, возникает нагрузка на ноды, падают неприятные out of memory ошибки и падение производительности в целом. Простыми словами, одна задача обрабатывает гигантский объем данных, не справляется и падает.

Далее, рассказала бы как выявляю проблему. По правде говоря, проблема выявляется, когда спустя некоторое время процесс падает 🥴. Но моя лучшая версия на собесе идет и анализирует Spark UI: смотрю на метрики Shuffle Read/Write и время выполнения задач. Если вижу, что одна задача обрабатывает в 10–100 раз больше данных, чем другие - это явный признак skew.
Затем проверяю распределение ключей через groupBy + count. Например:
df.groupBy("key").count().orderBy("count", ascending=False).show(10)

Если несколько ключей содержат >50% данных - skew присутствует. Бывает еще, что в ключе есть NULL, который собирает все в одну партицию.

Методы решения:
В реальной жизни у меня всегда в конфигурации сессии присутствует AQE (Adaptive Query Execution) для автоматического устранения skew:
spark.conf.set("spark.sql.adaptive.enabled", "true")

На собеседовании рассуждаю, что проблема решается в зависимости от контекста:
1 - Broadcast Join
Если один из датасетов маленький — использую broadcast:
df_large.join(broadcast(df_small), "key")
чтобы избежать shuffle.

2 - Солим данные (salting)
Для ключей со skew добавляю случайный префикс, чтобы равномерно распределить данные. Например, разбиваю „тяжелый“ ключ на 100 подключей, типа key_1, key_2 и т.д.
df = df.withColumn("salted_key", concat(col("key"), lit("_"), (rand() * 100).cast("int")))

3 - Разделение данных
Выделяю записи с тяжелыми ключами в отдельный датасет и обрабатываю их отдельно (например, через map-side join).

4 - Оптимизация партиций
Увеличиваю число партиций через spark.sql.shuffle.partitions или repartition(), чтобы снизить нагрузку на отдельные ноды.

Также обязательно делимся примером из практики в стиле: на прошлом проекте делала join датасета с 10 млрд записей и маленькой таблицей-справочником. Ключ user_id был сильно перекошен: 70% данных приходилось на 5% пользователей. Решила проблему так:
— Выделила тяжелых user_id в отдельный датасет.
— Для них применила соль с 200 подключами.
— Остальные данные обработала через broadcast join.
— Время выполнения сократилось с 3 часов до 30 минут 🎉.

Не забудьте упомянуть, что чаще всего обращаете внимание на тюнинг spark сессии:
— играю с параметрами spark.sql.shuffle.partitions
— использую kryo-сериализацию
— контролирую память исполнителей (spark.executor.memory, spark.memory.fraction)
— ну и вообще, кэширую часто используемые данные (если это уместно), как хорошая девочка 😇

Почитать подробнее про data skew 👉�� тут.

Так, ну перед сном самое время вкинуть пикантную задачу. На всякий случай ее заблюрю 😐
Задача 3:
В венерическом диспансере лежат трое мужчин и одна женщина. Все четверо больны разными венерическими болезнями. Они решили устроить оргию, в рамках которой все мужчины хотят переспать с одной женщиной. Но проблема: есть всего два презерватива. Как им поступить, чтобы не подцепить новые болезни?

P.S. надеюсь, после этого вы чувствуете себя максимально готовыми к логическим задачам на собесах… 🫡

Задача 2:
Есть тысяча бутылок, из них только одна с ядом, и 20 кроликов. Одна капля яда убивает кролика за 1 час. Из тысячи бутылок яд только в одной. Сколько часов потребуется, чтобы точно определить в какой бутылке яд?

Примерно лет 5 назад, когда я только искала около-инженерскую работу (DA/DE), на собеседованиях было супер популярным давать задачки на логику. Ну видимо, у джуна много не спросишь, а так хоть какой-то порог на адекватность. Но как же меня раздражало, когда на финальных этапах собеседования с менеджером или тим лидом они на ровном месте вкидывали какую-нибудь задачу 😤. Для меня такой прикол был и до сих пор является ред флагом, потому что мне кажется, это сомнительным методом отбора специалиста middle или senior уровня. В общем, если вы скучаете этим вечером, то предлагаю решить подборку лучших-бесячих:

Задача 1:
В одной стране очень плохо работала почта. Если ты отправляешь посылку, не закрытую на замок, то посылку обязательно украдут. Единственный надежный способ отправить посылку - это положить ее в крепкий ящик с навесным замком 🔐 , в таком случае она дойдет. Вам потребовалось отправить другу в другой город посылку с ценным содержанием, как это сделать?

Мне кажется, последние несколько лет у всех было на слуху понятие quiet quitting. Это тенденция «тихого ухода», когда сотрудники снижали вовлеченность, не покидая рабочее место. Так вот, в 2025 году ее заменяет «revenge quitting» - осознанный уход с работы на фоне длительного недовольства условиями труда с нотками драмы. По крайней мере так пишут в Forbes и The Economic Times.

Ребята из Software Finder даже заморочились и провели исследование более 1000 работников на эту тему. Из интересного пишут, что:
— 4% сотрудников планируют revenge quitting в 2025 году, при этом 7% - для тех, кто работает на гибридном графике.
А основными причинами являются:
— Низкие зарплаты и отсутствие повышений (48% опрошенных);
— Ощущение недооценки со стороны работодателя (34%);
— Отсутствие карьерных перспектив (33%).

Что я думаю?
Вообще сомнительно назвать это явление трендом, поскольку вряд ли это обретет популярность у обычных работяг, а не только у зумеров из тик-тока 🥴.
Плюс результаты исследования вызывают вопросы. Во-первых, какой у нас средний срок работы на одном месте? Ну, пусть 3-5 лет (не берем в расчет беспокойных ребят, работающих по году). Значит, каждый год меняет работу 20-30% работников. А тут речь о 4% планирующих уйти, хлопнув дверью, т.е. реально таких уйдет ~2%. Ну и как они выделяются на фоне вышеупомянутых 20-30%? Как-то не тянет на перелом тренда. Да и время для драматичных уходов как будто бы не самое подходящее, учитывая фризы и сокращения.

Что думаете вы? 🤔

Что в итоге?

Важно помнить, что эти типы - не статичные ярлыки, а скорее роли, которые сотрудники могут примерять в разные периоды и в разных командах. Нейтральный сегодня инженер завтра может стать «локомотивом» проекта, если найдет в работе личный смысл. Точно также, как и вовлеченный сотрудник может перегореть из-за хронической перезагрузки. Я думаю, что управление и распределение типов в команде - это, в первую очередь, задача менеджмента, поскольку у них в руках есть все необходимые инструменты для создания комфортной рабочей среды, где у каждого сотрудника есть возможность проявить себя.

Ниже приложила отчеты, которые помогли мне в написании этого поста.

Три типа инженеров

В it-командах, как и в любой профессиональной среде, сотрудники демонстрируют разные типы вовлеченности. На основе моего опыта и данных исследований можно выделить три условных типа: вовлеченные, нейтральные и отчужденные. Консалтинг Gallup в своем отчете State of the Global Workplace за 2024 год на основе опросов приводит следующие цифры по глобальному распределению этих типов:
— 23% - вовлеченные (engaged)
— 62% - нейтральные (not engaged)
— 15% - отчужденные (actively disengaged)

Итак, подробнее про типы:
Вовлеченный.
Вы наверняка замечали продуктивного коллегу, который берет на себя сложные задачи и инициирует улучшения процессов без указаний (напр., рефакторинг кода, внедрение новых инструментов). Он помогает коллегам и участвует в неформальных процессах команды. Зачастую именно его выбирают ментором для новичков в команде. А еще он чаще других берет на себя дополнительные задачи и участвует в принятии важных решений.

Нейтральный.
Пожалуй, это основной состав большинства команд. Это ваш коллега, который хорошо разбирается в устоявшихся процессах, делает задачи в срок, готов прийти на помощь, но при этом он редко выходят за рамки своих обязанностей. Например, такой инженер вовремя закрывает задачи, поставленные в спринте, но не станет предлагать оптимизацию ci/cd пайплайна, если это не входит в его годовые цели или KPI. Он работает в комфортном для себя режиме и зачастую не видит смысла быть чрезмерно вовлеченным во все процессы команды или компании.

Отчужденный.
Такой коллега редко остается незамеченным. Он делает ровно то, что прописано в задаче, без попыток понять контекст или предложить лучшее решение. Ему требуется четко сформулированная постановка задачи с конкретным планом действий, потому что иначе он сделает совсем не то, чего от него ожидали. Зачастую задачи такого сотрудника переделываются по несколько раз, и ему чаще других требуется помощь и поддержка коллег.

Что формирует эти типы?

Мой опыт и исследования сходятся в нескольких факторах:
1. Опыт первой работы. Мне кажется, пик моей вовлеченности пришелся на момент, когда я впервые заняла инженерскую позицию, к которой долгое время стремилась. Мне не терпелось поскорее научиться пользоваться всеми имеющимися инструментами, сделать что-то выдающееся и заметное, чтобы меня похвалили. Кстати, эту теорию подкрепляет исследование Deloitte о Gen Z (2024) — новички, погруженные в интересные задачи, демонстрируют на 50% более высокую вовлеченность (✍️менеджерам на заметку, почему не стоит бояться джунов).

2. Команда. Сугубо личное ощущение: очень сложно стать проактивным сотрудником в команде, если такой уже есть, поскольку приходится быть на «вторых ролях», что в конечном итоге снижает мотивацию и вовлечение. Помимо этого, важную роль играет эффект социальной лени - люди склонны прилагать меньше усилий при групповой работе.

3. Менеджер. Если менеджер вовлечен в процессы, если он умеет мотивировать всю команду и не закрывает глаза на отчужденных, то с большей вероятностью его сотрудники также будут вовлечены. В отчете Gallup приводится цифра - 70% успеха вовлеченности зависит от менеджера.

4. Денежная мотивация. Многие из моих коллег назвали бы это основным фактором вовлечения. Но исследования показывают неоднозначную связь между оплатой труда и вовлеченностью. Тут рекомендую к прочтению книгу «Драйв» Дэниела Пинка. Он считает, что деньги - это «гигиенический фактор», их отсутствие демотивирует, но наличие не гарантирует вовлеченность.

5. Процессы. Сложно начать хорошо делать свою работу, если ты зависишь от других людей и результатов их работы. Еще одна цифра из отчета Gallup - в компаниях с хорошо выстроенными процессами вовлечены 3/4 менеджеров и 7/10 рядовых сотрудников. Хотя тут я бы поспорила, что причина, а что следствие 🤔.

6. Личные границы и work-life balance. Исследование Deloitte показывает, что для 65% молодых it-специалистов баланс работы и личной жизни важнее карьерного роста.

Из неинженерного: так вышло, что последнюю неделю я провела в больницах. Поэтому некоторым из вас я долго отвечала на сообщения и редко писала посты здесь, потому что просто не могла собрать мысли. Меня одолевала злость от непонимания, ну почему мы знаем так много про всякие технологии и ничего не знаем про свой организм.
В общем, это была ужасная неделя, но сейчас все хорошо, врачи со всем разобрались. А я не опускаю руки и иду дальше.
Всем здоровья! 🕊️

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

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

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

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

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


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

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