Тестовое задание аналитика: решение, оформление и границы работы

Короткий ответ: как выполнить тестовое

Переформулируйте задачу в одном предложении, зафиксируйте зерно данных и критерий готовности, проверьте ключи перед соединениями. Покажите основной результат раньше кода: несколько строк выводов, метод, ограничения и предложение следующей проверки. Читатель должен суметь воспроизвести число и понять, где факт заканчивается.

Если условие размыто, задайте два-три вопроса: для какого решения нужен анализ, какой период и определение метрики, какой формат результата ждут. Если ответа нет, запишите допущение. Время и доступ к данным согласуйте до начала: объём задания у разных работодателей различается, универсальной нормы часов нет.

Какие бывают тестовые задания аналитика

SQL-задание проверяет зерно таблиц, соединения, агрегацию и обработку пустых значений. Аналитическое задание с выводами проверяет выбор метрики, проверку альтернатив и честность интерпретации. Дашборд — иерархию показателей, фильтры, определения и удобство решения. Продуктовый кейс — постановку гипотез и приоритет проверок. Для системного аналитика тестовым может быть описание сценария, API-контракта или состояний процесса.

Один файл с графиками не заменяет записку, а красивый документ не исправляет ошибку в SQL. При одинаковом результате выберите форму, в которой легче проверить логику. Условие без данных не даёт оснований рисовать фактическую воронку; лучше показать план измерения и явно назвать ожидаемый артефакт.

Что уточнить до начала и сколько времени тратить

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

Если на вопросы не ответили, выберите узкий проверяемый объём и пометьте допущения. Оцените свои часы до старта, сообщите рамку и попросите уточнить приоритет, если задача шире. Не существует честного универсального «два часа для любого тестового»: маленький SQL и многодневный анализ требуют разного труда. Не жертвуйте проверкой чисел ради последней необязательной визуализации.

Структура сдачи: что увидит проверяющий первым

Верхняя часть письма или README — три-пять предложений: вопрос, главный результат, его ограничение, рекомендуемое действие. Затем определение метрики, выборка и период, шаги расчёта, проверка качества, альтернативное объяснение. В приложении — SQL или ноутбук и инструкция запуска. Такая последовательность полезна и менеджеру, и техническому интервьюеру.

Для репозитория достаточно README с версией окружения, входными файлами без секретов, командой воспроизведения и ожидаемыми итогами. Для ноутбука выполните ячейки от начала до конца на чистом окружении, уберите персональные данные и тяжёлый вывод. Для таблицы Excel подпишите формулы и источники. Если файл закрыт доступом, проверьте право чтения до отправки.

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

Собственное учебное тестовое: условие

Данные: учебная база «Авиаперевозки», срез расписания на 5 августа 2026 года по московскому времени. В таблице flights есть рейсы и статусы, в boarding_passes — записи посадочных талонов по flight_id. Задача: оценить, сколько рейсов этого дня имеют записи посадочных талонов, показать долю рейсов без них по статусу и подготовить короткую записку владельцу данных. На выполнение отведите ограниченное время; цель — проверить ключ и смысл отсутствующей записи, а не построить дашборд.

Важное уточнение: это синтетическая учебная база. Отсутствие записи в boarding_passes не равняется отсутствию пассажиров. Статус Arrived и талон описывают разные процессы, а полнота регистрации талонов здесь не подтверждена. Нужно найти наблюдение в базе и вопрос владельцу источника.

Первый контроль: ключ, фильтр и риск размножения

Номер рейса нельзя считать ключом всего набора: в полном учебном срезе 33 121 строка flights и только 710 различных flight_no; один номер встречается до 61 раза. В выбранный день 548 строк и 548 номеров, но это свойство среза, а не обещание схемы. Для связи таблиц используйте flight_id. В boarding_passes пара ticket_no и flight_id не дублируется в проверенном наборе.

Прямой LEFT JOIN рейсов к талонам за день возвращает 22 189 строк при 548 рейсах: один рейс с несколькими талонами повторяется. Это нормальная кардинальность один-ко-многим, но COUNT(*) после такого JOIN испортит показатель рейсов. Сначала сверните талоны до одного flight_id, затем соединяйте.

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

Дата scheduled_departure фильтрует запланированный вылет, а не фактическое прибытие. Рейс со статусом Arrived может иметь другую дату прибытия, но здесь попадает в срез по расписанию. Это важная часть определения выборки. Если в реальном задании нужны рейсы, прибывшие в день, запрос придётся изменить, а результат пересчитать. Формулировка «за 5 августа» без указания временного поля слишком широкая.

SELECT COUNT(*) AS flight_rows, COUNT(DISTINCT flight_no) AS flight_numbers
FROM flights;
-- 33121 рейс, 710 номеров: flight_no не глобальный ключ.

SELECT COUNT(*) AS joined_rows, COUNT(DISTINCT f.flight_id) AS unique_flights
FROM flights f LEFT JOIN boarding_passes bp ON bp.flight_id = f.flight_id
WHERE CAST(f.scheduled_departure AS DATE) = DATE '2026-08-05';
-- 22189 строк, 548 рейсов.

Решение SQL: одно наблюдение на рейс

Сначала ограничим flights днём вылета по московскому времени. Во второй CTE сведём boarding_passes до множества идентификаторов рейса: таким образом факт наличия талона не зависит от числа талонов. LEFT JOIN сохранит рейсы без записи. В финале считаем два итога по статусу: всего рейсов и сколько без строки в наборе талонов.

Результат выполненного запроса: Arrived — 546 рейсов, из них 163 без записей талонов; Cancelled — 2, оба без талонов. Всего 548 рейсов и 165 без записей. Доля 163/546 ≈ 29,85% для Arrived — описание этого среза, а не оценка пассажирского потока. Если требуется доля по всем рейсам, 165/548 ≈ 30,11%; знаменатель должен быть указан рядом с числом.

Альтернатива DISTINCT в отдельной CTE — EXISTS для каждого рейса. Он тоже отвечает на вопрос «есть хотя бы одна запись», не размножая строки. В тестовом полезно назвать оба способа и объяснить выбор: отдельное множество идентификаторов читается просто, а EXISTS может быть удобно в большом запросе. Выбор реализации вторичен по отношению к зерну и проверке результата. Не заменяйте условие наличия на COUNT(bp.ticket_no)>0 после неподготовленного JOIN, если затем считаете рейсы тем же COUNT(*).

Для проверки доли можно вычислить 163 / 546 с явным приведением к дробному типу и округлением лишь при показе. Округлённые 29,85% не должны попадать обратно в последующие расчёты. Если в проверке попросят общий показатель, сначала решите, включать ли Cancelled: это не косметическая разница, потому что цель вопроса может быть «покрытие всех рейсов» или «покрытие рейсов, которые состоялись».

WITH day_flights AS (
  SELECT flight_id, status
  FROM flights
  WHERE CAST(scheduled_departure AS DATE) = DATE '2026-08-05'
), pass_flights AS (
  SELECT DISTINCT flight_id FROM boarding_passes
)
SELECT f.status, COUNT(*) AS flights,
       SUM(CASE WHEN p.flight_id IS NULL THEN 1 ELSE 0 END) AS without_pass_record
FROM day_flights f
LEFT JOIN pass_flights p ON p.flight_id = f.flight_id
GROUP BY f.status ORDER BY f.status;

Что проверить перед выводом

Сверьте общий итог с отдельным COUNT(*) по flights на ту же дату — 548. Проверьте, что каждый рейс после JOIN присутствует один раз. Уточните, что DATE для scheduled_departure уже относится к московскому времени набора; на иной базе явное приведение часового пояса изменит границу дня. Посмотрите, не означает ли статус Cancelled ожидаемое отсутствие талонов; отдельно считайте Arrived.

Не выводите «163 пустых самолёта», «ошибка регистрации» или «потеря выручки». Никакое из этих утверждений не следует из таблиц без определения покрытия и процесса записи. Операционно полезный следующий шаг — попросить владельца boarding_passes описать обязательность и задержку загрузки, сверить с другим источником и повторить проверку по нескольким датам. Если задача тестового требует рекомендацию, предложите именно эту проверку.

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

Если выяснится, что boarding_passes заполняется только для части перевозчиков или маршрутов, знаменатель придётся согласовать с владельцем источника. Тогда текущий расчёт останется корректным ответом на вопрос «есть ли запись в этой таблице», но не станет метрикой полноты всего процесса. Это типичный случай, когда SQL верен, а управленческая интерпретация преждевременна.

Короткая записка по результату

«В учебном срезе на 5 августа 2026 года найдено 548 рейсов. Среди 546 рейсов со статусом Arrived у 163 нет записи в boarding_passes (29,85%). Проверка сделана на уровне flight_id; прямое соединение даёт 22 189 строк и не годится как счёт рейсов. По двум Cancelled отсутствие талона ожидаемо возможно, поэтому они вынесены отдельно. Наличие или отсутствие пассажиров из этого результата не следует. Предлагаю уточнить охват и задержку источника талонов, затем повторить расчёт по статусам и датам».

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

Записка не должна прятать критерий в приложении. Руководитель может переслать один абзац без SQL, поэтому в нём должны стоять дата, статус, знаменатель, единица наблюдения и ограничение. Разработчик или аналитик, который будет повторять расчёт, найдёт детали ниже. Если нет возможности приложить исходный набор данных, запишите версию базы и дату доступа, чтобы объяснить будущие расхождения.

При устной защите начните с вывода, затем назовите две проверки: глобальная повторяемость flight_no и рост строк после соединения. Если интервьюер спросит, что бы вы сделали при ещё одном часе работы, предложите сверку охвата источника и соседних дат. Ответ «нарисовал бы ещё график» не закрывает главный риск интерпретации.

Как объяснять решение на интервью: двенадцать вопросов

Таблица — репетиция разговора о вашем тестовом. Не учите её дословно: подставьте фактическое зерно и источник своей задачи. В колонке ошибки показано, какая привычка мешает даже при верном запросе.

Если задание другого типа: перенесите логику

В продуктовой задаче на падение метрики начните с определения метрики и проверки, не изменилось ли событие. Разложите показатель по этапам и сегментам, а причину формулируйте после проверок. В дашборде поставьте решение и главный показатель выше второстепенных графиков, подпишите источник и зерно. В системном задании вместо доли пропусков разберите сценарий, контракт, повтор запроса и контроль ошибок.

Для SQL-теста с несколькими запросами разумно приложить контрольные проверки каждого ключа. Если время короткое, оставьте лучше один корректный запрос с честным выводом, чем пять без единой проверки. Дополнительную работу отделите разделом «что проверил бы дальше», чтобы она не выглядела невыполненной частью обязательного задания.

Для Excel-файла продемонстрируйте определения столбцов и один контрольный итог вне сводной таблицы. Для Python-ноутбука отделите очистку от расчёта, напечатайте размер выборки после каждого существенного фильтра и сохраните фиксированный порядок сортировки. Для дашборда подпишите, что происходит с пустыми значениями и какие фильтры действуют по умолчанию. Эти проверки работают независимо от инструмента: читатель должен знать, какие наблюдения вошли в показатель.

Когда тестовое похоже на бесплатную работу

Обсуждайте границы спокойно. Сигналы для разговора: просят анализ внутренних данных с прямым коммерческим применением, объём не ограничен, результат нужен до обсуждения роли, нельзя описать критерии оценки или предполагается запуск решения без вашего участия. По одному сигналу нельзя судить о намерениях; задайте вопросы о времени, обезличивании и том, что именно хотят оценить.

Вежливый ответ: «Готов показать подход на учебном или обезличенном наборе и прислать короткий разбор в согласованной рамке. Полный аудит текущего процесса выходит за эту рамку; давайте выберем один вопрос для оценки навыка или обсудим отдельный оплачиваемый проект». Если условия не подходят, можно отказаться без обвинения. Не публикуйте полученное от работодателя условие или данные: для портфолио создайте собственный синтетический кейс.

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

Ошибки, которые портят даже верный расчёт

Первая — сразу писать запрос без уточнения зерна: общий итог раздувается после соединения. Вторая — использовать номер рейса вместо идентификатора: разные дни смешиваются. Третья — убрать строки без талонов внутренним JOIN: пропуск исчезнет из анализа. Четвёртая — назвать отсутствие записи отсутствием пассажира: вывод не подтверждён.

Пятая — скрыть статус Cancelled внутри общего процента: смысл метрики меняется. Шестая — прислать только ноутбук без ответа: менеджер не увидит решение. Седьмая — приложить результат, который не запускается с начала: техническая проверка остановится. Восьмая — потратить много часов без согласования рамки: оценить владение задачей становится труднее.

План на неделю и частые вопросы

День 1: соберите шаблон сдачи и потренируйтесь уточнять неполное условие. День 2: решите задачу на ключи и JOIN, сверьте контрольный итог. День 3: сделайте короткую записку и попросите другого человека назвать недоказанный вывод. Дни 4–5: повторите на продуктовом или процессном кейсе. День 6: прогоните файлы на чистом окружении. День 7: проговорите решение вслух за пять минут.

Нужно ли делать идеальный дашборд? Нет, если проверяется аналитический вывод; уточните критерий оценки. Можно ли задавать вопросы интервьюеру? Да: конкретный вопрос к определению метрики часто часть работы аналитика. Можно ли использовать нейросеть? Согласуйте правила задания, проверяйте расчёты и будьте готовы объяснить каждую строку. Стоит ли отправлять неполное решение? Отправьте честно ограниченный результат, если рамка и срок это допускают.