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

Возьмем условный пример из клиентской поддержки.

Слабая версия:
«Готовил еженедельный отчет по обращениям клиентов».
Фраза правдивая, короткая и почти бесполезная. Непонятно, зачем существовал отчет, что в нем делал именно аналитик и мог ли кто-то принять решение после его отправки. Возможно, человек просто нажимал кнопку по понедельникам. Возможно, собрал важный процесс с нуля. Резюме оставляет оба варианта одинаково вероятными.

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

Что изменилось?
Появился контекст: команде нужно было понимать повторяющиеся причины обращений. Видна сложность: два канала и разные формулировки одной проблемы. Понятно действие человека: он не просто «участвовал», а объединял данные и согласовывал классификацию. Наконец, появился результат, не выдуманный рост на 147%, а решение, которое поддерживал обзор.

Это не литературный конкурс. Сильная строка не обязана звучать грандиозно. Она обязана давать собеседнику зацепки для вопросов: как проверяли данные, почему определения расходились, какие разрезы помогали найти проблему?
Если точных процентов раскрывать нельзя или они не сохранились, не нужно сочинять. Масштаб можно показать количеством источников, регулярностью процесса, числом направлений или сложностью согласования. А результатом может быть не только рост метрики, но и выбранный приоритет, найденная ошибка, более прозрачное решение.

Практика на пять минут: открой резюме и найди фразу, которая начинается с «готовил», «занимался» или «участвовал». Добавь к ней три ответа:
1. Какую проблему решали?
2. Что конкретно сделал ты?
3. Какое действие стало возможно после результата?

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

Почему список обязанностей выглядит слабее, чем сам опыт?

Потому что обязанность описывает ожидание от роли, а не то, как ты с ним справлялся. «Анализировал данные», «строил дашборды», «взаимодействовал с заказчиками» можно вставить почти в любую вакансию аналитика. Из этих слов нельзя понять ни уровень задачи, ни твой способ работы.

С инструментами похожая история. Перечень «SQL, Python, Tableau» полезен для первичного соответствия требованиям, но не доказывает применение. Молоток в шкафу еще не сообщает, что его владелец строитель.

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

Я бы искал в каждом сильном пункте пять элементов.
Проблема. Зачем задача появилась? Например, две команды по-разному считали активного пользователя.
Решение. Какой выбор или изменение требовалось поддержать? Согласовать общую метрику для ежемесячного обзора.
Масштаб или сложность. Несколько источников, разные платформы, неоднозначные правила, регулярный процесс. Не обязательно раскрывать конфиденциальные цифры.
Твое действие. Сравнил логику расчетов, нашел расхождения, организовал обсуждение, описал итоговое определение и проверки.
Результат. Команды стали использовать одну логику, а обсуждение перестало начинаться со спора о числах. Это конкретный рабочий эффект даже без процента.

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

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

Хороший опыт становится заметным, когда у рассказа есть маршрут.

Для резюме и ответа «Расскажите о себе» можно использовать один каркас из четырех частей. Объем будет разным, логика общей.

1. Текущая позиция и цель
Кто ты сейчас и какую роль рассматриваешь? Например: «Я аналитик с опытом в операционных задачах, сейчас развиваюсь в сторону продуктовой аналитики». Это быстрее задает контекст, чем хронология от первой подработки.
2. Релевантное доказательство
Выбери один-два эпизода, близких вакансии. Не перечисляй десять проектов. Покажи связку: была проблема, ты сделал конкретную работу, команда получила основу для решения.
Например: «В последнем проекте я сопоставил сроки доставки по регионам, выделил этап с основными задержками и помог команде выбрать процесс для первой проверки». Это учебная формулировка.
3. Как ты работаешь
Добавь наблюдаемую привычку: сначала уточняешь решение, согласуешь определение метрики, проверяешь качество данных, проговариваешь ограничения. Вместо «я ответственный» лучше: «Перед выводом отдельно проверяю полноту данных и показываю, какие допущения могут повлиять на решение».
4. Направление и соответствие
Объясни, почему следующий шаг логичен: какие задачи хочешь решать и что в этой роли соединяется с твоим опытом. Без обещания «мечтал о вашей компании с детства», если в детстве ты мечтал в основном не делать домашнее задание.
В резюме этот каркас распределяется по заголовку, краткому профилю и достижениям. В устном ответе он занимает примерно минуту-полторы. Задача не в том, чтобы выучить текст по слогам, а в том, чтобы не терять профессиональную нить.

Небольшое упражнение:
1. Запиши ответ голосом без подготовки.
2. Расшифруй первые 90 секунд.
3. Отметь четырьмя цветами позицию, доказательство, способ работы и направление.
4. Удали детали, которые не помогают понять ни одну из частей.

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

Цель упаковки, не создать идеального кандидата из воздуха. Она скромнее и полезнее: показать настоящую работу в понятной последовательности.

Собирательный учебный кейс, не история конкретного менти. Ситуация составлена из типичных ошибок на тренировках.

Кандидат хорошо знает SQL, повторил статистику и может объяснить основные продуктовые метрики. Ему дают задачу: в сервисе снизилась конверсия из оформления в оплату. Нужно рассказать, как искать причину.

Первые несколько секунд он молчит. Затем выбирает одну версию, например, ошибка на платежном шаге, и начинает строить под нее подробную проверку. Когда интервьюер добавляет, что технических ошибок не нашли, кандидат останавливается. Не потому, что больше ничего не знает. Он решил, что первая версия должна была оказаться «правильным ответом», а подсказка прозвучала как отметка красной ручкой.

Знаний здесь достаточно для продолжения. Можно уточнить период изменения, сегменты пользователей, платформы, источники трафика, изменения в продукте и качество событий. Можно разделить факт «конверсия снизилась» и предположения о причинах. Но в моменте человек занят другой задачей: пытается угадать, какую мысль спрятал интервьюер.

Так кейс превращается в викторину. В голове запускается поиск по конспекту: «Где был похожий пример? Какая метрика обычно падает? Что от меня хотят услышать?» Рабочее рассуждение в этот момент выключается, хотя именно его и полезно показать.

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

Даже если первая гипотеза не подтвердится, структура останется. Подсказка тогда не обнуляет ответ, а добавляет новую информацию.

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

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

В продуктовом кейсе финальная гипотеза это только часть ответа.

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

1. Структура
Ты раскладываешь задачу на части или перескакиваешь между версиями? Для падения конверсии можно сначала проверить само измерение, затем локализовать изменение по времени и сегментам, после этого перейти к группам продуктовых и внешних причин.

2. Уточнения и допущения
Хороший вопрос меняет план решения. Например: «Падение видно на всех платформах?» Если данных нет, проговори допущение: «Предположу, что снижение началось одновременно, но отдельно проверил бы версии приложения».

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

4. Поведение в тупике
Если понял что в своих рассуждениях зашел в тупик, то просто зафиксируй границу: «Эта версия не объясняет наблюдение. Вернусь к группам причин и проверю, что пропустил». Это сильнее, чем молча держаться за первую идею или перечислять все подряд.

Мини-чеклист для десятиминутной тренировки:
- переформулировал задачу своими словами;
- уточнил метрику, период и охват изменения;
- отделил известные факты от предположений;
- назвал 2–4 группы причин, а не двадцать случайных гипотез;
- объяснил порядок проверок;
- после новой вводной обновил план;
- завершил промежуточным выводом и следующим шагом.

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

Я тут пропал на пару недель, но виной тому не только работа.

Долго думал как улучшить и систематизировать подготовку к собесу. Тренажеры SQL или pandas, это конечно хорошо, но есть уже много того что ты знаешь и приходится самостоятельно отбирать задачи для решения. А что изучить из теоретической части, вообще не всегда понятно. Мне в свое время помог большой платный курс. Там хотя бы была структура и я понимал что на каком этапе изучать. Но это дорого и долго.

Поэтому я собрал инструмент, который называется "Маршрут".

Работает так. Сначала бесплатная диагностика: 39 вопросов, семь блоков, минут двадцать. На этом этапе важно понять где есть пробелы.
Дальше по этому результату собирается план на месяц: пятнадцать блоков по два дня. Слабые темы получают больше времени и практики, сильные меньше, но при этом они сложнее. Если по ходу начинаешь ошибаться в том, что тест счел сильным, тема возвращается на повторение ближе к финалу.
Каждый день понятно, что делать и сколько это займет (тридцать-шестьдесят минут).

Что внутри, кроме плана:
— премиум-задачи SQL, pandas и A/B с проверкой решения;
— шесть схем разбора кейсов: по одной на каждый тип, который дают на интервью. Это не примеры чужих решений, а порядок — с чего начать, что уточнить, что проверить, чем закончить;
— разбор твоих ответов на кейсы: пишешь своими словами, получаешь четыре пункта — что учтено, что упущено, где формулировка размыта и как сказать конкретнее;
— шесть пробных собеседований с AI и разбором;
— в конце повторная диагностика и отчет: что выросло, что осталось слабым.

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

2 490 ₽ разово, доступ 45 дней — тридцать на план и пятнадцать в запасе, если выбьешься из графика.

Начать стоит с диагностики, она бесплатная и без нее маршрут собрать не из чего: new-lvl.pro/sprint

Конверсия 3%. Можно ли ей верить?

Недавно по работе мне понадобилось рассчитать минимальную выборку.
Вопрос звучал довольно просто: если мы получили конверсию 3%, достаточно ли у нас данных, чтобы принимать решение?
Но выборки не бывает просто «достаточно».

Достаточно для чего?

Чтобы понять порядок величины? Сравнить два периода? Заметить изменение на доли процента? Для каждой задачи потребуется разная точность.
Допустим, мы ожидаем конверсию 3% и хотим измерить её с относительной погрешностью ±20%. То есть получить интервал примерно от 2,4% до 3,6%.
При доверительном уровне 95% нам понадобится около 3 100 наблюдений. При конверсии 3% это примерно 93 целевых действия.

Отсюда удобное правило:
Около 100 конверсий дают точность примерно ±20%.

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

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

И отдельно: если нужно сравнить конверсии двух вариантов в A/B-тесте, это уже другая задача. Там появляются MDE, статистическая мощность и уровень значимости.

Подробно разобрал формулы, примеры и обратный расчёт выборки в статье

Цифра на дашборде всегда выглядит законченной. Но иногда самый честный вывод аналитика не «конверсия равна 3%», а «пока мы знаем только её примерный порядок».

Сто решённых задач могут не сдвинуть тебя с места

Поймал себя на знакомой ловушке.
Открываешь тренажёр, решаешь несколько задач подряд, всё получается с первого раза, галочки загораются зелёным. Закрываешь ноутбук с приятным ощущением: сегодня хорошо позанимался.
А потом на собеседовании появляется задача чуть в сторону и ты снова не понимаешь, с чего начать.
Потому что пятнадцать знакомых задач это не всегда пятнадцать шагов вперёд. Иногда это один и тот же шаг, повторённый пятнадцать раз.

Андерс Эрикссон много лет изучал, как люди становятся экспертами. Один из его главных выводов: для роста недостаточно повторять то, что уже получается. Нужна осознанная практика с понятной целью, обратной связью и задачами чуть сложнее тех, которые ты уже умеешь решать.

Ключевое слово здесь — чуть.

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

Есть даже любопытный ориентир правило 85%. В некоторых типах обучения максимальная скорость прогресса достигается, когда примерно 85% попыток заканчиваются успехом, а 15% ошибкой.
Это не универсальная константа, которую нужно высчитывать после каждой задачи. Скорее хороший сигнал: ошибки во время учёбы не мешают росту, а помогают понять, что именно стоит потренировать.

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

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

После JOIN выручка выросла, хотя продаж больше не стало

Иногда для роста выручки достаточно добавить в запрос один JOIN. Правда, растёт она только в отчёте.
Допустим, покупатель оформил заказ суммарно на 1 000 рублей. Внутри заказа три товара: футболка, носки и кепка.
В таблице заказов этому заказу соответствует одна строка с общей суммой. В таблице товаров заказа три строки, по одной на каждую позицию.

Соединяем таблицы по номеру заказа, чтобы добавить названия товаров. Получаем три строки. И в каждой из них повторяется сумма всего заказа:
- футболка — сумма заказа 1 000 ₽;
- носки — сумма заказа 1 000 ₽;
- кепка — сумма заказа 1 000 ₽.

Теперь считаем SUM(order_total) и получаем 3 000 рублей. Покупатель заплатил тысячу, а отчёт уже перевыполнил план.
На одном заказе всё очевидно. В запросе с несколькими таблицами такую историю заметить сложнее. Особенно если сумма выросла на несколько процентов и выглядит вполне правдоподобно.

SQL при этом не выдаст ошибку. Для каждого товара он нашёл соответствующий заказ и подставил его данные. Всё по инструкции.

Изменилось то, что означает одна строка.
До соединения одна строка была одним заказом. После джойна одной товарной позицией. А складывать мы продолжаем суммы заказов, которые теперь повторяются.

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

И здесь легко попасть во вторую ловушку: написать SUM(DISTINCT order_total). На одном заказе поможет. Но два разных заказа по тысяче рублей превратятся в одну тысячу: DISTINCT различает значения суммы, а не заказы.

Поэтому после соединения полезно проверить три вещи:
- сколько стало строк и ожидали ли мы такое количество;
- сколько осталось уникальных заказов;
- что произошло с контрольной суммой на том же наборе заказов.

Я, очень часто, смотрю промежуточные таблицы глазами, перед тем как приджойнивать их. Это помогает не допускать подобных ошибок.

А у вас бывало, что после JOIN цифры вдруг становились подозрительно хорошими?