⚡️Пошаговый план: как получить оффер на аналитика в 2026 году?

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

Это очень полезное событие для тех кто только зашел в аналитику и для тех, кто хочет в нее зайти в ближайшее время. Особенно если вы не понимаете, какие навыки действительно важны или боитесь, что без опыта вас не возьмут на работу. Кстати тут разберут и возрастной аспект: как стать аналитиком в 30/40/50 лет и т.д.

На вебинаре будет:
🟠Разберем полный роадмап: что учить, в каком порядке, до какого уровня;
🟠Структура хорошего портфолио с примерами;
🟠Что говорят реальные наниматели - какие у них сейчас требования:

— Покажем реальные примеры, как оформить резюме и портфолио, чтобы привлекать внимание;
— Обсудим какие отклики работают, а какие сразу отправляют в корзину;
— Изнанка найма: инсайдерский взгляд на процессы отбора

🟠 Практические техники для новичков: разберём, как компенсировать недостаток опыта и быстро закрывать пробелы в знаниях.

💬 Всем зарегистрировавшимся Simulative пришлют полезный материал — карту компетенций аналитика данных со всеми нужными инструментами для освоения.

😶Зарегистрироваться на бесплатный вебинар

🖥 SQL задачка на внимательность (и одна классическая ловушка)

У тебя есть таблица логов. Нужно найти пользователей, которые заходили 3 дня подряд.

Таблица:
- user_id
- event_date (DATE)

Задача:
Верни user_id и дату третьего дня серии (то есть конец 3-дневной цепочки).

Ловушка:
1) В один день может быть несколько событий - их нельзя считать как разные дни
2) Дни должны идти подряд по календарю (не “3 записи подряд”)

-- PostgreSQL / MySQL 8+ (через window functions)
WITH uniq_days AS (
  SELECT DISTINCT user_id, event_date
  FROM user_events
),
grp AS (
  SELECT
    user_id,
    event_date,
    event_date
      - INTERVAL '1 day' * (ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_date))
      AS anchor
  FROM uniq_days
),
runs AS (
  SELECT
    user_id,
    MIN(event_date) AS start_day,
    MAX(event_date) AS end_day,
    COUNT(*) AS days_cnt
  FROM grp
  GROUP BY user_id, anchor
)
SELECT user_id, end_day AS third_day
FROM runs
WHERE days_cnt >= 3
ORDER BY user_id, third_day;

Почему это работает:
- DISTINCT убирает повторы в один день
- “anchor” превращает подряд идущие даты в одну группу
- дальше считаем длину серии и берём конец

📌 Банхаммер Anthropic: как потерять доступ к API, заставив Claude писать инструкции для Claude.

Любопытный кейс португальского разработчика Хуго Даниэля, который решил поиграть в жесткую автоматизацию с Сlaude Сode. и проиграл

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

🟢Claude A (в одном окне): отвечает за обновление файла CLAUDE.md. Это файл с контекстом и инструкциями, как вести себя модели в конкретном проекте.

🟢Claude B (в другом окне): пытается выполнять задачи внутри этого проекта, используя инструкции из CLAUDE.md.

🟠Loop: когда Claude B косячил, Хуго копировал ошибку, скармливал ее Claude A и говорил: "Поправь инструкции, чтобы этот дурак больше так не делал".

В какой-то момент Claude A, видимо, устал от тупости коллеги и начал генерировать инструкции капсом, чтобы жестко задать поведение - файл наполнился директивами, которые выглядели как System Prompts.

🟡На этом этапе Хуго и получил бан от Anthropic.

Гипотеза бана в том, что сработали эвристики защиты от Prompt Injection. Система безопасности Anthropic увидела, что пользователь генерирует и скармливает модели текст, который структурно и лексически выглядит как системные инструкции. Вобщем, для алгоритмов безопасности это выглядит как попытка джейлбрейка.

Ожидаемо, саппорт хранил молчание: ни через систему апелляции (она, кстати на Google Forms), ни письма в поддержку не дали результатов. Через насколько дней пришел только молчаливый возврат средств за подписку. Так что причины блокировки так и остались гипотезой.

🟡Автор справедливо замечает: хорошо, что это был не Google.

Если бы подобный эксперимент проводился у "Корпорации Добра" - сработал бы их вездесущий триггер на "злонамеренную активность", и человек мог бы потерять Gmail, Google Photos, документы и получить кирпич вместо Android-смартфона.

История Хуго - хорошее напоминание о том, что модерация в ИИ сейчас - это черный ящик.

Если вы занимаетесь авто-генерацией промптов, которые выглядят как системные инструкции (то, что называют meta-prompting и scaffolding) - вы ходите по минному полю.



@ai_machinelearning_big_data

#AI #ML #Story #Anthropic

🖥 SQL: ЛОВУШКА ДУБЛЕЙ И ДАТ

Иногда самая коварная задача - найти “покупали 3 дня подряд”. Профи часто делают self-join на даты, но он ломается на дубликатах, таймзонах и нескольких покупках в день.

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

-- Задача:
-- Найти пользователей, которые совершали покупку 3 календарных дня подряд (минимум).
-- Условия:
-- 1) В один день может быть много покупок - считаем день один раз.
-- 2) Нужны именно подряд идущие дни без пропусков.
-- 3) Вернуть user_id и начало/конец самой длинной серии.

WITH days AS (
SELECT DISTINCT
user_id,
DATE(created_at) AS d
FROM orders
),
grp AS (
SELECT
user_id,
d,
-- трюк: для подряд идущих дат разность (дата - номер) постоянна
DATEADD(day, -ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY d), d) AS g
FROM days
),
streaks AS (
SELECT
user_id,
MIN(d) AS streak_start,
MAX(d) AS streak_end,
COUNT(*) AS streak_len
FROM grp
GROUP BY user_id, g
)
SELECT user_id, streak_start, streak_end, streak_len
FROM streaks
WHERE streak_len >= 3
ORDER BY streak_len DESC;

🖥 Большинство “парсеров” умирают через 2 дня.
Ты научишься делать те, которые живут в проде.

Это не про BeautifulSoup ради галочки.
Это про системы сбора данных, которые:

• не падают от мелких правок на сайте
• собирают данные в разы быстрее
• обновляют всё сами по расписанию
• обходят ограничения и баны
• выглядят как сервис, а не хаос из файлов

Ты начнёшь видеть сайты не как страницы, а как источники данных, к которым можно подключиться.

В итоге ты сможешь:

• забирать данные для своих проектов
• автоматизировать чужую рутину
• делать инструменты для аналитики
• брать коммерческие заказы на сбор данных

Это навык, который напрямую превращается в деньги.
Не “знаю Python”, а умею добывать данные из интернета профессионально.

🎁 48 часов скидка 50% на Stepik: https://stepik.org/a/269942/

🖥 Как не убить базу большими таблицами в SQL - фильтруй и агрегируй как можно раньше

Главная ошибка при работе с большими таблицами - делать SELECT * и потом надеяться, что "оно как-нибудь".

На больших объёмах это превращается в долгие запросы, высокую нагрузку и таймауты.

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

Практическое правило: если запрос возвращает миллионы строк - ты почти наверняка решаешь задачу неправильно. В 90% случаев тебе нужна витрина: GROUP BY, window-функции, или отдельная агрегированная таблица. А чтобы база не страдала, добавляй индексы под фильтры и под JOIN-ключи, и проверяй план выполнения через EXPLAIN.

 ПЛОХО: тащим весь объём и только потом думаем
SELECT *
FROM events
WHERE created_at >= NOW() - INTERVAL '90 days';

-- ХОРОШО: сразу сужаем, берем нужные колонки, считаем агрегаты
SELECT
  user_id,
  COUNT(*) AS events_7d,
  MAX(created_at) AS last_event_at
FROM events
WHERE created_at >= NOW() - INTERVAL '7 days'
GROUP BY user_id;

-- Индекс под фильтр по времени + join по user_id (частый паттерн)
CREATE INDEX IF NOT EXISTS idx_events_created_user
ON events (created_at, user_id);

-- Проверяй план, чтобы не было Seq Scan на миллионах строк
EXPLAIN (ANALYZE, BUFFERS)
SELECT user_id, COUNT(*)
FROM events
WHERE created_at >= NOW() - INTERVAL '7 days'
GROUP BY user_id;