Собес в бигтех: когда теория уже не спасает

На собесах в классные компании на интервью редко спрашивают только «что такое ETL?». Чаще дают кейс с прода и смотрят, как ты думаешь🧐: где риск дублей, что сломается при ретрае, как найти узкое место и чем лечить проблему.

💡Собрал 5 интересных и реальных вопросов, на которых проверяют реальный опыт:

1️⃣Airflow: задача упала на середине загрузки — что делать?

Не просто  Clear . Сначала проверь идемпотентность: staging,  UPSERT , перезапись партиции, атомарный commit. Повторный запуск не должен портить данные.

🔗 Статья про идемпотентность в Airflow

2️⃣Spark тормозит, хотя ресурсов в кластере много — с чего начнёшь?

С Spark UI. Ищи  shuffle ,  data skew , лишние мелкие файлы и дорогие UDF. Часто проблема не в памяти, а в плане выполнения.

🔗 Диагностика Spark приложений

3️⃣Kafka: пришёл дубль события — как не сломать витрину?

Офсеты не спасают. Нужны exactly-once на pipeline-уровне и идемпотентная запись в приёмник:  UPSERT ,  MERGE , уникальный ключ.

🔗Идемпотентность и повторные запуски

4️⃣Iceberg: наплодили много мелких файлов — чем это плохо?

Растёт нагрузка на метаданные, а Trino/Spark тратят время на планирование. Нужен  compaction  и нормальный размер файлов.

5️⃣Когда реально нужен real-time?

Бизнес всегда хочет быстрее, но платить за это тоже нужно. Стриминг (Flink/Spark Streaming) нужен только там, где задержка в секунды критична: антифрод, алерты, персонализация. Если можно подождать 5–10 минут обычный batch будет в разы проще и дешевле.

На собесе важнее не угадать инструмент, а показать, что ты понимаешь ограничения архитектуры и умеешь выбирать решение под задачу.

🚀Хочешь оценить свою готовность к рынку?
Пиши мне в личку @ampodvalniy, укажи текущий стек и на какой грейд/ЗП метишь. Посмотрим, где у тебя пробелы и как их закрыть.