Как происходил парсинг и обработка данных

Что проверяют

Насколько вы понимаете путь данных от сырого источника до таблицы, с которой работает модель, и что делали сами, а не команда. Интервьюер ищет инженерные детали: как переживали сбои, дубли и смену формата. Следом часто просят рассказать, как вы узнавали, что парсер сломался.

Как отвечать

Постройте ответ по этапам своего проекта, с реальными объёмами и сроками:

• источник: API, файлы, логи или HTML. Для страниц подходят httpx или requests вместе с lxml или BeautifulSoup, для сайтов с отрисовкой на JavaScript нужен Playwright. Сразу оговорите повторы с паузой, ограничение частоты запросов и соблюдение условий сайта;
• сырой слой: исходные ответы сохраняются как есть (JSON Lines, Parquet, объектное хранилище). Тогда при ошибке в разборе данные переразбираются без повторного скачивания;
• разбор: структурный парсер вместо регулярных выражений, где это возможно, явная схема и проверка типов. Отдельно кодировки, форматы дат и часовые пояса;
• очистка: дедупликация по ключу, приведение справочных значений, решение по пропускам. Заполнение пропусков для обучения считается только по обучающей части, иначе это утечка;
• загрузка: инкрементально и идемпотентно, то есть повторный запуск не плодит дубли (upsert по ключу). Инструменты: pandas или polars на одной машине, Spark для больших объёмов, запуск через Airflow или cron;
• контроль: число записей за прогон, доля пустых полей, алерт, если показатели резко изменились.

Если парсинг был разовым скриптом в ноутбуке, так и скажите и добавьте, что поменяли бы для регулярного конвейера. Цифры ускорения называйте только свои и с базой сравнения.

Где спотыкаются

Рассказывают о библиотеках, но не о сбоях. Сайт поменял вёрстку, и парсер неделю писал пустые поля: такой случай и его разбор ценнее списка инструментов.

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

Заполняют пропуски средним по всему датасету до разбиения на выборки и не замечают, что это утечка в валидацию.