яндекс стажировка машинное обучение

Как проходят секции по машинному обучению на собеседованиях в Яндекс

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

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

1. Собеседования по машинному обучению в Яндексе

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

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

Как правило, наши лучшие сотрудники обладают ещё и экспертными знаниями в специфических областях — например, компьютерном зрении, построении языковых моделей или моделей для рекомендательных или поисковых сервисов.

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

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

В зависимости от требований подразделения также может потребоваться алгоритмическая секция с написанием кода или даже архитектурная секция.

2. Постановка задачи

Итак, основной задачей секции является проверка, насколько кандидат способен самостоятельно разобраться с задачей во всём её объёме, начиная от её постановки и заканчивая вопросами приёмки в пользовательских экспериментах.

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

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

Исходя из причин возникновения задачи формулируются бизнес-метрики, а затем и метрики, подходящие для оптимизации в процессе обучения или выбора моделей. Показатель чрезвычайно высокого класса кандидата — если выбор метрик для оптимизации продиктован физическим смыслом решаемой задачи. Простейший пример такого рода — использование DCG-like метрик для задач ранжирования или AUC-like метрик для некоторых специфичных задач классификации.

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

3. Методы машинного обучения

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

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

Следующий обязательный для обсуждения пункт — пространство признаков. Классный специалист способен сходу придумать несколько десятков или даже сотен признаков в новой задаче, предварительно разбив их на несколько классов сообразно используемым видам данных (например, признаки могут зависеть только от пользователя, а могут – от пары «пользователь — объект»).

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

4. Контроль качества

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

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

5. Как преуспеть на секции

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

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

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

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

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

Источник

Стажировка в IT: взгляд руководителя

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

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

Собеседование перед стажировкой

_Игнат:

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

_Денис:

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

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

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

_Денис:

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

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

_Денис:

Те, кто приходит на собеседование, в основном знают языки: у нас в Екатеринбурге хорошая школа основных языков, хорошие институты. Но если честно, кандидат на стажировку с хорошими hard skills — редкий случай, по крайней мере в нашей эпсилон-окрестности. Вот к примеру, Swift. В нём очень сложная работа со строками, и людей, которые навскидку из головы могут с ними поработать, мало. За таких сразу цепляется глаз. Я часто даю на собеседованиях задачу, которая как раз связана с обработкой строк. И за всё время был только один человек, который сходу, на листочке, смог такой Swift-код написать. Я после этого ходил и всем рассказывал, что кто-то наконец смог решить эту задачу на Swift на листочке.

Проверка алгоритмов на собеседовании

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

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

_Денис:

Большая часть мобильной разработки — это «перекладывание JSON». Но раз в полгода бывают случаи, когда алгоритмы нужны. Я сейчас рисую красивые карты для Яндекс.Погоды. И мне за неделю пришлось реализовать алгоритм сглаживания, алгоритм Сазерленда-Ходгмана и алгоритм Мартинеса. Если бы человек не знал, что такое хэшмап или очередь по приоритетам, он бы засел с этим надолго и непонятно, справился бы или нет без посторонней помощи.

Алгоритмы — основа разработки. Это то, что помогает разработчику быть разработчиком. Неважно, чем вы занимаетесь. Они нужны и в несложных проектах, где основная работа состоит из «перекладывания JSON». Даже если вы не пишете сами алгоритмы, но неявно используете какие-нибудь структуры данных, то лучше их понимать. Иначе у вас будут получаться приложения, которые медленно или некорректно работают.

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

А есть самоучки, к которым я причисляю и себя. Да, формально у меня есть IT-образование, диплом инженера-программиста. Но самоучки программировать научились «вопреки». У них не было университетской программы. Обычно они с алгоритмами не знакомы — потому что никогда не сталкивались с необходимостью их изучить. И когда такой человек понимает алгоритмы, это значит, что он потратил время и в них разобрался. Закончив универ, я понял, что у меня есть белые пятна в части фундаментальных алгоритмов — дело в том, что специальность была прикладная. Я пошёл и изучил онлайн-курсы Принстонского университета, хорошо известного Роберта Седжвика. Разобрался, сделал все домашки. И когда человек на собеседовании рассказывает похожую историю, мне сразу становится интересно, появляется желание с ним поработать или хотя бы продолжить разговор.

_Игнат:

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

Какие задачи решает стажёр

_Игнат:

Это крайне полезные задачи. Возможно, они не увеличат утилизацию кластера на 10%, не сэкономят миллион долларов компании, но сделают счастливыми сотни людей. Например, у нас сейчас есть стажёр, который занимается нашим клиентом для запуска операций на наших кластерах. Перед запуском операция должна загрузить некие данные на кластер. Обычно это занимает 20–40 секунд, и раньше это происходило молча: запустил её в консоли и сидишь, смотришь в чёрный экран. Стажёр пришёл и за две недели сделал фичу: теперь видно, как файлы заливаются и что происходит. Задача, с одной стороны, несложная в описании, а с другой — есть в чём покопаться, какие библиотеки посмотреть. Самое приятное — что ты это сделал, прошла неделя, это оказалось на кластерах, люди уже этим пользуются. Пишешь пост во внутреннюю сеть — тебе говорят спасибо.

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

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

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

Менторство над стажёром

_Игнат:

Я стараюсь хотя бы через день подходить, спрашивать, как у стажёра дела. Если вижу, что закопался, то стараюсь ему помочь, спросить, в чём проблема, и вместе с ним её раскопать. Ясно, что это отнимает мои силы и делает работу стажёра не столь эффективной интегрально — я же тоже своё время трачу. Зато это позволяет ему ни в чём не закопаться, получить результат. И всё равно это быстрее, чем если бы я это делал сам. Самому мне нужно на задачу условные 5 часов. Стажёр её сделает за 5 дней. И да, я потрачу 2 часа в течение этих 5 дней на то, чтобы пообщаться со стажёром и помочь. Но хотя бы 3 часа я сэкономлю, и стажёру будет приятно, что ему подсказали, помогли. В целом, надо просто плотно общаться, смотреть, что человек делает, не терять контакт.

_{Серёжа:}

Стажёр постоянно находится на связи со своим ментором и общается с ним по несколько раз в день. Ментор ревьюит код, занимается парным программированием со стажёром, помогает, когда возникают какие-то проблемные места. Именно таким способом, сочетанием помощи ментора и реальных боевых задач, мы обучаем фронтендеров.

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

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

_{Серёжа:}

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

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

Окончание стажировки

Перед началом работы мы подписываем с каждым стажёром срочный договор. Разумеется, стажировка оплачивается, оформляется по ТК РФ, и у стажёра появляются те же преимущества, что и у любого другого сотрудника Яндекса. Спустя три месяца программа завершается — многих стажёров мы затем переводим в штат (на бессрочный договор).

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

_{Серёжа:}

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

_Игнат:

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

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

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

Истории о стажёрах

_Денис:

Девушка, которая к нам устроилась на стажировку в 2017 году, была родом из Перми. Это километров 400 от Екатеринбурга на запад. И она каждую неделю приезжала к нам из Перми на поезде в Школу мобильной разработки. Днём приезжала, вечером училась и поздним вечером уезжала обратно. Оценив такое рвение, мы её позвали работать, и это себя оправдало.

_Игнат:

Несколько лет назад мы участвовали в программе обмена стажёрами. Поработать с иностранными ребятами было интересно. Но стажёры оттуда не сильнее, чем, например, из ШАДа или с ФКНа. Казалось бы, EPFL находится в топ-20 вузов Европы. У меня в тот момент — как ещё у не очень опытного собеседующего — было такое ожидание: невероятно, мы собеседуем людей из EPFL, они будут супер-крутые. Но люди, которые получили базовое образование про кодинг у нас — в том числе в ключевых региональных вузах, — оказываются вполне на уровне.

Или другая история. Сейчас у меня в штате парень, молодой совсем, около 20 лет. Работает в Питере, приезжал на стажировку. Он очень крутой. Ты, как обычно, даёшь человеку задачи, он их решает, а через месяц приходит и говорит: я порешал, смотрю, и, кажется, у вас архитектура плохо построена. Давай переделаем. Код станет проще, понятней. Я его, конечно, отговорил: объём работ большой, профита для пользователей нет, но идея звучит абсолютно разумно. Человек разобрался в сложном многопоточном процессе и предложил улучшения — может, и несвоевременные, рефакторинг ради рефакторинга. Но как только захочется этот код усложнить, можно будет этот рефакторинг всё-таки сделать. По факту прошло несколько месяцев, и мы занялись этой задачей. Я с удовольствием взял его в штат. Мы все не гении. Можно прийти, разобраться в чём-то и указать нам на наши проблемы. Это ценится.

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

Источник