Структура ответа на три минуты: роль и команда (сколько инженеров, кто заказчики), стек (источники → хранилище → витрины → потребители), ваша зона ответственности и два-три результата с цифрами (объёмы в строках или гигабайтах в день, сколько пайплайнов, что ускорили и во сколько раз). Дальше интервьюер пойдёт вглубь по каждому слову, поэтому называйте только то, что готовы разобрать: откуда загружали (базы, API, файлы), чем (Airflow + PXF/Spark/Python), какой первый слой (raw как есть, staging с типизацией), как считали инкремент, чем трансформировали (SQL в хранилище или Spark), как проверяли.
Формула: контекст (какая боль у бизнеса), что сделали вы лично (не команда), какое решение приняли и почему отвергли альтернативы, результат в цифрах, что бы сделали иначе. Пример: «витрина сверки платежей считалась 6 часов и падала; я перевёл расчёт на инкремент по дате платежа с перезаписью трёх последних дней, вынес справочники в replicated-таблицы, добавил проверки; стало 20 минут, падений ноль за полгода». Один подготовленный кейс с деталями лучше трёх расплывчатых.
Назвать порядок, а не точные числа: строк в день, размер витрин в гигабайтах, число таблиц и пайплайнов, прирост. Важно связать объём с решениями: «200 млн событий в день, поэтому хранили в ClickHouse партициями по дню, а не в Postgres». Если объёмы были небольшими, сказать честно и показать, что понимаете, что изменится при росте.
Назвать число с обоснованием: что делаете уверенно (оконные функции, оптимизация планов, идемпотентные загрузки), чего не делали (тюнинг на уровне СУБД, PL/pgSQL). Завышенная оценка проверяется задачами тут же, заниженная снижает ожидания; 7–8 с конкретикой звучит убедительно для middle.
Честно сказать, что не работали, и показать перенос опыта: ODI и Pentaho это ETL-инструменты с тем же набором понятий (источник, маппинг, расписание, инкремент), SOAP это XML поверх HTTP с WSDL-описанием, парсится стандартными библиотеками. Назвать, как будете входить: документация, тестовый стенд, первая маленькая задача под ревью. Интервьюер проверяет не знание инструмента, а то, как вы учитесь.
Ожидают не «да», а примеры: как получали требования (ТЗ от аналитика, постановка в задаче, устная договорённость), что уточняли перед работой (источники, частота обновления, кто потребитель, что считать ошибкой), приходилось ли править ТЗ, когда выяснялось, что данных нет или требование противоречиво, и как это оформляли. Про регламенты: порядок выкладки, код-ревью, ночные окна загрузки, дежурства, документирование витрин. Хороший ответ показывает, что кандидат фиксирует договорённости письменно и возвращается к заказчику при расхождениях, а не додумывает.
Отвечать про рост, а не про обиды: «вырос из текущих задач, хочу работать с большими объёмами и стримингом, здесь это есть». Про другие собеседования нейтрально: «рассматриваю несколько команд с похожим стеком, выбираю по задачам и команде». Направление развития конкретное: архитектура хранилища, платформенные инструменты, лидерство в команде, с привязкой к вакансии.
Настоящая слабость с историей исправления: «увлекался оптимизацией там, где достаточно было работающего решения, научился сначала выпускать и мерить, потом улучшать». Не называть «перфекционизм» без деталей и не выбирать слабость, критичную для роли.
Сначала понять причину: людям дорого переучиваться, изменение ломает их процессы или просто не объяснено. Поговорить один на один, показать выгоду на их задаче, предложить пилот на одном пайплайне, договориться о критериях, когда откатим. «Забить» это проигрыш обеим сторонам: изменение саботируют.
Реализовать выбранный вариант добросовестно: решение принято, и его успех теперь общий. Зафиксировать свои риски письменно (в задаче или документе), чтобы вернуться к ним, если они сработают, без «я же говорил». При директивном решении без аргументов спокойно попросить объяснение, потому что оно нужно для правильной реализации, а не для спора; если объяснения нет, уточнить критерии приёмки и делать. Систематическая директивность это уже вопрос к тому, оставаться ли в команде, но не повод для конфликта на месте.
Да, с примером: как уточняли требования к витрине (вопросы про зерно, определения метрик, периодичность, что считать ошибкой), как фиксировали договорённости и показывали прототип на части данных до полной реализации. Инженер, который умеет снять требования, ценится выше, и это стоит показать, даже если формально это делал аналитик.
Да: юнит-тесты на трансформации, проверки качества данных как часть пайплайна, сверка с источником до выкладки. Требования к проверкам обычно формулировали совместно: бизнес-правила от аналитика или заказчика, технические (уникальность, полнота, свежесть) от инженера. Показать понимание, что проверка без порога и владельца это не проверка.
Не отказывать молча и не обещать невозможного. Выяснить реальную потребность: какое решение он примет по этой витрине и когда. Предложить варианты: упрощённую версию (одна метрика вместо десяти, недельная вместо ежедневной), разовую выгрузку вместо регулярной витрины, срок с учётом очереди, или эскалацию приоритета руководителю с оценкой затрат. Зафиксировать договорённость письменно. Интервьюер проверяет, что вы управляете ожиданиями, а не исчезаете.
Разобраться, почему именно вторник (выгрузка за выходные, отчётный день у источника), и измерить, какой шаг не масштабируется. Варианты: обрабатывать по частям параллельно, выделять больше ресурсов на этот день (динамическая аллокация, отдельная очередь), перенести тяжёлые шаги в инкремент, начинать обработку по мере поступления, а не после полной выгрузки, договориться с источником о более раннем старте. Поставить мониторинг длительности с порогом, чтобы следующий рост заметить заранее.
Начать с инвентаризации: какие таблицы, объёмы, кто потребители, какие запросы к ним идут, есть ли метка изменений для инкремента. Выбрать приёмник по нагрузке: Greenplum для модели со сложными соединениями, ClickHouse для событий и агрегатов. Сделать маппинг типов, первую полную выгрузку, инкремент, сверку, параллельный период, переключение. Если источники у систем разные, сначала сверить справочники и ключи между ними (один и тот же клиент под разными id) и построить таблицу соответствий, иначе данные не сойдутся после переноса.
Сначала оценить: что именно не досчиталось и можно ли выпустить отчёт частично или на вчерашних данных с пометкой. Сообщить заказчику сразу, с оценкой времени, а не после починки. Починить минимально безопасным способом (перезапуск за период, ручная догрузка), после выпуска отчёта разобрать причину и написать постмортем с действиями, чтобы не повторилось. Тишина хуже плохих новостей.
Разделить на три группы по три. Первое взвешивание: группа A против группы B. Если равны, фальшивая в C; если одна чаша легче, фальшивая в ней. Второе взвешивание: из найденной тройки положить одну монету против другой: если равны, фальшивая третья, иначе та, что легче. Общий принцип: каждое взвешивание даёт три исхода, поэтому за n взвешиваний можно различить 3ⁿ монет.
Стрелять сразу. После холостого выстрела известно, что курок стоял на одном из четырёх пустых гнёзд; следующее гнездо заряжено только в одном случае из четырёх (когда холостое было последним перед парой патронов), то есть риск 1/4. Если крутить барабан, риск становится 2/6 = 1/3. Если бы патроны лежали не подряд, ответ мог бы быть другим: такие задачи проверяют умение честно пересчитать условную вероятность.