Лев говорит

«Как работает градиентный бустинг?» Это не вопрос, на котором нужно валить кандидата 💻

На ML-собеседованиях я часто спрашиваю: как работает градиентный бустинг?

Обычно человек начинает уверенно:

> «Это ансамбль деревьев, который последовательно исправляет ошибки предыдущих моделей».

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

И вот здесь нередко заканчивается уверенность. Человек помнит, что бустинг «исправляет ошибки», но не может объяснить, что новое дерево обучается на направлении уменьшения функции потерь, а не просто получает исходный таргет ещё раз. Это не повод ставить крест на кандидате. Не знать внутренности конкретного алгоритма можно, особенно если последние два года ты решал задачи, строил пайплайны, общался с бизнесом и не выводил формулы на доске. Такой пробел реально закрыть за пару вечеров.

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

📌 Хорошая реакция:

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

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

🚩 Плохой сценарий начинается с оправданий:

> «А это вообще спрашивают на Senior?»
> «Я с университета математику не трогал».
> «Да все же просто CatBoost вызывают».

Использовать CatBoost, конечно, можно. Но если ты претендуешь на Senior-роль, от тебя покупают не только способность вызвать fit(). От тебя покупают способность заметить неизвестное, не скрыть риск за уверенным тоном и быстро разобраться, когда от этого зависит решение. Никто не обязан знать всё, и идеальных собеседований не существует. Но пытаться защитить пробел фразой «это не должны спрашивать» — плохая стратегия. Работодатель не перестанет проверять то, что считает важным, а ты просто отдашь ему сигнал, что с обратной связью может быть тяжело.

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

Четыре инженера не равны команде продукта. 📦

Когда мы делали pdf2latex, нас было четыре инженера. Мы умели собирать Telegram-ботов, обучать модели, распознавать формулы, работать с изображениями и думать об архитектуре. Для второго курса это казалось почти идеальной командой.

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

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

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

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

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

Самое опасное, что это происходит не только с новичками. Я видел зрелые команды из сильных и опытных инженеров, с большими бюджетами и высокими ФОТами. Уровень разработки был действительно серьёзным. Но продукт всё равно месяцами или годами оставался «почти готов». Потому что готовность продукта определяет не команда. Определяет не количество написанного кода, не красивая архитектура, не покрытие тестами и даже не удобство интерфейса, которое инженеры оценили на внутренней демо-встрече. Всё это может быть важно позже. Но на этапе MVP главный вопрос другой: готов ли кто-то регулярно отдавать за ваше решение деньги? 💰

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

Почему блог для меня не медиа, а инфраструктура

Я долго относился к блогу как к чему-то второстепенному. Есть работа, проекты, курсы, консультации, реальные задачи, реальные деньги. А блог где-то сбоку. Написал пост, получил несколько реакций, стало приятно, пошёл дальше заниматься нормальными делами. Но чем больше я думаю про продукты, образование и активы, тем сильнее понимаю одну вещь: блог для меня не медиа. Блог, это инфраструктура.

Медиа в моей голове, это борьба за внимание. Нужно чаще публиковаться, громче формулировать, быстрее реагировать на инфоповоды, собирать просмотры. В этом нет ничего плохого, но это не совсем то, что я хочу строить. Инфраструктура, это другое. 🗻

Это система, через которую постепенно накапливается доверие. Человек читает один пост про карьерную ошибку, потом второй про ML-метрики, потом третий про курсы, потом видит, как я думаю, как ошибаюсь и как принимаю решения. В какой-то момент между нами появляется контекст. Не “вот случайный человек из интернета что-то продаёт”, а “я примерно понимаю, как он мыслит”. 🧠

Когда я делал курсы на чужих платформах, я думал в основном про качество материала. Хорошая программа, понятные объяснения, практика, структура. Казалось, что если продукт хороший, он как-то сам найдёт людей. Потом реальность мягко объяснила, что нет. Можно сделать нормальный продукт, но если у тебя нет канала дистрибуции, аудитории и доверия, продукт может просто лежать на платформе и ждать чуда. А чудо обычно занято другими делами. 📦

И вот здесь блог начинает выглядеть иначе. Это не место, где я “пишу мысли”. Это место, где я строю несколько важных вещей:
• собственный канал дистрибуции 💰
• публичную историю своих решений 💻
• связь с людьми, которым близки мои темы 😸
• проверку гипотез через реакцию аудитории 💯
• репутационный капитал 📈
• архив мыслей, к которому можно возвращаться 📦

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

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

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

Главный вывод для меня такой: если ты хочешь меньше зависеть от обмена времени на деньги, тебе нужна не только экспертиза. Тебе нужна инфраструктура, через которую эта экспертиза доходит до людей. Для меня такой инфраструктурой постепенно становится блог. 📈

Почему в ML-задаче важно заранее договориться о критериях успеха 🧠

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

Data Scientist смотрит на ROC-AUC и считает, что результат хороший. Бизнес смотрит на количество обработанных клиентов и не понимает, почему эффект не виден. Операционная команда говорит, что не успевает разбирать все срабатывания. Продакт спрашивает, как это повлияло на конверсию. В итоге спор начинается не потому, что модель обязательно плохая, а потому что критерии успеха не были проговорены заранее.

Перед началом ML-задачи полезно договориться минимум о нескольких вещах:

📌 Какая бизнес-проблема решается? Не «обучить модель оттока», а «снизить отток платящих клиентов в течение месяца» или «уменьшить количество ручных проверок без роста ошибок».

📌 Какое действие будет выполняться после предсказания? Модель сама по себе не создаёт ценность. Ценность появляется, когда её предсказание меняет процесс: клиент получает предложение, заявка уходит на ручную проверку, товар попадает в рекомендацию, менеджер получает приоритетный список.

📌 Какая метрика будет основной? Важно заранее понять, что оптимизируем: recall, precision, F1, ROC-AUC, прибыль, снижение времени обработки, уменьшение числа ошибок или другую бизнес-метрику. Без этого команда может улучшать технический показатель, который не помогает реальному процессу.

📌 Какие ограничения есть у процесса? Например, служба контроля может обработать только 500 алертов в день, менеджеры могут позвонить только 1000 клиентам в неделю, а ложная блокировка операции стоит компании репутации. Эти ограничения напрямую влияют на выбор порога и оценку качества.

📌 Что будет считаться достаточным результатом? Не всегда нужна идеальная модель. Иногда достаточно решения, которое на 20% сокращает ручную работу. Иногда нужна очень высокая точность, потому что ошибка дорогая. Это нужно обсуждать до экспериментов, а не после презентации метрик.

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

Главный вывод простой: ML-задача должна иметь acceptance criteria так же, как обычная продуктовая задача. Команда заранее должна понимать, что именно изменится после запуска, как это будет измеряться, какие ограничения есть у процесса и какой результат считается достаточным. Иначе можно построить хорошую модель, но так и не получить хорошее решение.

Как понять, что задачу вообще стоит решать с помощью ML 🧠

Когда в компании появляется идея использовать машинное обучение, очень легко сразу перейти к обсуждению моделей. Какой алгоритм взять, какие признаки добавить, какую метрику оптимизировать, где хранить эмбеддинги, нужен ли CatBoost, нейросеть или LLM. Но сильная ML-задача начинается не с модели. Она начинается с проверки, есть ли здесь вообще повторяемая проблема, данные, бизнес-действие и понятный способ измерить результат.

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

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

📌 Есть ли данные о прошлом? Чтобы предсказывать отток, нужно понимать, кто ушёл раньше, какие признаки были известны до ухода, какие действия компания предпринимала и что произошло после. Если данные неполные, размечены задним числом или содержат утечки, модель может показать хорошую метрику в эксперименте, но плохо работать в реальности.

📌 Что изменится после предсказания? Это один из самых важных вопросов. Если модель нашла клиента с высоким риском оттока, что произойдёт дальше: звонок менеджера, скидка, персональное письмо, изменение тарифа, передача в отдельный сегмент. Если на предсказание не завязано действие, оно не создаёт ценности.

📌 Можно ли измерить эффект? Недостаточно сказать, что модель должна быть точной. Нужно заранее понять, какая бизнес-метрика должна измениться: отток, выручка, конверсия, время обработки, количество ручных проверок, стоимость ошибки. Иначе команда будет спорить о ROC-AUC, хотя бизнесу важно совсем другое.

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

Хороший признак, что ML здесь действительно уместен: у команды есть повторяемая задача, достаточно данных, понятное действие после предсказания, измеримая бизнес-метрика и понимание стоимости ошибок. Если хотя бы одного элемента нет, это не значит, что модель точно не нужна. Но это значит, что сначала нужно доработать постановку задачи.

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

Вопрос с ML-собеса: когда accuracy вообще бесполезна 😭

Есть классический вопрос, который выглядит максимально школьно, но на собесах всё ещё отлично показывает, человек понимает метрики или просто где-то видел model.score(X_test, y_test). Вопрос примерно такой: у нас есть модель для поиска мошеннических операций, accuracy 99%, хорошая модель или нет?

И вот тут начинается веселье, потому что очень хочется сказать: 99%, ну нормально же, почти идеально. Только потом оказывается, что мошеннических операций в данных 1%, а обычных 99%. И модель, которая всегда говорит «операция нормальная», тоже получит accuracy 99%. Вообще ничего не нашла, бизнесу не помогла, мошенников пропустила, зато метрика красивая, можно в презентацию вставлять и идти пить кофе 🤡

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

Нормальный ответ на собесе я бы строил так. Сначала нужно посмотреть на распределение классов, потом отдельно оценить precision и recall для важного класса, потом понять бизнес-стоимость ошибок. Если нам важно поймать как можно больше мошенничества, мы будем смотреть в сторону recall. Если нам важно не завалить службу контроля ложными срабатываниями, будет важен precision. А дальше всё равно придётся выбирать порог, потому что модель обычно выдаёт вероятность, а не готовое божественное решение с небес. 😔

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

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

Если коротко: метрика не бывает хорошей сама по себе. Она хорошая только тогда, когда соответствует задаче, данным и цене ошибок. И если модель с accuracy 99% ничего не ловит, то это не сильная модель, а очень уверенный генератор самообмана. 😜

Почему ML-метрика сама по себе почти ничего не говорит бизнесу 📊

Когда начинаешь изучать машинное обучение, кажется, что качество модели можно описать одной красивой цифрой. Accuracy 0.92, ROC-AUC 0.87, F1-score 0.74, и вроде бы сразу понятно, хорошая модель или плохая. Но в реальных проектах эта логика быстро ломается, потому что бизнесу нужна не сама метрика, а изменение в процессе: меньше ручной работы, больше выручки, ниже отток или выше конверсия.

Например, команда строит модель, которая должна предсказывать клиентов с высоким риском оттока. После обучения модель показывает ROC-AUC 0.86. На первый взгляд результат хороший, метрика высокая, графики красивые, эксперимент можно считать успешным. Но дальше появляется главный вопрос: что именно бизнес будет делать с этим предсказанием? Если ответа нет, модель остаётся техническим артефактом, а не инструментом принятия решений.

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

📌 Сколько клиентов попадёт в список риска?

📌 Кто будет с ними работать: менеджер, CRM-система или автоматическая рассылка?

📌 Какое действие будет выполнено: звонок, скидка или персональное предложение?

📌 Сколько стоит это действие для компании?

📌 Как мы поймём, что клиент остался именно из-за этого действия?

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

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

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

Поэтому перед запуском ML-модели важно описать не только качество алгоритма, но и процесс, в который он будет встроен. Для этого полезно ответить на несколько вопросов:

📌 Какое решение будет приниматься на основе предсказания?

📌 Кто будет принимать это решение?

📌 Что изменится в текущем бизнес-процессе после появления модели?

📌 Какая метрика должна измениться, если модель действительно полезна?

📌 Как мы отделим эффект модели от других факторов?

📌 Что произойдёт, если модель ошибётся?

📌 Сколько стоят разные типы ошибок?

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

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

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

Я выпустил 18 курсов. Stepik не показал ни один. 📉

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

С 1 июня я выпустил 18 новых курсов:
- 12 задачников по SQL
- 2 задачника по ML
- 4 практических воркшопа по машинному обучению

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

Такой подход научил меня не суетиться. Выпустил курс - оставил его в покое на 2–4 недели. Потом вернулся и посмотрел на результаты. Ровно так я поступил и в этот раз. Поэтому можете представить моё удивление, когда спустя полтора месяца я увидел:

0 продаж. 🌝

Но гораздо сильнее меня удивило другое:

0 посещений страниц курсов. 😒

Это уже было совсем странно. Обычно Stepik хотя бы немного показывает новый курс пользователям. Даже у слабого запуска появляются 20–30 посещений промостраницы.

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

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

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

В результате мы договорились, что Stepik возьмёт в продвижение один выбранный мной курс. Остальные смогут постепенно возвращаться в рекомендации после того, как я поработаю над их «глубиной». Что именно платформа понимает под глубиной, мне пока не до конца ясно. Критерии выглядят довольно туманными. Но ситуация всё равно стала лучше. До обращения поддержка была готова продвигать ноль курсов. Теперь готова продвигать один, а для остальных хотя бы появился путь обратно.

Главных вывод для меня здесь 2 (и они не про Stepik):
- Cоздать продукт недостаточно. Нужна ещё дистрибуция. Можно написать хороший курс, сделать сильную программу и решить реальную проблему пользователя. Но если между вами и аудиторией стоит платформа, которая решила вас не показывать, результат всё равно будет равен нулю.
- Всегда нужно фокусироваться на цели. Я очень хотел поспорить с ними, оскорбить их, написать пост о том какие они мудаки и т.д., но цель - дать качественные образовательные продукты всем желающим и увеличить выручку образовательно бизнеса. Поэтому в таким моменты важно отбросить эмоции и делать шаги только в сторону цели, а не своего Эго.

Кажется, главный урок здесь вообще не про Stepik. Если между вами и клиентом стоит чужая платформа, то часть вашего бизнеса принадлежит этой платформе. Именно поэтому теперь я хочу строить не только образовательные продукты. Я хочу строить собственную аудиторию. 🗻☕️

Почему я начал заниматься образованием 🧠

В детстве у меня было четыре карьерных мечты.
- Стать преподавателем. 👨‍🏫
- Стать инженером. 🚶‍➡️
- Стать бизнесменом. 💰
- И стать волшебником. 🧙‍♂️

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

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

Эта идея настолько засела у меня в голове, что ещё в школе я начал заниматься репетиторством. И именно тогда появилась вещь, которая раздражает меня до сих пор. Очень часто людей учат запоминать вместо того, чтобы понимать. Выучить определение, выучить формулу, выучить алгоритм. Но так и не разобраться, почему всё это вообще работает. (даже пока пишу, бесит)

Мне всегда казалось, что это какой-то странный способ обучения. Ведь когда человек действительно понимает идею, ему уже не нужно заучивать половину материала - многое становится логичным само собой. Именно поэтому сегодня я так много времени трачу на свои курсы. Мне нравится искать объяснения, после которых человек говорит: «Подожди… так это же совсем не сложно!» ☕️

Для меня смысл образования заключается именно в этом. Не показать что-то сложное, а сделать сложное понятным.

Почему некоторые Senior не являются Senior 🗻

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

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

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

Для меня Senior это самостоятельная боевая единица. ⚙️

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

Если Senior взял задачу, он владеет ей. Он не просто исполняет требования. Он отвечает за то, чтобы задача действительно привела к результату. И это очень важное отличие.

Исполнитель смотрит на задачу и думает: Как это сделать?
Senior смотрит на задачу и думает: Что здесь может пойти не так? Какую проблему мы на самом деле решаем? Какие есть риски? Какой вариант будет самым устойчивым? Что сломается через месяц, если мы сейчас примем плохое решение?

Мне кажется, настоящий Senior уже смирился с тем, что в работе почти никогда не бывает идеальных решений. Всегда есть сроки, всегда есть ограничения, всегда есть технический долг, всегда есть бизнес-интересы, всегда есть пользователи, всегда есть команда, которой потом жить с этим решением. Но когда сотрудник надевает свой Senior-мундир он должен стать непоколебимой Фемидой, которая готова спокойно балансировать между рисками. Не потому что ему всё равно. А потому что он уже понимает цену каждого решения.

Senior отличается не тем, что всегда выбирает самый красивый вариант. Он отличается тем, что понимает, чем придётся заплатить за каждый вариант.💰

И ещё одна вещь, о которой редко говорят. У Senior всегда есть своё видение доменной области. Не только конкретной задачи. Не только своего куска кода. А всей области, за которую он отвечает. Он понимает, куда система должна развиваться. Какие решения сейчас мешают двигаться быстрее. Где команда постоянно теряет время. Какие проблемы повторяются из квартала в квартал. Какие вещи нужно упростить, а какие наоборот пора сделать серьёзнее.

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

Но на самом деле за этим стоит внутренняя карта местности. Человек понимает не только, где он находится сейчас, но и куда должна двигаться вся система. И именно поэтому некоторые Senior на самом деле не являются Senior. Потому что они выросли по зарплате, но не выросли по уровню ответственности. Они умеют решать сложные задачи, но не владеют ими. Они ждут требований, но не формируют позицию. Они хорошо исполняют, но не думают о системе. Они могут быть сильными специалистами. Очень полезными. Очень опытными. Очень дорогими на рынке. Но Senior для меня это не просто опытный исполнитель. Senior это человек, которому можно отдать проблему и быть уверенным, что он не просто принесёт решение.💻

Самые дорогие стратегические ошибки в карьере. Часть 3.

Не высказывать своё мнение. 💬

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

Чем меньше вопросов - тем лучше.

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

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

Поэтому сейчас меня всегда настораживает ситуация, когда на встрече руководитель спрашивает “Есть ли у кого-нибудь замечания?” И в ответ наступает тишина.

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

Важно понимать, что высказывать своё мнение - не значит спорить ради спора!!!🌪️

Фраза “Я не согласен.” Практически бесполезна. А вот фраза “Мне кажется, здесь есть риск, потому что…” или “Я бы предложил другой вариант, потому что…” - это уже профессиональная позиция.

За несколько лет работы я заметил интересную вещь. Руководители гораздо лучше запоминают людей, которые способны аргументированно защищать свою точку зрения, чем тех, кто всегда соглашается. Даже если в итоге решение останется прежним. Потому что мнение - это вклад в качество решения. Молчание - нет.📊

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

В какой-то момент вас начинают ценить не только за то, что вы умеете делать, но и за то, как вы помогаете принимать правильные решения. И именно тогда происходит переход от исполнителя к настоящему инженеру. 🧑‍💻

Самые дорогие стратегические ошибки в карьере. Часть 2. 💻

Думать, что достаточно просто хорошо делать свою работу. 😸

Когда я только начинал работать, мне казалось, что карьерный рост - это очень простая формула. Много впахиваешь → тебя замечают → повышают. Очень оптимистичная система.

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

Они практически не общались с коллегами. 😒

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

Потому что карьеру строят не только результаты. Карьеру строит доверие. 🗻

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

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

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

Надеяться, что результаты сами всё расскажут за вас. ☕️