0 просмотренных постов скрыто
"Через неделю ты должен быть в Москве". Как меня почти развели на работу
Хочу поделиться историей, которая научила меня важной вещи: если тебя настойчиво зовут на позицию, до которой ты, как сам считаешь, явно не дотягиваешь, — это не удача. Это первый и самый главный звоночек. Я на эту вакансию даже не откликался. Меня сами нашли и сами пригласили.
Я адекватно оцениваю свои возможности и понимал — моё резюме для такой «серьёзной» роли выглядит слабовато. Но нет, меня «согласовали» мгновенно. С этого и началась цепь странностей.
Мне, предложили контракт на объекте прямо здесь, в Красноярске. Звучало отлично: интересный проект, хорошая оплата, никуда переезжать не надо. Изначально речь шла о самозанятости, но поскольку у меня уже есть ИП, я предложил оформить договор с ИП. Они моментально согласились, без единого вопроса. И понеслось.
Всё решили за один звонок с рекрутером, а поговорить с будущим начальником так и не дали — сказали, он меня «уже утвердил по резюме». Когда зашёл разговор о деньгах, я назвал сумму, а в ответ услышал: «А вам точно хватит? Может, больше хотите? Ну я вам добавил немного сверху». Так не торгуются.
А потом выдали главное условие: чтобы начать работу здесь, мне нужно лично приехать в Москву — подписать документы, пройти медкомиссию в их партнёрской клинике и какое то серьезное тестирование. И сделать это нужно срочно: «Через неделю вы уже должны быть на месте, проект не ждёт». Обещали полный компенс: аванс на билеты, и в аэропорту встретят , оплату самой медкомиссии и даже бронь в гостинице (ссылку скинули на гостиницу). Всё за их счёт.
Договор прислали. И вот тут стало совсем тревожно: документ был составлен на коленке, кривой и сырой. Я в молодости и то профессиональнее делал. Вся неделя прошла в звонках и сообщениях: «Где ваши реквизиты для аванса? Подписывайте уже!». Давили так, будто это я их подвожу.
На любые мои вопросы — «Зачем вообще ехать? Почему такие сроки?» — был один ответ: «Давайте я вам позвоню и всё объясню». Звонили, но вместо внятных причин звучала одна вода: «У нас серьёзный заказчик, это его требования, корпоративные стандарты». Никакой конкретики по проекту, по задачам — только туманные отговорки и спешка.
В итоге я просто отказался. Жалею ли я? Нет. Ну может чуток. Но мне до сих пор непонятно, в чём был бы конечный развод. Они ведь ничего не просили — ни переводов, ни кодов. Торопили с договором для «аванса». Может, и впрямь была какая-то дикая, но реальная работа? Или схема была тоньше, и «кидок» планировался на следующем этапе?
Собственно, вопрос к Пикабу: Как думаете, в чём здесь был бы подвох? На каком этапе и по какому сценарию могли бы попросить денег или провернуть аферу? Или, может, я всё же отказался от редкого, но честного предложения?
P.S. Для ясности и структуры текст был оформлен с помощью нейросети.
Показать полностью
Вопрос по HH
Подскажите, искал работников и никогда не видел такую надпись раньше, что она означает?
Что делать, если бизнес сам не знает, что ему нужно
Есть ситуация, знакомая почти каждому аналитику.
К тебе приходит бизнес и говорит:
Нам нужен отчёт
Посмотри цифры
Что-то у нас не так, разберись
И на этом - всё.
Нет метрик.
Нет определения "не так".
Нет ответа на вопрос зачем.
Обычно, на такие вопросы у аналитика есть ответы, если он погружен в предметную область, уже сталкивался с такими кейсами, занимался данной задачей недавно (иногда аналитики на разных проектах параллельно работают и эти проекты не связаны)
А пока подписывайся на мой канала Аналитика FM.
Его я веду с нуля подписчиков.
В этом канале я публикую информацию об инструментах аналитика (SQL, Python)
О мышлении аналитика, о метриках, об ошибках.
Публикую чек-листы по стандартным видам работы аналитика.
Присоединяйся!
Бизнес редко приходит с чётким запросом.
Не потому что он глупый или ленивый.
А потому что бизнес живёт ощущениями, а не формулами.
Продажи "просели".
Конверсия "стала хуже".
Клиенты "ведут себя странно".
Это язык боли, а не требований.
И тут аналитик хочет обезопасить себя со всех сторон:
- написать запрос
- вытащить все данные
- построить отчёт "на всякий случай"
- показать цифры и сказать: "Вот"
Но в реальности это почти всегда заканчивается одинаково:
- "А это не совсем то"
- "А можно по-другому?"
- "А мы вообще не это имели в виду"
Когда бизнес не знает, что ему нужно,
аналитик не исполнитель,
аналитик - переводчик.
Ты начинаешь переводить бизнесовые ощущения в конкретные показатели, и смотреть как эти показатели подтверждают/опровергают эти ощущения. Ты переводишь эмоции в конкретные метрики. Подсознательное ощущение "что-то не так", ты переводишь в конкретные вопросы к данным.
И вот на этом этапе SQL становится не просто инструментом, а следствием мышления.
Очень часто проблема не в том, что запрос неправильный.
А в том, что вопроса не существовало.
Например:
"Продажи упали" - относительно чего?
"Конверсия плохая" - на каком этапе?
"Клиенты уходят" - кто именно и когда?
Пока бизнес не ответил хотя бы на это - любой запрос будет случайным.
Или аналитик с приличным бэкграундом, задаст их сам себе, задаст эти вопросы данным и получит развернутый ответ, чтобы у бизнеса были аргументированные показатели.
И это самый важный навык аналитика. Аналитик не должен просто писать сложные JOIN-ы, он должен уметь задавать вопросы так, чтобы:
- стало понятно, что именно ищем
- появилось ощущение направления
- сузилось пространство неопределенности.
И да - бывает, что бизнес так и не может сформулировать запрос.
Тогда аналитик делает не отчёт, а гипотезу.
Я предполагаю, что проблема может быть здесь.
Давайте проверим это.
Это нормальная практика.
Гораздо честнее, чем молча строить отчёт "на всякий случай".
Самое важное:
если бизнес не знает, что ему нужно - это не ошибка бизнеса.
Это точка, где аналитика становится ценностью!
Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.
Присоединяйся!
Показать полностью
Деньги vs риски: куда движется Хэдхантер
💭 Проанализируем ключевые финансовые показатели и стратегические шаги компании...
💰 Финансовая часть (3 кв 2025)
📊 Компания увеличила свою выручку на 1,9%, достигнув уровня 10,9 млрд рублей. Это стало возможным благодаря росту среднего дохода на каждого клиента (ARPC) и включению показателей дочерней компании HRlink, а также высокому развитию сектора технологий управления персоналом (HRtech).
🔀 Значение скорректированной прибыли до уплаты процентов, налогов, износа и амортизации (EBITDA) уменьшилось на 5,4%, остановившись на отметке 6,6 млрд рублей.
🧐 Показатель рентабельности скорректированной EBITDA упал на 4,6 процентных пункта, опустившись с отметки 64,6% до уровня 60%. Основной причиной стала интеграция отчетности HRlink начиная с четвертого квартала 2024 года, а также общий спад динамики доходов на фоне неблагоприятной макроситуации.
🤔 Кроме того, отдельно выделяется основной бизнес компании, показавший снижение рентабельности скорректированной EBITDA с 66,2% до 64,4%, тогда как сегмент HRtech продемонстрировал ухудшение показателя до минус 13,8% против минус 2,4% годом ранее.
✔️ Развитие
👌 Несмотря на скромные темпы развития своего главного направления, компания HeadHunter активно наращивает присутствие в сфере технологий управления человеческими ресурсами (HR Tech). Хотя вклад этого направления пока небольшой — всего примерно 6% от общей выручки, оно уже оказывает заметное воздействие на компанию. Для укрепления позиций HeadHunter внедряет новые решения, вкладывает средства в перспективные стартапы, создает сервисы на основе искусственного интеллекта и оптимизирует внутренние процессы.
📎 Например, в октябре компания приобрела долю размером 26% в платформе «Моя смена», ориентированной на временное трудоустройство. Этот проект является новым сегментом для HeadHunter, открывающим дополнительные возможности для расширения клиентской базы и диверсификации бизнеса.
📌 Итог
⏯️ Продолжающееся замедление экономического роста и высокий уровень ключевой ставки негативно влияют на ситуацию на рынке труда. Работодатели становятся менее активными, причем наиболее ощутимо это проявляется среди предприятий малого и среднего бизнеса.
🎯 ИнвестВзгляд: Актив удерживается в среднесрочном портфеле.
📊 Фундаментальный анализ: ✅ Покупать - ввиду устойчивого финансового положения, привлекательных дивидендных выплат и хороших перспектив роста.
💣 Риски: ⛈️ Высокие - компания сталкивается с комплексом существенных рисков, включая финансовые, структурные и регуляторные.
💯 Ответ на поставленный вопрос: Хэдхантер движется в сторону активного освоения рынка HRTech, несмотря на слабые показатели роста традиционного бизнеса. Ключевая цель компании — расширение продуктового ряда, внедрение новых сервисов на базе искусственного интеллекта и диверсификация через приобретение перспективных проектов.
🤷♂️ Данный обзор не является индивидуальной инвестиционной рекомендацией. Инвестиции сопряжены с рисками, а фундамент инвестиций — самостоятельность мышления и здоровое недоверие!
⏰ Благодарим Вас за поддержку! Следующий материал уже в работе...
$HEAD #HEAD #HeadHunter #инвестиции #HRtech #анализ #бизнес #акции
Показать полностью
SQL и Python: один запрос - два разных способа думать
Сейчас у аналитика для работы с данными есть два популярных "инструмента" - это SQL и Python.
Часто слышу, что SQL считают "жестким", а Python - "гибким" инструментом в аналитике.
На самом деле разница не в гибкости между этими языками, а в "модели выполнения"
Ниже сравним один и тот же пример реализованный SQL и Python. И проследим, что выполняется на каждом шаге.
А пока подписывайся на мой канала Аналитика FM.
Его я веду с нуля подписчиков.
В этом канале я публикую информацию об инструментах аналитика (SQL, Python)
О мышлении аналитика, о метриках, об ошибках.
Публикую чек-листы по стандартным видам работы аналитика.
Присоединяйся!
Рассмотрим задачу.
Есть таблица заказов. Нужно:
Взять только оплаченные заказы
Посчитать сумму заказов по пользователям
Оставить пользователей, у которых сумма больше 10 000
Отсортировать по убыванию суммы
Как это выглядит в SQL
SELECT
user_id,
SUM(amount) AS total_amount
FROM orders
WHERE status = 'paid'
GROUP BY user_id
HAVING SUM(amount) > 10000
ORDER BY total_amount DESC;
Что происходит на самом деле?
Хотя запрос написан сверху вниз, выполняется он иначе:
FROM — база берёт таблицу orders
WHERE — отфильтровывает только status = 'paid'
GROUP BY — группирует строки по user_id
SUM(amount) — считает сумму внутри каждой группы
HAVING — отбрасывает группы с суммой ≤ 10 000
SELECT — формирует финальные колонки
ORDER BY — сортирует результат
SQL не идёт шаг за шагом как сценарий. Для него каждый запрос - это единый слепок результата
Ты не "живешь" внутри процесса, ты его декларируешь.
Теперь тот же самый запрос в Python (pandas)
Чтобы не увеличивать объем строк с подключением к БД, сделаем так, что наши данные мы читаем из CSV файла
Ты загружаешь данные. Ты их уже видишь. Они лежат в память, у них есть текущее состояние.
import pandas as pd
df = pd.read_csv('orders.csv')
2. Фильтрация
paid_orders = df[df['status'] == 'paid']
paid_orders.head()
Здесь отфильтровали данные, можно посмотреть, что получилось, можно вернуться назад.
Это состояние сохранилось.
3. Группировка и агрегация
grouped = (
paid_orders
.groupby('user_id')['amount']
.sum()
.reset_index(name='total_amount')
)
grouped.head()
Ты видишь промежуточный результат:
пользователей
их суммы
можешь проверить аномалии
4. Фильтр по агрегату
filtered = grouped[grouped['total_amount'] > 10000]
filtered.head()
5. Сортировка
result = filtered.sort_values('total_amount', ascending=False)
result
Ключевая разница
SQL
- нет "текущего состояния"
- каждый запрос - это новый расчет
- описываем, что хотим получить
- оптимизатор решает как
Python
- данные живут в памяти
- каждый шаг меняет состояние
- на каждом шаге можно остановиться, посмотреть, вернуться, ветвить логику
На практике аналитик:
- думает как в Python
- реализует как в SQL
- и постоянно переключается между этими моделями
Получается, что SQL и Python - это два разных способа мышления.
SQL говорит нам - вот результат
Python - вот процесс.
Python - это процедурный подход.
Аналитик говорит КАК делать:
- возьми данные
- отфильтруй
- посчитай
- отсортируй
- покажи результат
Здесь происходить управление процессом: мы ведем данные по шагам
SQL - декларативный подход.
Аналитик не говорит КАК делать, он говорит, что хочет получить.
В разбираемом примере мы говори:
Хочу видеть сумму заказов по пользователям,
только оплаченные,
только больше 10 000
Для SQL есть входные данные, правила отбора, финальный результат.
SQL не живет во времени, он живет в описании результата
Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.
Присоединяйся!
Показать полностью