В больших корпорациях есть методология выявления сотрудников с высоким потенциалом. Некоторые изобретают свою, некоторые по ощущениям, а кто-то берет готовый фреймворк, как например в статье The Ultimate Guide to High‑Potential Identification

В статье рассказывают про HiPo сотрудников (high‑potential) - это сотрудники с высоким интеллектом, стремлением к росту, гибкостью и лидерской направленностью, способные эффективно справляться с более сложными ролями в будущем.


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

Популярные инструменты для оценки HiPo:
- Assessment & Development Centers (ACDC) - виртуальные, традиционные или смешанные центры оценки с ролеплеями, симуляциями, интервью, тестами
- 360‑градусная обратная связь - отзывы от самих сотрудников, коллег, подчинённых и клиентов как инструмент анализа потенциала
- Assessment‑тесты - краткие стандартизованные тесты на личность, когнитивные способности, обучаемость; подходят для больших групп и начальных уровней

К сожалению здесь большую роль играет человеческий фактор. Из инструментов я использовал 360-градусов обратную связь.

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

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

Для контекста. Из компании Газпром-Медиа уволили накрутчика опыта, который работал над Rutube. Сотрудники службы безопасности нашли отзыв, который он оставил год назад, где рассказал, что накрутил опыт. Накрутчик работал в компании около года. С его перформансом всё было в порядке. Он готовился идти на повышение.

То есть ещё раз: нормально работающего сотрудника уволили за то, как он попал в компанию год назад.

Газпром-Медиа решили пойти дальше и устроили охоту на ведьм. Сотрудник считается заведомо недобросовестным, если подписан на «Осознанную Меркантильность» (далее «ОМ»). Плевать, накручивал он опыт или нет, как использует сообщество, работает ли на нескольких работах и т. д. Сам факт подписки уже является поводом расторгнуть рабочие отношения.

В Газпром-Медиа запущено так называемое «дело волков» (я не шучу, они сами так его называют), людей водят на допросы в службу безопасности, где светят лампой в лицо.

Охранительная часть IT-комьюнити рукоплещет Газпром-Медиа за такую инициативу. Глеб Михеев написал:

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

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

Сам Глеб занимал пост «Директор по развитию образовательной платформы» в Skillbox. Работа там, кстати, на репутацию не влияет. Skillbox всего лишь оставил тысячи людей с кредитами, не дав ничего взамен. А вот подписка на «ОМ» — это клеймо на репутации.

Зачистку же внутри Rutube проводит ещё один моральный камертон отрасли, Head of Client Development в Rutube, Максим Ульянов. На скриншоте его сообщение из внутреннего рабочего чатика. Давайте представим, что институт репутации действительно есть. А вы работаете в государевом видеохостинге, который существует из-за двух причин: распилить гос. бабки и отрезать граждан собственной страны от информации. Плюсом, Rutube — рассадник пиратского контента. Но вы не перепутайте, у Максима репутация просто прекрасная, а вот у подписчиков «ОМ» — нет.

Максим и Глеб, очень хорошо учить других жизни и говорить про репутацию, когда у самих рыльце в пушку. Репутации в IT нет, и вы вдвоём — выгодоприобретатели этого. Потому что если бы она была, то первой бы ударила по вам.

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

Как любил говорить мой любимый учитель английского в лицее №1501: «Когда одним хорошо, другим дурно».
Когда читаешь истории о людях, которых увольняют из-за ерунды, становится грустно. Если бы я сам всегда был честен, не уверен, что смог бы перейти с завода ГКНПЦ им. Хруничева в Cetelem (BNP Paribas). К сожалению, у меня не было ментора, который мог бы подсказать, что учить, что говорить. Первые три месяца я вообще работал бесплатно.

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

А теперь представим: вы захотели работать в ИТ, но у вас нет профильного образования и опыта. Что делать? Заплатить 150–250 тысяч за псевдокурсы с обещаниями трудоустройства? Или смириться и пойти в курьеры?

Лучшее, что можно сделать — найти эксперта, ментора, который подскажет, как достичь желаемого. Он объяснит, что делать, чтобы не тратить деньги впустую. Окей, допустим, человек приукрасил опыт. А что, если реального опыта нет, но человек соображает, задачи решает, хочет развиваться, учиться и зарабатывать? Так не мешайте ему. Если работает плохо — расстаньтесь. Но не нужно из мухи делать слона.

Из подобных историй видно: процессы найма кривые, а некоторые менеджеры — самовлюблённые, без реальных заслуг, с посредственной жизнью. Такие пытаются самоутвердиться за счёт подчинённых. «Максимов» и «Глебов» хватает везде — и не только в отечественных компаниях. Обижаться на них не стоит — скорее всего, у них в жизни всё непросто и нечем гордиться.

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

Сообщества вроде «ОМ» и «Волки» лишь один из множество путей попасть в ИТ, причем как мы видим, довольно успешный. Сообщество решает классическую проблему отсутствия опыта, просто делают это немного эпатажно. Примерно тем же занимается Datalearn, Surfalytics. Все, кто пробился с их помощью — крутые ребята, которые действительно умеют работать.

А если кандидат слабый, не хочет и не умеет работать — это зона ответственности HR и Hiring Manager: либо отсеять, либо платить достойно, вовремя повышать, чтобы не было желания «убегать налево».

Интересная статья про отрицательную селекцию

Snowflake самый популярный и при этом “простой” инструмент. Почему “простой” в кавычках? Потому что с ним легко начать, везде всем знакомый SQL, запросы всегда работают, можно обрабатывать огромные массивы данных, маштабироваться горизонтально и вертикально. В общем одним плюсы на старте, а потом как повезет.

В посте товарищ указал на некоторые из проблем, с которыми он столкнулся:

Я работаю с технологией Snowflake уже 7 лет, и вот вещи, с которыми большинство внедрений Snowflake сталкиваются и с большим трудом справляются.
- Role-based access control — Очень легко создать полный хаос, после чего команда DBA оказывается навечно занята решением проблем с доступами.
- Virtual Warehouse deployment — В итоге у вас появляется сотни VW, и расходы стремительно выходят из-под контроля.
- Data Clustering — Они не работают как индексы и часто приводят к огромным затратам без какого-либо прироста производительности.
- Migrating to Snowflake — На первый взгляд кажется, что это намного проще, чем миграция на Oracle (или с него), но затем вы понимаете, что Snowflake сильно отличается — а миграции баз данных вообще всегда болезненны.
- Performance vs. Cost — В Oracle или SQL Server вы раньше просто тюнили производительность. В Snowflake же у вас три конкурирующие задачи:
- (a) Performance — как можно быстрее выполнять пользовательские запросы
- (b) Throughput — обрабатывать огромные объёмы данных, т.е. буква T в ELT
- (c) Cost — о которой вы даже не задумываетесь, пока менеджеры не начнут жаловаться, что система обходится в миллионы долларов в год.

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

Цена у Snowflake всегда боль. А с тюнингом не заморачиваются, просто увеличивают размер VW или кластера.

Альтернативы всегда есть, но как всегда в ИТ это tradeoff.

Какая мораль истории? Во всех аналитических проектах, даже если там не Snowflake, всегда важна безопасность, цена и производительность. Именно на этом и нужно акцентировать внимание при работе и собеседованиях.

Data Observability относится к data engineering, и является его неотъемлемой частью, согласно best practices, конечно.

У меня давно в закладках лежит статья - SLA vs SLO.

В больших компаниях мы часто можем слышать про SLA и SLO, и даже SLI. Очень часто их путают. Поэтому статья помогает понять, что для чего и как использовать.

📌 Зачем вообще всё это нужно?
SLA, SLO и SLI — это инструменты управления надёжностью сервисов. Они помогают установить понятные и измеримые ожидания между теми, кто предоставляет сервис (разработчики, команды, компании), и теми, кто его использует (внутренние или внешние клиенты).

💡 Основные термины:
SLI (Service Level Indicator) — Показатель уровня сервиса: метрика, которая показывает, насколько хорошо работает сервис с точки зрения пользователя (например, доступность, время отклика, процент ошибок).

SLO (Service Level Objective) — Целевой уровень сервиса: цель по метрике (например, “доступность 99.9% за 30 дней”). Если сервис ниже цели — это тревожный сигнал, может остановиться деплой, пойдут расследования.

SLA (Service Level Agreement) — Юридическое соглашение об уровне сервиса: официальный контракт, в котором закреплены SLO и последствия их невыполнения (штрафы, компенсации). Обычно используется во внешних отношениях с клиентами.

🤝 Зачем это нужно:
Командам — чтобы знать, когда сервис работает плохо и нести ответственность.
Бизнесу — чтобы договариваться с клиентами на чётких условиях.
Пользователям — чтобы понимать, на что можно рассчитывать (и требовать компенсацию при сбоях).

🧭 Простая аналогия:
SLI — это стрелка на спидометре.
SLO — это знак "не ехать быстрее 100 км/ч".
SLA — это штраф за превышение.

Практически на всех проектах по инжинирингу данных обсуждается тема мониторинга, но очень редко мы действительно устанавливаем метрики, ведь в большинстве случаев аналитика и хранилище данных это не business critical приложение, и если что-то сломалось, то мы можем починить в течения дня. Хотя было бы неплохо установить SLO для бизнеса, что хранилище данных и отчетность будет доступна 99% в течение рабочего времени. И даже если это не соответствует действительности, мы можем установить начальную точку и двигаться в сторону улучшения. Как правило у нас SLA не будет, да и SLI тоже не обязателен.

А есть совсем другой пример, когда компания продает данные американских клиентов (их обезличенные гео данные на млн долларов) в другую компанию, которая находится за пределами США. Эта компания, использует данные для классической аналитики трафика людей в разных городах. Так как компания платит большие деньги они установили SLO и SLA. И в случае сбоев выставляют штрафы. Из недостатков такого проекта для дата инженеров - on-call.

SLI (Service Level Indicators) — метрики, которые мы измеряем:
unique_user_count - Кол-во уникальных пользователей в часовой выгрузке
event_volume_total - Общее кол-во событий в часовой выгрузке

SLO (Service Level Objectives) — цели по этим метрикам
unique_user_count - > 90% от среднего значения за 4 недели
event_volume_total - > 90% от среднего значения за 4 недели
data_delivery_lag_minutes - < 10 минут задержки 99% времени
data_integrity_flag - 100% данных доставлены без ошибок 98% времени

SLA (Service Level Agreement) — договор с клиентом, в котором
- Фиксируете SLO (например, 98% своевременных поставок в течение месяца)
- Описываете последствия (например, штрафы, перерасчет, SLA-кредит)
- Уточняете исключения (форс-мажор, проблемы на стороне клиента)
- Описываете процесс эскалации и ответственности

Пример SLA-формулировки:
Мы гарантируем доставку данных каждый час в течение 10 минут после окончания часа. Минимально допустимый объем — не менее 90% от среднего за предыдущие 4 недели. Если в течение календарного месяца нарушены более 2 SLA-интервала, предоставляется SLA-кредит 10% от месячного счета.

Цифры SLA у нас в договоре другие, метрики такие как я указал.

Само решение достаточно не сложное, данные все хранятся в AWS S3 в Parquet. Другая команда использует kinesis и пишет в S3. Данные каждый час обрабатываются с помощью Athena и запускается в Glue Python Shell (даже не PySpark). Результат складывается в другой S3 bucket и дальше он проверяется с помощью другого Glue Job. Все метрики публикуются в Cloud Watch.

Cloud Watch подключен через SNS topic к Pager Duty, и в случае отклонения получаем alert в Slack. Сейчас решение мигрируется в Databricks, таблицы переходят с Parquet на managed delta tables (Parquet + Delta log). Для проверки качества данных используем DBX библиотеку. Самое забавное, цена в Databricks получается значительно дороже, чем в Glue Athena. В качестве оркестратора AWS Managed Airflow.

MWS Cloud запустила платформу для внедрения и работы ИИ, выйдя на рынок объемом более 15 млрд рублей.

Платформа Inference Valve помогает вывести в продакшн обученные ML-модели, большие языковые модели и модели компьютерного зрения. С помощью платформы их можно разворачивать на инфраструктуре, подключать к ИТ-системам компаний через стандартные API, масштабировать, а также обновлять и мониторить.

После запуска кластера специалисты заказчика загружают артефакты модели (например, ONNX, TorchScript) в платформу, после чего она автоматически формирует контейнер сервиса и публикует эндпоинт. Платформа поддерживает одновременную работу сразу с несколькими моделями с выделением квот вычислительных ресурсов, управление версиями, маршрутизацию трафика между версиями и масштабирование под нагрузку как на GPU, так и на CPU.

Inference Valve также предоставляет метрики задержек и пропускной способности, мониторинг доступности, алёрты и дашборды; доступна телеметрия качества, включая отслеживание дрейфа данных и моделей, контроль целевых метрик и уведомления при деградации. Интеграция с системами наблюдаемости (Prometheus/Grafana) и журналированием запросов упрощает аудит и разбор инцидентов.


По словам CEO MWS Cloud, исполнительного директора МТС Web Services Игоря Зарубинского, платформа позволяет:

- В десятки раз быстрее интегрировать LLM и CV-модели с ИТ-системами компаний;

- На 70% снизить операционную нагрузку на ML-команды при эксплуатации моделей;

- Повысить автоматизацию CI/CD более чем на треть;

- Уменьшить затраты на GPU более чем на 15%;

Пример data stack в компании Clair. Взял у них в Linkedin.

Очень стандартный и понятный кейс. Если сравнить с РФ кейсом, то на российском рынке нет 3rd party managed продуктов для ETL, BI, DW. Ну как нет, они-то есть, но всегда возникает вопрос, а где хостить? А где хранить данные? Вроде бы облаком можно отечественным, но вот много всяких НО.

Поэтому по опыту общения с коллегами вижу два основных направления:

1) полностью on-premise так, где может быть Hadoop+HDFS+Spark, Greenplum или Clickhouse.
Все остальное для слоя хранения редко и не обычно. Есть еще множество старых и надежных решений на SQL Server.

Для загрузки данных используют Python и запускают его в Airflow, иди стрим через Kafka.

2) компании по смелей или по меньше уже могут идти в облака и строить там аналитические решения на VK, Ya облаках. Причем у них есть отличная возможность хостить все на Managed Kubernetes, чтобы развернуть Airbyte, Metabase, Trino и тп. Такой кейс будет очень похож на западный, но выбор инструментов будет достаточно скуден и устоявшийся

На западе наоборот все, мы сначала выбираем public cloud - AWS, Azure, GCP. Затем выбираем слой хранения (Snowflake, Databricks, Trino, Athena, Synapse, BigQuery) и потом уже решаем как туда загружать данных и как их визуализоровать. Как правило все инструменты отлично поддерживают кейсы для ML, Streaming, Reverse ETL.

Еще кардинальная разница будет в DevOps и Data Observability. На западе очень много решений на любой вкус и цвет и все они стандартизированы и работают с любым из публичных облаков.

Поэтому в зависимости от ваших карьерных целей, ваш road map может отличаться.

⚡Гендиректор GitHub Томас Думке уходит, чтобы вернуться к работе над стартапами.

- Microsoft не будет назначать нового CEO и полностью интегрирует GitHub в свою AI-команду CoreAI.

- Теперь GitHub станет ещё теснее связан с развитием инструментов на базе искусственного интеллекта, таких как Copilot.

https://www.theverge.com/news/757461/microsoft-github-thomas-dohmke-resignation-coreai-team-transition

https://news.ycombinator.com/item?id=44865560

Для всех кто делает курсы - пример отличного pivot, как залететь в топ и создавать учебный контент, собирать лайки и просмотры😃

996 - новая норма для AI стартапов и BigTech.

Это значит с 9 утра до 9 вечера 6 дней в неделю. Говорят, что в Китайских компаниях это норма. Хотят недавно казалось, что все единогласно были против crazy work hours в западном мире. Так же, как и кто-то говорил, что 4х дневная рабочая неделя это круто и эффективно. Некоторые СЕО вообще говорят, что 6 дней это хорошо, но лучше 7 дней. Короче grinding in the office day and night это новая норма.

Время прошло, и теперь компании с самыми высокими зарплатами хотят, чтобы люди работали в офисе, 80+ часов в неделю. Чтобы себя заставить так много работать, надо от этого балдеть. Чтобы кайфовать от того, что ты делаешь, должен быть хороший incentive.

Я вообще верю, что в основе любой мотивации лежит incentive, он может быть материальный и нематериальный. В случае с AI компаниями, им удается сразу платить намного выше рынка, даже рядовым инженерам. И все они работают над крутой миссией, ощущая себя причастным к великому. Часто в ущерб здоровью и семье. Но каждый волен делать, что ему нравится.

Возможно когда вам 20-30, самое время фигачить по 80+ часов и зарабатывать как CEO. Хотя реальность такова, что вы можете работать столько же много и получать низкую зарплату, и даже не работать на созданием AGI, а просто ковырять кривые отчетики в токсичной компании с токсичным руководством.

С другой стороны, чтобы создать что-то великое, нужно пахать, пахать и гореть тем, что ты делаешь - get rich or die trying?:)

Я уверен у каждого должен быть период в жизни 996, но это не должно становится нормой. Тут как в анекдоте про профессионалов и любителей.

Вызывают на заводе двух инженеров чинить сломавшийся станок.

Любитель:
Приходит с чемоданом инструментов, раскручивает половину станка, меняет кучу деталей, возится весь день. В итоге станок кое-как заработал, но с грохотом и искрами.

Профессионал:
Приходит, слушает станок пять секунд, достаёт маленький молоточек, тук — и всё заработало идеально.

Директор удивлён:
— И за что вы хотите 500 долларов? За один удар?

Профессионал:
— Нет. Один доллар — за удар.
499 — за то, что знал, куда ударить.

Мораль, чтобы иметь хорошую карьеру, зарабатывать выше рынка, вам не обязательно работать в AI стратапе 996. Даже работаю в AI стартапе, вы все еще должны думать о job security. Совсем недавно, Cognition купил остатки Windsurf. Сразу уволили 30 человек. Остальным 200 предложили buyout, чтобы они ушли. Их СЕО сказал - «Мы не верим в work-life balance — миссия настолько важна, что разделить её с жизнью нельзя»

Поэтому каждый сам выбирает, что его делает счастливым🤝