Economics & Time-Series Domain — DE Interview PrepЭкономика и временны́е ряды — Подготовка к DE-интервью

A macro series is a labelled stream of observations over time, plus a heavy metadata stack. The data engineering twist that makes econ data different from your event/log work at Meta: the same period gets multiple values over time (revisions), and users need to ask "what did we know then?" not just "what's true now?"

Макроэкономический ряд — это помеченный поток наблюдений во времени плюс тяжёлый стек метаданных. Инженерный поворот, который отличает эконом-данные от работы с событиями/логами в Meta: один и тот же период получает несколько значений во времени (ревизии), и пользователям нужно спросить «что мы знали тогда?», а не только «что верно сейчас?»

If you remember one thing: the natural grain of an observation is NOT (series_id, period) — it is (series_id, period, release_date/vintage). That single fact signals you "get" the domain.

Если запомнить одно: естественная гранулярность наблюдения — это НЕ (series_id, period), а (series_id, period, release_date/vintage). Этот единственный факт даёт понять, что ты «въехал» в домен.

Storage patterns

Паттерны хранения

Pragmatic shops keep full vintages for revision-prone series (GDP, payrolls), latest-only or compressed for stable ones.

Прагматичные команды хранят полные версии для склонных к ревизиям серий (GDP, payrolls), latest-only или сжатые для стабильных.

Many series have predictable intra-year patterns (Dec retail spike, summer hiring). Seasonal adjustment removes that recurring component to expose the trend/cycle. Methods: X-13ARIMA-SEATS, TRAMO/SEATS.

Многие серии имеют предсказуемые внутригодовые паттерны (всплеск розницы в декабре, летний наём). Сезонная корректировка убирает этот повторяющийся компонент, чтобы обнажить тренд/цикл. Методы: X-13ARIMA-SEATS, TRAMO/SEATS.

Mixed frequency (daily / weekly / monthly / quarterly)

Смешанная частота (дневная / недельная / месячная / квартальная)

• Store frequency as explicit metadata — don't infer from row spacing.
• Mixed-frequency alignment: up/down-sample (aggregate vs interpolate) is a transform decision — keep native frequency, resample at serving.
• Period semantics differ: end-of-period vs period-average vs flow vs stock — store the semantic.
• Calendar edges: week-numbering, partial periods, holidays, business-day counts.

• Хранить частоту как явные метаданные — не выводить из интервала между строками.
• Выравнивание смешанной частоты: up/down-sample (агрегация vs интерполяция) — это решение преобразования — хранить родную частоту, передискретизировать при сервинге.
• Семантика периода различается: end-of-period vs period-average vs flow vs stock — хранить семантику.
• Края календаря: нумерация недель, частичные периоды, праздники, счёт бизнес-дней.

Releases (CPI, NFP, FOMC, GDP) move markets in seconds. Users, algos and analysts need the number the instant it's public. Late or wrong = competitive + reputational failure. That's a core value prop for financial data providers.

Релизы (CPI, NFP, FOMC, GDP) двигают рынки за секунды. Пользователи, алгоритмы и аналитики нуждаются в числе в момент, когда оно публично. Поздно или неправильно = конкурентный и репутационный провал. Это ключевое предложение ценности для провайдеров финансовых данных.

• Releases are scheduled but format-variable → event-driven, pre-staged pipelines.
• Release calendar = first-class data asset; freshness/SLA monitoring ("did CPI land at 08:30 ET?").
• Speed vs accuracy tension → resolve by embedding fast inline controls on the critical path, human escalation only on exceptions.
• Corrections happen → clean, versioned re-publish (no silent overwrite).

• Релизы запланированы, но формат переменный → event-driven, предварительно настроенные пайплайны.
• Календарь релизов = первоклассный data asset; мониторинг свежести/SLA («CPI приземлился в 08:30 ET?»).
• Напряжение скорость vs точность → решается встраиванием быстрых inline-контролей на критическом пути, человеческая эскалация только на исключениях.
• Исправления случаются → чистая, версионированная переиздание (не тихая перезапись).

Operational: inline where cheap, async where heavy; exceptions → queue + runbook; every correction versioned; observability dashboards + alerting; idempotent re-runs.

Операционно: inline где дёшево, async где тяжело; исключения → очередь + runbook; каждое исправление версионировано; дашборды наблюдаемости + алертинг; идемпотентные перезапуски.

-- GRAIN: observation = (series_id, observation_period, release_date/vintage)  ← bitemporal heart

CREATE TABLE dim_series (        -- SCD2: definition revises when base year/units change
  series_id        STRING,
  indicator        STRING,   -- 'CPI'
  geography        STRING,   -- ISO + canonical
  unit             STRING,   -- index(1982-84=100) / pct / count
  frequency        STRING,   -- M/Q/W/D
  sa_flag          BOOLEAN,  -- SA vs NSA
  currency         STRING,
  base_year        STRING,
  period_semantic  STRING,   -- EOP / avg / flow / stock
  source           STRING,
  valid_from       DATE, valid_to DATE );

CREATE TABLE fct_observation (   -- APPEND-ONLY, never UPDATE
  series_id        STRING,
  obs_start        DATE, obs_end DATE,  -- the period described
  value            DOUBLE,
  release_date     TIMESTAMP,  -- when published
  vintage_id       STRING,
  status           STRING,      -- prelim / final
  source_file      STRING );    -- lineage

-- LATEST view: pick newest vintage per period
SELECT series_id, obs_start, value
FROM (
  SELECT *, ROW_NUMBER() OVER (
           PARTITION BY series_id, obs_start
           ORDER BY release_date DESC) AS rn
  FROM fct_observation )
WHERE rn = 1;

-- AS-OF view: what we knew on :asof_date
SELECT series_id, obs_start, value
FROM (
  SELECT *, ROW_NUMBER() OVER (
           PARTITION BY series_id, obs_start
           ORDER BY release_date DESC) AS rn
  FROM fct_observation
  WHERE release_date <= :asof_date )   -- ← no look-ahead
WHERE rn = 1;

-- ГРАНУЛЯРНОСТЬ: observation = (series_id, observation_period, release_date/vintage)  ← битемпоральное сердце

CREATE TABLE dim_series (        -- SCD2: определение ревизируется при изменении base year/units
  series_id        STRING,
  indicator        STRING,   -- 'CPI'
  geography        STRING,   -- ISO + канонический
  unit             STRING,   -- index(1982-84=100) / pct / count
  frequency        STRING,   -- M/Q/W/D
  sa_flag          BOOLEAN,  -- SA vs NSA
  currency         STRING,
  base_year        STRING,
  period_semantic  STRING,   -- EOP / avg / flow / stock
  source           STRING,
  valid_from       DATE, valid_to DATE );

CREATE TABLE fct_observation (   -- APPEND-ONLY, никогда UPDATE
  series_id        STRING,
  obs_start        DATE, obs_end DATE,  -- период, который описывается
  value            DOUBLE,
  release_date     TIMESTAMP,  -- когда опубликовано
  vintage_id       STRING,
  status           STRING,      -- prelim / final
  source_file      STRING );    -- lineage

-- LATEST вьюха: выбрать новейшую версию на период
SELECT series_id, obs_start, value
FROM (
  SELECT *, ROW_NUMBER() OVER (
           PARTITION BY series_id, obs_start
           ORDER BY release_date DESC) AS rn
  FROM fct_observation )
WHERE rn = 1;

-- AS-OF вьюха: что мы знали на :asof_date
SELECT series_id, obs_start, value
FROM (
  SELECT *, ROW_NUMBER() OVER (
           PARTITION BY series_id, obs_start
           ORDER BY release_date DESC) AS rn
  FROM fct_observation
  WHERE release_date <= :asof_date )   -- ← нет look-ahead
WHERE rn = 1;

Scale: partition by source/frequency/date; columnar; as-of prunes on release_date; compress unchanged vintages; full vintages only for revision-prone series. Also: dim_release (calendar, embargo) and vendor crosswalk tables.

Масштаб: партиция по source/frequency/date; колоночное; as-of прунит по release_date; сжимать неизменённые версии; полные версии только для склонных к ревизии серий. Также: dim_release (календарь, эмбарго) и вендорные crosswalk-таблицы.

They've read your CV; they will raise the missing macro/time-series experience. Pre-empt it. Calm, specific, zero defensiveness.

Они читали твоё CV; они поднимут отсутствие опыта макро/временны́х рядов. Опереди это. Спокойно, конкретно, без защиты.

1. Name it plainly: "I haven't worked with macro, survey or forecast datasets; my closest time-series-adjacent work is the bank default model, not true series modelling. I want to be upfront."
2. PIT instinct from credit: the top-10 bank factoring default model lived on point-in-time correctness — you cannot train on info unavailable at decision time. Same look-ahead/vintage discipline econ demands.
3. Modelling at scale: 10 logging systems / 3.6B events/day into one model; entity-resolution fix across 6.2B records. "Nail the grain, fix identity, restore downstream trust" — here on a new temporal axis.
4. Legacy modernization (direct match): McMakler triple migration (Snowflake, Airflow, dbt), EUR 1M+ saved, no BI downtime — parallel-run + reconcile + incremental cutover.
5. Messy multi-source: Salesforce sync layer, 8-brand customer-spine convergence = the vendor crosswalk problem.
6. Proof of fast ramp: EMEA DE Hackathon win (Untangler multi-agent, picked for internal tooling); Kafka + GPT-4 production at IU in months; Azure OpenAI case study.
7. Show you started: "I've already studied vintages/PIT, seasonal adjustment, release calendars, and the BLS/BEA/Eurostat/central-bank model — happy to go deep."

1. Назови прямо: «Я не работал с макро-, опросными или прогнозными датасетами; моя ближайшая time-series-смежная работа — банковская модель дефолта, не настоящее моделирование серий. Хочу быть честным.»
2. PIT-инстинкт из кредита: модель дефолта факторинга топ-10 банка жила на point-in-time корректности — нельзя тренировать на информации, недоступной в момент решения. Та же look-ahead/vintage дисциплина, которую требует экономика.
3. Моделирование на масштабе: 10 систем логирования / 3.6B событий/день в одну модель; entity-resolution фикс на 6.2B записях. «Пробей гранулярность, почини идентичность, восстанови доверие downstream» — здесь на новой временно́й оси.
4. Модернизация легаси (прямое попадание): McMakler тройная миграция (Snowflake, Airflow, dbt), EUR 1M+ сэкономлено, никакого простоя BI — параллельный запуск + сверка + инкрементальная переключка.
5. Грязный мульти-источник: Salesforce-синк-слой, 8-брендовая customer-spine конвергенция = проблема вендорного crosswalk.
6. Доказательство быстрого вката: победа в EMEA DE Hackathon (Untangler мультиагент, выбран для внутренних инструментов); Kafka + GPT-4 в продакшн в IU за месяцы; Azure OpenAI кейс.
7. Покажи, что начал: «Я уже изучил vintages/PIT, сезонную корректировку, календари релизов и модели BLS/BEA/Eurostat/центробанков — готов углубиться.»