Лев говорит

Как говорить о зарплате на собеседовании 💰

Разговор о деньгах часто нервирует сильнее технического интервью. Страшно назвать слишком много, продешевить или услышать вопрос «а сколько вы получаете сейчас?». Поэтому лучше подготовить ответы до звонка с HR, а не придумывать цифры на ходу.

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

HR: «Какие у вас зарплатные ожидания?»

Если пока мало информации о роли, не спешите первым называть точную сумму:

> «Мне важно сначала понять задачи и уровень ответственности. Подскажите, пожалуйста, какой диапазон предусмотрен для этой позиции?»

Если диапазон известен и совпадает с ожиданиями:

> «По описанию роли и моему опыту я ориентируюсь на диапазон X–Y до вычета налогов. Готов обсуждать точнее, когда пойму полный состав задач и компенсации».

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

HR: «Сколько вы получаете сейчас?»

Вы не обязаны строить переговоры вокруг своей текущей зарплаты. Можно вернуть разговор к новой роли:

> «Я бы хотел ориентироваться на ответственность и диапазон этой позиции. Для следующего шага рассматриваю X–Y».

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

HR: «Мы готовы сделать оффер на X».

Если сумма ниже желаемой, не нужно сразу отказываться или соглашаться:

> «Спасибо, роль мне интересна. Я рассчитывал на X. Можно ли приблизиться к этой сумме? Мой ориентир связан с задачами A и B и опытом, который я принесу».

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

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

Как Middle стать Middle+ ⚙️

«Я самостоятельно закрываю задачи. Почему этого всё ещё недостаточно для следующего грейда?»

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

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

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

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

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

Я бы проверял готовность к Middle+ такими вопросами:

📌 За какой домен или часть продукта вы отвечаете не только в рамках одной задачи?

📌 Какие повторяющиеся проблемы вы устранили, а не просто чинили по одной?

📌 Как вы сделали решение понятным и поддерживаемым для остальных?

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

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

Следующий переход, Middle+ → Senior, будет уже про ответственность за результат в условиях, когда проблема и путь к решению заранее не определены. 🚀

Pet-проект глазами интервьюера 🧠

В GitHub открывается ещё один Titanic или House Prices. Ноутбук запускается, в конце стоит метрика. Что я понял о кандидате? Пока почти ничего.

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

Слабый проект обычно отвечает только на вопрос «какую библиотеку я использовал?». Сильный помогает поговорить о другом:

📌 Проблема: какую задачу вы решили и для кого?

📌 Решение: почему выбрали этот подход, а не альтернативу?

📌 Проверка: с чем сравнивали и почему выбрали эту метрику?

📌 Ограничения: где модель ошибается и что вы не успели проверить?

📌 Инженерия: как проект запустить, откуда берутся данные, что происходит при сбое?

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

README, то есть описание проекта, тоже часть работы. За пару минут я хочу понять что вы сделали сами, как проверили результат и чему научились. Честно описанные ограничения производят лучшее впечатление, чем громкое «модель предсказывает будущее» без проверки.

Проверьте свой проект: сможете ли вы за две минуты объяснить задачу, личный вклад, выбор метрики, главный компромисс и следующий шаг? Если да, он уже даёт материал для хорошего разговора на собеседовании. Pet-проект не заменяет опыт, но помогает показать мышление и подтвердить заявленные навыки. 🚀

Как Junior+ стать Middle 🚀

«Я уже два года работаю, сам закрываю задачи. Почему мне всё ещё не дают Middle?» Часто потому, что следующий грейд не выдают за срок и ещё один курс. Он появляется, когда меняется то, какую часть проблемы вы способны взять на себя.

Для меня разница звучит так: Junior+ получает задачу. Middle получает проблему. Не в смысле, что Junior+ просто ждёт инструкций. Он может самостоятельно вести небольшой понятный кусок работы. Middle же способен разобраться в ситуации, где готового решения и подробного плана нет.

Представим, что команда жалуется: модель стала хуже находить клиентов, которые скоро уйдут. Junior+ может взять задачу проверить качество новых данных, найти ошибку в признаке и поправить расчёт. Это полезная работа. Middle начинает с другого: уточняет, что именно значит «стала хуже», для какого сегмента и периода, как это измерили, что изменилось в продукте и какие решения бизнес принимает на прогнозе.

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

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

Это не означает, что Middle должен делать всё один или не просить помощи. Он умеет понять, где нужен эксперт, какие данные или доступы нужны и когда пора поднять риск. Разница в том, что он не ждёт, пока кто-то другой превратит проблему в подробный список действий. 🧠

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

Коротко: Junior+ самостоятельно ведёт кусок задачи. Middle самостоятельно разбирается, какую проблему нужно решить, и отвечает за результат.

Дальше разберём Middle → Middle+. Там фокус смещается ещё раз, от решения отдельной проблемы к ответственности за часть проекта или направления. 🗻

Один вопрос, три уровня: Junior, Middle и Senior 🎯

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

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

Ответ Junior: «Я заметил ошибку в данных, нашёл причину, исправил обработку пропусков и проверил, что модель снова выдаёт ожидаемый результат».

Это хороший ответ для Junior. Кандидат умеет локализовать проблему, исправить свой участок и проверить результат. Он не обязан в одиночку перестраивать всю систему.

Ответ Middle: «Я исправил обработку пропусков, добавил проверку входных данных и тест, который ловит такой формат до запуска модели. Ещё проверил соседние источники, чтобы убедиться, что проблема не повторится там».

Здесь видно больше автономности: Middle не только тушит текущий пожар, но и снижает вероятность его повторения. Он смотрит за пределы одной строки кода, на свой компонент и его надёжность.

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

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

Это не значит, что Senior обязательно должен произнести больше терминов. Разница в масштабе ответственности: Junior устраняет локальную ошибку, Middle предотвращает её повторение в своём компоненте, Senior снижает риск для бизнеса и меняет систему так, чтобы проблема обнаруживалась и решалась надёжно.

Почему я не пользуюсь hh.ru. 💼

Я ни разу не находил работу через hh.ru.

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

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

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

Поэтому сотни безответных откликов на hh.ru не обязательно означают, что рынок мёртв. Скорее всего, вы используете один канал, где конкурируете с сотнями других резюме. Это нормальный канал, но плохая единственная стратегия.

Я бы строил поиск так:

📌 Отклики: смотреть вакансии и отправлять резюме точечно, под конкретную роль.

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

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

📌 Видимость: вести GitHub, писать заметки, показывать проекты, выступать, помогать с разбором задач. Человека легче порекомендовать, когда понятно, что он умеет.

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

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

Как найти стажировку в ML/DS без опыта. 🎓

«Во всех вакансиях нужен опыт. Где мне его взять, если меня никуда не берут?»

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

Я бы собирал первые отклики в такой последовательности. 👇

1. Сделайте один сильный инженерный проект. 🧠

Не десять ноутбуков с Titanic, а одну работу, которую не стыдно открыть с интервьюером. Например, выберите научную статью по ML или анализу данных, воспроизведите идею на Python и положите в GitHub. В README, то есть описании проекта, напишите: какую задачу решает подход, что реализовали, на каких данных проверили, что получилось и какие есть ограничения. Это показывает глубину лучше строки Python, pandas, sklearn.

2. Добавьте проект, похожий на продакшен. ⚙️

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

3. Соберите бизнесовый контекст. 📊

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

4. Покажите общую активность. 🚀

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

Есть грубая, но полезная формула: network is your net worth, то есть сеть профессиональных связей формирует вашу ценность на рынке. Речь не о просьбах устроить вас на работу. Социальный капитал, то есть сеть доверия и взаимных профессиональных связей, строится иначе: вы общаетесь, показываете проекты, просите конкретную обратную связь, помогаете другим и не пропадаете после одного разговора. Не игнорируйте других новичков, через несколько лет они тоже смогут вас рекомендовать. 🤝

5. Только теперь оформляйте резюме и начинайте откликаться. 💼

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

📌 Чек-лист перед первыми откликами:

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

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

Как найти стажировку в ML/DS без опыта. 🎓

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

Я бы строил резюме вокруг двух линий. Первая, инженерная глубина. Не список Python, pandas, sklearn, а один-два сильных проекта. Например, возьмите научную статью по ML или анализу данных, воспроизведите идею на Python и оформите её в GitHub. В README покажите: какую задачу решает статья, что вы реализовали, на каких данных проверили, что получилось и какие есть ограничения. Это показывает, что вы умеете читать сложный материал, превращать его в код и проверять результат. 🧠

Вторая линия, умение довести ML-идею до работающего сервиса. Вместо очередного Titanic можно собрать небольшой проект с данными, моделью и дашбордом. Например, сервис, который обновляет рыночные данные и показывает краткосрочный прогноз. Интервьюер должен открыть ссылку и увидеть, что всё работает, а вы должны суметь объяснить архитектуру, метрику и ограничения модели. Это не торговая стратегия и не способ заработать на криптовалюте, а демонстрация production-мышления. Хостинг может стоить несколько тысяч рублей в месяц, поэтому сначала посчитайте бюджет. ⚙️

Бизнесовый контекст можно получить и без компании: через side hustle, хакатон, студенческий продукт или проект для знакомого бизнеса. Важно, чтобы вы общались с пользователями, формулировали проблему, выбирали метрику и меняли решение после обратной связи. В резюме лучше написать не «сделал модель», а «собрал требования у пяти пользователей, автоматизировал обработку заявок, проверил эффект по метрике». 📊

Ищите стажировки не только на сайтах вакансий. У меня большинство работ и проектов приходили через знакомства: рекомендации, реферальные программы, карьерные чаты, мероприятия, однокурсников, людей из pet-проектов. Иногда команда уже ищет человека, но вакансия ещё не появилась публично. Нетворкинг, это не просьба “возьмите меня на работу”. Это нормальное общение, обратная связь по проектам, помощь другим и репутация человека, с которым приятно работать. Не игнорируйте других новичков, со временем они тоже станут коллегами и рекомендателями. 🤝

Не рассылайте одно CV всем подряд. Посмотрите на задачу команды, выберите релевантный проект и коротко напишите: почему вам интересна роль, чем ваш опыт похож и где посмотреть код или демо. Даже отказ не всегда финальный. Резюме остаётся во внутренней базе, и при новом найме рекрутер или руководитель может вернуться к старому отклику. У меня так происходило около десяти раз: откликался давно, а написать с предложением обсудить работу могли уже спустя время. 📬

Первая ML/DS-стажировка начинается не с фразы «у меня нет опыта», а с фразы: вот видимая работа, по которой можно проверить, как я думаю, что умею делать и какую пользу могу принести. 🗻

Вопрос с ML-собеса для Junior DS/ML 😭

Что делать, если классы сильно несбалансированы?

Это один из тех вопросов, который выглядит довольно простым, пока человек не начинает отвечать. Потому что очень хочется сразу сказать что-то умное про oversampling, undersampling, SMOTE или веса классов. Только на собесе я почти всегда смотрю не на то, сколько терминов человек вспомнил, а на то, понимает ли он, зачем вообще нужен каждый из этих приёмов и какую проблему он решает.

Слабый ответ обычно звучит так: «Ну, надо просто сделать oversampling или SMOTE, и всё станет нормально». Формально это похоже на правду, но по факту это очень слабый ответ. Потому что тут не видно ни понимания задачи, ни понимания метрики, ни понимания цены ошибок. Это как сказать «ну, модель надо улучшить», и считать, что на этом собес закончился.

Хороший ответ я бы строил иначе. Сначала я бы посмотрел, насколько сильный дисбаланс, какой именно класс важен, и какие ошибки для бизнеса дороже. Если важный класс встречается редко, accuracy почти сразу становится подозрительной метрикой. Дальше я бы выбрал метрики, которые лучше показывают качество по важному классу, например precision, recall, F1, иногда PR-AUC, и уже потом думал бы, нужно ли менять порог, использовать веса классов, делать oversampling или undersampling. То есть сначала я бы понял задачу, а уже потом трогал технику.

И вот здесь важная оговорка. Можно вспомнить и более продвинутые техники борьбы с дисбалансом, например class weights, balanced sampling, SMOTE, подбор порога, калибровку вероятностей. Но если вы о них говорите, я почти всегда начну копать глубже. Почему именно эта техника? Какие у неё плюсы и минусы? Что она меняет в данных? Что будет с ложными срабатываниями? Почему вы выбрали её, а не другую? Если на эти вопросы ответа нет, то это скорее не плюс, а попытка притянуть за уши красивое слово.

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

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

Как стажёру стать Junior. 🎓

Главная ошибка стажёра, который хочет получить Junior-оффер, — пытаться доказать, как много он знает.

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

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

1. Стажёр сам добирает контекст.

Junior не обязан знать всё, но он уже умеет не теряться, когда задача неполная. Он сам уточняет недостающее, собирает контекст и приходит не с общим «не понял», а с конкретными вопросами. Это сразу меняет восприятие: человек не висит на каждом шаге, а двигается сам. 🧠

2. Стажёр берёт ownership за кусок работы.

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

3. Стажёр перестаёт приносить только ответ.

«Я сделал» — плохой формат коммуникации для человека, которого только начинают оценивать. Гораздо полезнее звучит так: «Я понял задачу вот так, попробовал A и B, B оказался лучше по такой-то причине, здесь остаётся такой-то риск». Руководителю важно не только увидеть результат, но и понять, можно ли доверять способу, которым ты к нему пришёл. 📌

4. Стажёр учится не теряться после ошибки.

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

5. Стажёр становится предсказуемым по срокам.

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

6. Стажёр понимает, зачем существует задача.

Junior уже может объяснить, кому нужен результат, что произойдёт после завершения задачи и почему это вообще важно. Это пока ещё не уровень самостоятельного влияния на систему, но уже не слепое исполнение. 🧩

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

И важная оговорка: это не универсальная грейдовая система. В разных компаниях Junior может означать очень разный уровень. Я описываю не формальный титул, а тот переход в поведении, после которого лично я начинаю воспринимать стажёра как Junior.

Дальше разберу всю лестницу: Intern → Junior → Junior+ → Middle → Middle+ → Senior → Senior+ → Lead.

Именно поэтому я бы сказал так: Junior, это не тот, кто всё знает. Junior, это тот, кому уже можно доверить кусок работы без постоянного контроля. 🗻

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

Идти в БигТех на старте карьеры ради красивой строчки в резюме. 🧑‍💻

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

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

С другой стороны есть стартапы. Приходя в стартап на любую позицию, твоя роль размывается. Ты становишься и инженером, и лидом, и бизнес-аналитиком, который общается с заказчиками, и девопсом, и дизайнером. При этом тебе ещё и платят меньше. В чём смысл? Смысл - в плотности опыта. За год в стартапе ML-инженер выводит четыре-пять моделей в прод. Сам, без команд интеграции, без ML Ops. Он видит заказчика, договаривается о метриках, тестирует, запускает, обрабатывает ошибки, объясняет коллегам, как работать с моделью. Год в стартапе равен двум годам в БигТехе на хорошей позиции. Иногда трём. 🚀

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

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

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

Опыт, полученный в стартапе в первые два-три года, открывает путь к сильным позициям в крупных компаниях. Обратная траектория работает гораздо хуже. Выйти из БигТеха после трёх лет на роли джуниор-исполнителя и начать самостоятельно вести сложные задачи намного сложнее.

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

Как градиентный бустинг учится на ошибках, без формул на доске 🧠

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

🏠 Представим задачу прогноза цены квартиры. У нас есть площадь, район, этаж, год постройки и реальная цена каждой квартиры. Первое дерево обычно очень простое. Например, оно замечает, что квартиры больше 60 квадратных метров в среднем стоят дороже, и выдаёт грубые прогнозы. Для одной квартиры оно предсказало 10 миллионов, хотя настоящая цена была 12 миллионов. Для другой предсказало 8 миллионов вместо 7 миллионов. После первого дерева у нас появляется не только прогноз, но и понимание, где и насколько текущая модель ошибается.

📌 Что становится таргетом второго дерева? Не исходная цена квартиры и не прогноз первого дерева. В простой регрессионной задаче с квадратичной ошибкой это остаток:


таргет второго дерева = факт − прогноз первого дерева


Для квартиры стоимостью 12 млн первое дерево предсказало 10 млн. Значит, таргет второго дерева будет +2 млн. Для квартиры стоимостью 7 млн был прогноз 8 млн, значит таргет будет −1 млн. В этом конкретном случае остаток и есть антиградиент функции потерь. Там, где первое дерево занизило цену, новое дерево учится добавлять значение. Там, где завысило, уменьшать. Каждое новое дерево отвечает не на вопрос «сколько стоит квартира?», а на вопрос «какую поправку нужно добавить к уже сделанному прогнозу?» ⚙️

➕ Как деревья собираются в один прогноз? Их предсказания не конкурируют друг с другом, а складываются в композицию. Если первое дерево для квартиры предсказало 10 млн, а второе выучило поправку +1,5 млн, итоговый прогноз после двух деревьев будет 11,5 млн. Если третье дерево добавит ещё +0,3 млн, итог станет 11,8 млн:


итоговый прогноз = прогноз 1-го дерева + поправка 2-го дерева + поправка 3-го дерева + ...

10 млн + 1,5 млн + 0,3 млн = 11,8 млн


На практике к каждой поправке ещё применяется скорость обучения. Например, при learning_rate = 0.1 вклад второго дерева +1,5 млн добавится не целиком, а как +0,15 млн. Так модель учится осторожнее и меньше рискует слишком точно запомнить обучающие данные. 🛡️

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

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

Когда новая ответственность становится ростом, а когда это просто бесплатное повышение 💰

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

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

📌 За какой конкретный результат я отвечаю? Не «улучшить процесс», а сократить время запуска моделей, снизить число инцидентов или вывести новую часть продукта к определённой дате.

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

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

📌 Как мы измерим, что я справился? Иначе через полгода легко услышать: «Ты молодец, но для повышения нужно ещё немного доказать». Критерии должны появиться до того, как вы возьмёте на себя риск.

📌 Когда и как изменятся условия? Иногда повышение возможно только в следующий цикл, и это не катастрофа, если есть дата, критерии и договорённость, кто поднимает вопрос. Формулировка «поработай, там посмотрим» не является карьерным планом.

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

Сильная позиция может звучать так:

> «Мне интересна эта зона. Давайте зафиксируем, за что я отвечаю, какие у меня будут полномочия и что изменится в моей роли, если я показываю результат в ближайшие три месяца».

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

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

Если не растёт ничего, кроме списка задач, это не повышение. Это бесплатная дополнительная работа.