Как в бигтехах становятся миддлами

Как в бигтехах становятся миддлами Попросил нашего выпускника-старичка написать свои мысли о том, как МЛ стажеру в Яндексе попасть в штат. Дальше текст выпускника с легкими изменениями. Кстати, 4 октября дедлайн подачи на intern week offer по МЛ , разбор заданий уже выложен на наших курсах МЛ ПРО, ИИ агенты ПРО . Не упусти возможность за неделю попасть в Яндекс. ➡ Записаться За свою карьеру (5 лет) я побывал на всех возможных ступенях развития ML-инженера: от стажера до сеньора. В начале пути я еще не понимал, каким назойливым, вечно задающим одни и те же вопросы студентом я был. Сейчас мне 24, и, поменторив уже с десяток джунов, я могу с уверенностью заявить: рост программиста зависит исключительно от того, как он ставит себя перед руководством и относится к задачам. Именно о том, как это сделать, я и хочу рассказать. Для большинства людей, погружающихся в IT, миддл — это человек, который деплоит модели, сам общается с бизнесом и выступает на митапах от лица команды. На деле всё прозаичнее. Грейд в первую очередь дает вам возможность самим влиять на свою работу: ставить задачи, работать с продовыми ресурсами и, самое главное, нести за это ответственность. Поэтому первое, чему должен научиться джун, желающий стать миддлом, — нести ответственность за свои действия. Первый совет Расскажу про свой первый серьезный косяк. Второй месяц работы, мне дали задачу: переобучить модель классификации обращений на свежих данных и выкатить. Я сделал всё по инструкции из вики, метрики на валидации даже подросли, выкатил и с чистой совестью пошел домой. Через два дня приходит продакт: половина обращений улетает не в ту очередь, саппорт зашивается. Оказалось, в новых данных поменялась разметка одной категории, и никто об этом не написал. Первый порыв был сказать: я сделал как в инструкции, данные мне дали такие, я не виноват. И формально это было правдой. Но я поймал себя на мысли, что, будь модель моей, а не «выданной по задаче», я бы сейчас не оправдывался, а чинил. Так что в тот же день я сам откатил модель, написал в трекер, что сломалось и почему не поймали на валидации, добавил в пайплайн проверку на распределение классов и пошел договариваться с командой разметки, чтобы про такие изменения предупреждали заранее. Меня, конечно, всё равно поругали. Но именно после этого случая мне начали давать задачи без присмотра. Лид увидел, что после ошибки я не жду, пока за меня разгребут. Второй совет Теперь касательно навыков. Когда я в первый раз просил руководство о повышении, мне прямо сказали: ты еще даже вуз не окончил, какое тебе повышение. Я стал спорить, доказывая, что мои навыки достойны миддла, и спустя две недели тимлид сказал: вот тебе задачка, сделаешь за неделю — дадим повышение. Чтобы вы понимали: с такой задачей я еще не сталкивался, там было много непонятных слов, а в согласующих стояли три неизвестных мне человека. Два дня ушло на декомпозицию, еще два на общение с людьми, а потом мне пришлось ночами копаться в документации Triton и CUDA, чтобы разобраться, как деплоить. В итоге спустя почти двое суток без сна мне удалось задеплоить модель. В процессе я освоил около пяти фреймворков и сервисов, о существовании которых раньше даже не знал, но задачу сделал, и руководитель признал, что меня можно повысить. Так что второе наставление — постоянно осваивать релевантные технические навыки и, главное, показывать их руководству. Третий совет Ну и третий совет — обрастайте связями. Работа в IT лишь на 50% состоит из написания кода. Остальное — общение с людьми из смежных команд и изучение смежных направлений. Возможно, в компании уже есть команда, которая вам по душе и где открыта вакансия на миддла, но вы просто об этом не знаете. Опять пример. Была у меня стажерка, назовем ее Лена. Пришла в команду CV, а хотела в NLP: тогда как раз все носились с LLM, и ей было обидно размечать дефекты на фотках. Она могла сидеть и ждать, пока ее заметят, но сделала иначе — стала ходить на все внутренние демо и митапы, даже те, что вообще не про ее команд