Евгений Штерн (Okko): Мне кажется, сеньором за два года можно стать, если у тебя есть, во-первых, свои какие-то задатки — это и образование, и какой-то склад личности, и мотивация, и у тебя есть подходящие задачи. Если человек выходит в какую-то компанию и перекладывает 2 года одинаковые JSON’ы из одного места в другое, навряд ли он вырастет за два года до сеньора. Он и за три может не вырасти, и за 10 тоже не вырастет. И если человек попадает в какую-то такую ситуацию, когда у него есть большой классный проект, там он мотивирован, у него хватает бэкграунда своего, хватает софт скиллов, он вполне может вырасти за 2 года. То есть я видел людей, которые к нам приходили, на прошлой работе, и за 2 года они действительно вот вырастали в сеньора. Но это, скорее, исключение, чем правило. Ну, вопрос с подвохом, да, то есть по сути мы говорим о трех годах, как правило, и тогда мы можем вырастать в сеньора. Но все возможно.

Петр Белкин (Сбер): Но я бы еще добавил к спикерам историю с командной работой. На самом деле для меня сеньор — это человек, который уже достаточно хорошо прокачан в софт скиллах, и это помимо знаний, которые он там… Не только JSON перекладывал, но еще и с командой научился работать, и, может быть, уже кого-то поменторить успел. Вот поэтому знания, желание развиваться, какие-то задатки, про которые мы проговорили, проект и куча наработанного опыта. Ну и, естественно, командная работа, в которой он должен участвовать. По моему мнению, если он не очень круто ладит с командой, не умеет заниматься наставничеством, хотя хорошо пилит код — ну он больше мидл, чем сеньор. Задам тренд какой-то холиварный дискуссии.

Из зала: Да, если я вас правильно понял, то помимо каких-то природных качеств личностных, надо еще, чтобы человеку немножко повезло. Ну он попал в правильную компанию, в правильный проект. А тогда такой вопрос: я например хочу стать сеньором. И вот я там первую работу ищу, еще что-нибудь… Окей, у меня есть брат, он учится в университете на первом курсе, я хочу сделать из него сеньора за 2 года. Куда мне его закинуть? Ну помимо того, что там взять его к себе на работу и сделать его сеньором за 2 года. Куда-нибудь в другое место. Как направить, на что смотреть? Вот человек реально хочет очень быстро вырасти, стать сеньором. На что ему больше всего смотреть, какие задачи брать, какие проекты брать, в какие компании идти? Ну вот на эту тему если подискутировать?

Евгений Штерн (Okko): А я скажу вот такую штуку, что по крайней мере в Okko принято думать, что сеньор — это человек, который находит сеньорские задачи. И если человек идет по принципу «мне повезет, меня закинут куда-то, меня куда-то унесет», то это займет чуть больше времени. А если человек понимает, куда он идет сегодня и сейчас, то он сам найдет ту компанию, того лида и те задачи, которые его вырастят, как бы забавно это ни звучало. Это замкнутый круг. Можно изобрести машину времени, вернуться к себе и сказать, что надо делать, но вот так это работает, на мой взгляд.

Из зала: То есть нельзя стать сеньором за 2 года, если ты уже не стал сеньором за 2 года…

Лев Орехов (Яндекс): Ну я тут все-таки оспорю. Не всегда у тебя есть возможности. То есть понятно, что ты для того, чтобы вырасти в сеньора, ты должен искать возможности. Понятно, что если ты будешь просто сидеть и делать задачи, не вырастешь. Но не всегда, не в любой компании у тебя просто будут возможности такие. 

Сергей Анчутин (Doubletapp): А если такая штука: искать подработку или пет-проект, или вторую работу, чтобы у тебя Experience в два раза рос за одно и то же время?

Петр Белкин (Сбер):  Мне кажется, как раз пет-проект — это одна из топ-инициатив, в которых ты можешь побыстрее найти какой-то рост и попробовать себя в других нишах возможных. И потом сделать пивот в ту сторону, в которой тебе интересно. То есть, наверное, чтобы стать сеньором за 2 года, у тебя помимо какого-то желания развиваться по той сфере, в которой ты хочешь стать сеньором, должна развиваться насмотренность путем проб и ошибок. То есть если не пытаться, не искать самому, а надеяться на удачу, мне кажется, ты за 2 года никуда не вырастешь, несмотря на то, какой бы ты крутой специалист ни был, все смотрят тоже на то, насколько у тебя развито чувство что-нибудь поделать и активный человек в комьюнити или нет. Это мое мнение.

Из зала:  У меня вопрос. У меня сложилось ощущение, что когда мы говорим про сеньора за 2 года, лично меня это смущает, потому что у меня такое ощущение, что у нас, возможно, разное понимание — кто такой сеньор. Может, мы про это немножечко поговорим? Был такой заход на холивар, что кроме технических скиллов, которые быстро прокачиваются, есть еще софт скиллы, которые качаются сильно медленнее.

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

Евгений Штерн (Okko):  Но по сути это закрытый вопрос. Да, ты просто добавил качество. Но я могу добавить такую холиварную тему: если разобраться, кто действительно есть сеньор? Потому что сеньором можно стать за два года, просто надо наняться на работу мидлом. Потом пойти через какое-то время и сказать: «Я увольняюсь». Вот, и стать сеньором с возложением венка, вас коронуют мечом.

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

Из зала: Я поддерживаю предыдущий вопрос, тоже хотел сказать, что про сеньора не так все однозначно. Почему например? То есть мы говорим о составляющих его хард скиллов, каких-то софт скиллов, и что конкретно еще про опыт интересует. В моем понимании есть интересная такая штука, когда у специалиста не просто хард скиллы крутые, софт скиллы свои, но когда он в принципе понимает работу и других каких-то областей, кругозор какой-то отличает. И если мы просто сложим в часы 2 года… То есть просто вы сказали про сеньора номинального — устроиться мидлом куда-то, переуволиться и куда-то устроиться. То есть мы же говорим, наверное, не про такого сеньора, а сеньора настоящего. Который признается сообществом. 

И вот то же самое признание — за счет чего его тоже получать, если ты 2 года проработал… Ну все эти 2 года, даже наверное если ты будешь тратить 24/7, сможешь ли ты все это заработать: и кругозор этот разный, и опыт этот разный, и проекты какие-то. То есть просто в диалоге, скорее всего, даже не выстоишь с каким-то действительно опытным человеком. Он просто, скорее всего, сможет тебе кинуть чего-то, что ты не ответишь. То есть это про опыт тоже. То есть даже цифрах просто рассуждать…

Петр Белкин (Сбер): У меня родился, наверное, ответный вопрос на вопрос. Ну вот реально мы сейчас говорим про конкретную цифру в 2 года и пытаемся ее осязать с точки зрения того, много это или мало. 

Сергей Анчутин (Doubletapp): Просто считается, что это мало. Там нужно 4 года.

Петр Белкин (Сбер): Что действительно фундаментально поменяется за 4 года по сравнению с двумя с точки зрения хард скиллов? 

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

Петр Белкин (Сбер): Ну видишь мы как бы подошли к теме, что на самом деле есть две плоскости — это количество и качество, про которые мы уже проговорили. 

Сергей Анчутин (Doubletapp): Понятно, что нельзя мерить просто годами и что нужен опыт, кругозор расширенный. Но возможно ли вот этот необходимый опыт получить за 2 года? 

Петр Белкин (Сбер): Это да, скорее, исключение.

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

Сергей Анчутин (Doubletapp): А что такое сложный проект? Проекты же очень разные есть: можно спроектировать вот видеосервис, видеохостинг, а можно спроектировать там простое мобильное приложение с новостями.

Лев Орехов (Яндекс): Отлично. Ну например: вот мобильное приложение в Яндекс Путешествий — это большой сложный проект.

Сергей Анчутин (Doubletapp): Да.

Из зала: Это вопрос?

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

Сергей Анчутин (Doubletapp): А понимание градации сложного / не сложного проекта у тебя есть? Нужно уметь поднимать кластера и распределять нагрузку по разным кластерам и писать такой код, нужно уметь писать асинхронный код? 

Лев Орехов (Яндекс): Нет, это по-другому. Я могу доверить человеку какой-то проект, если этот человек сам может понять, что нужно, для чего мы делаем этот проект, что нужно, чтобы это сделать. И вот под «что нужно, чтобы это сделать» это вот как раз «поднять кластера, написать код»… 

Сергей Анчутин (Doubletapp): Как ты оцениваешь критерии того, что человек сможет грамотно, и грамотно с точки зрения для бизнеса, выбрать инструменты для реализации? Чтоб это было оптимально быстро и оптимально расширяемо, а не было суперпереусложнений или не было суперпросто и через год пришлось бы переписывать?

Лев Орехов (Яндекс): Ну смотри, вообще если человек уже дорос до сеньора, я ему уже, конечно, доверяю. Он уже себя проявил. А до того, как он растет до сеньора, с ним работает его руководитель, условно.

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

Лев Орехов (Яндекс): А, ты про это. 

Сергей Анчутин (Doubletapp): У нас же тема — собеседования.

Лев Орехов (Яндекс): Мы просто до этого не собеседования обсуждали. (смеются) Слушай, если нужно определить, что человек сеньор, у меня есть три основных фильтра. Первый — это то, что он умеет писать код, это секции с кодом. Второе — то, что он умеет делать архитектуру, это секция систем-дизайн, и третье — то, что он обладает какими-то софтовыми скиллами и релевантным опытом — это финал. 

Сергей Анчутин (Doubletapp): Ты сможешь за час секции определить, сможет ли он нормальную архитектуру накидать или нет?

Лев Орехов (Яндекс): Скорее, да. Понятно, что не бывает стопроцентной точности. Но вообще да. 

Сергей Анчутин (Doubletapp): Окей, а ты много сеньоров за карьеру нанимал?

Лев Орехов (Яндекс):  Да.

Сергей Анчутин (Doubletapp): Какой порядок? Типа, 10-20-5-1?

Лев Орехов (Яндекс):  Меньше 10 и больше 5, где-то так.

Сергей Анчутин (Doubletapp): И потом в реальности оказалось, что они все были сеньорами? Они подтвердили свой грейд, который ты дал при собесе?

Лев Орехов (Яндекс): Да.

Сергей Анчутин (Doubletapp): Окей, давайте дальше, есть Женя, Петя, что сказать?

Из зала: Сколько опыта было?

Сергей Анчутин (Doubletapp): Вопрос был: сколько было опыта в годах?

Лев Орехов (Яндекс): Слушай, я тебе это не отвечу… Больше двух — точно.

Евгений Штерн (Okko): Я вот здесь чуть-чуть вернусь назад. Как бы, что кривить душой, если мы получаем резюме, где написано: одна компания — там два года опыта, один проект, и написано, что человек типа джун — сеньор… Скорее всего, эффект wow не случится. Случится обратный эффект, что вот, сейчас мы его пойдем на собесе раздербаним и поймем, как он вот так вот это обманул систему, ну что душой кривить? 

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

Потому что работает у нас много всего. Когда мы это сочетаем в одно, то почему-то не работает ничего, и дальше мы идем разбираться, и 2 недели превращаются в 6 спринтов. 

Сергей Анчутин (Doubletapp): Напомню вопрос. Дай критерий сеньорности при собеседованиях.

Петр Белкин (Сбер): Критерии сеньорности — тут уже ребята многое проговорили. 

Сергей Анчутин (Doubletapp): Ты согласен целиком с ними?

Петр Белкин (Сбер): Да, я согласен, но я добавлю от себя, что есть история, связанная с тем, что на собеседованиях сложно проверить такой навык, но хотелось бы… Ну, для меня сеньор — это человек, который еще помимо того, что он хорошо знает систем-дизайн, как это работает под капотом, его можно запереть, и он сам решит задачу… Это история, что он может рассказать, когда он решит эту задачу, и он может эту оценку сделать. То есть он может грамотно декомпозировать в задачу входные требования, имеет навык задавать правильные вопросы, и при решении какой-то непонятной задачи… То есть можно это реверсивно проверить, и это важно, как я говорил, что человек умеет работать в команде. 

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

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

Сергей Анчутин (Doubletapp): Ты делаешь большой акцент постоянно на то, что сеньор обязательно должен менторить джунов. А если я не хочу менторить джунов? Вот я глубокий технический специалист, я понимаю менеджеров, но я не хочу никого растить. Так нельзя?

Сергей Анчутин (Doubletapp): То есть он скажет: «Можно джунов ко мне просто не подпускать? Вот я пилю сложную штуку, и ее надо пилить быстро, нужно быстро деливировать. Можно без джунов, пожалуйста? Чтобы мне не нужно было никому объяснять элементарные вещи».

Петр Белкин (Сбер): Есть какие-то узкие задачи, к примеру, на стадии, когда мы развивали платформу, у нас были такие задачи, что надо быстрее нанять человека, который нам запилит быстро сервис, сделает это без лишних вопросов и не будет сильно долго это делать. Поэтому в этой стезе, когда он достаточно изолирован, то да.

А когда команда растет и делает какую-то фичу, — это фичтим, которая ответственна за продукт. У него должна быть ценность — люби ближнего своего — должна быть развита. Если у тебя есть джун, значит к нему нужно нормально относиться.

Сергей Анчутин (Doubletapp): Ты хотел, Женя, поспорить про обязательность растить джунов?

Евгений Штерн (Okko): Поспорить можно. Это зависит от размера компании, потому что местами… Я знаю тимлидов, хороших тимлидов, которые готовы лидить, но не готовы менторить, вот. И периодически бывает так, то что человек может быть хорошим командным игроком, но вот не хочется ему, не может, то есть вот не хватает его на это, обжегся где-то. И формально он может быть и сеньором, и тимлидом, и назови его как хочешь, но при этом вот менторить он не будет. Такие кейсы бывают. 

Петр Белкин (Сбер): Я попробую придумать термин тому, что я называю «менторить». Это я не говорю, что он типа 24/7, не все сеньоры обязаны 24/7 сидеть с джунами и объяснять, как конкретно решить какую-то задачу. Это история про то, человек умеет грамотно направлять, какую конкретную сферу ты можешь посмотреть и где почитать. То есть это, возможно, для джуна какая-то точка опоры для задавании вопросов. Но не обязательно ты можешь быть чуваком, который у тебя 24/7 менторит. То есть это история не совсем про это.

Лев Орехов (Яндекс): Я считаю, что, скорее, нет. На секции с кодом… Ну, вообще как? Секции с кодом у нас проводят и мидлы, и сеньоры, и здесь без разницы в принципе. Систем-дизайн уже, наверное, под вопросом. Если у тебя мидл умеет в такой систем-дизайн, то непонятно, почему не сеньор на самом деле. Но если говорить про финалы, то тут понятно, как бы на финале мидл вряд ли что-то сможет сделать, дать какую-то оценку. Так что на секциях с кодом — пожалуйста, на системном дизайне уже вряд ли, на финалах точно нет.

Евгений Штерн (Okko): Можно я здесь дополню очень коротко? Я, наверное, здесь соглашусь, но дам такую методику: если вы собеседете кого-то и вы понимаете то, что он там шарит в каком-то из SDK и технологии, а вы нет, попросите просто сравнить это с чем-то, в чем вы шарите, и вы таким образом… Вам человек расскажет, и вы примерно поймете, как он шарит той секции, в которой вы не шарите. Ну просто как некий лайфхак.

Лев Орехов (Яндекс): Я согласен, но плюс к этому еще есть вторая рекомендация. У тебя в компании, наверное, есть какие-то образы грейдов, и наверное, у тебя есть какое-то описание ожиданий от этих образов грейдов. Вот ты можешь примерно себя к ним приложить. Или это не помогает? Ну а точнее, чем вот так, наверное, не получится. 

Сергей Анчутин (Doubletapp):  Ну смотрите, если сходить пособеситься: сходил пособесился в одну компанию — мне сказали мидл, во вторую — джун, в третью — сказали сеньор.

Лев Орехов (Яндекс): Бери сеньора. (смех)

Сергей Анчутин (Doubletapp):  Ну а потом к тебе и говорю, что в Оkko меня считают сеньором, а ты считаешь меня мидл+ и говоришь, что я плохо систем-дизайн прохожу.

Лев Орехов (Яндекс):  Да, я тебе скажу: «Бери мидл+ или уходи в Оkko». Все просто.

Сергей Анчутин (Doubletapp):  Ну то есть это система какая-то — она в разных компаниях очень разная. Непонятно, какую из линеек примерять к себе. Мне считать себя сеньором, если Google считает, или Яндекс, или Сбер? 

Лев Орехов (Яндекс): Я еще раз повторяю: лучше считать себя по верху. Вот за сколько смог продать, за столько смог. Это будет самая лучшая стратегия с твоей точки зрения.

Сергей Анчутин (Doubletapp): Тогда мы приходим к выводу, что эти все линейки — они вообще очень субъективные, и нужно просто идти туда, где тебе больше дают. 

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

Сергей Анчутин (Doubletapp): Нет, ну компании, контекст — они такие важные, но тебе обидно, что ты такой крутой, а тебя не хотят считать тем, кем ты себя считаешь.

Лев Орехов (Яндекс): Ну тебя же где-то считают таким крутым, нет?

Сергей Анчутин (Doubletapp): Но туда ты не хочешь идти. То есть какой тогда смысл вообще в этих грейдах и названиях и вообще в каком-то резюме, если все там определяет собес и конкретное место и все суперсубъективно.

Лев Орехов (Яндекс): Слушай, ну давай так, если от сферических компаний в вакууме переходить к более конкретным, то вот собеседование Яндекса, собеседование Meta, собеседования Facebook — они имеют примерно одинаковые грейды, примерно одинаковое количество испытаний, и если ты прошел в Яндекс на сеньора, ты, скорее всего, пройдешь и в ту же Meta на сеньора. И в Сбер, наверное, тоже.

Сергей Анчутин (Doubletapp): Вот смотри, у меня тут есть даже пример из нашей реальной практики. У нас в 20-м году собеседовались люди на аутстафф в Сбер и в Яндекс, и было два человека: один прошел в Яндекс, не прошел в Сбер, второй прошел в Сбер и не прошел в Яндекс. Собесы были на одной и той же неделе, они были примерно одинаково готовы. И тогда это дало мне супер понять, что все очень субъективно и зависит от собеседующих, их настроения и просто фазы Луны.

Лев Орехов (Яндекс): А в чем там была проблема? Почему не прошли Яндекс?

Сергей Анчутин (Doubletapp): Ну сказали, что тут секция не пройдена, а при этом в Сбере она была отлично пройдена, и там был грейд мидл+. А в Яндексе сказали, типа больше джуна+ не дадим. И с другим человеком была обратная ситуация, симметричная, без дополнительной подготовки на одной и той же неделе. 

Лев Орехов (Яндекс): Видимо, Сбер как-то выбивается из этой линейки, которую я привел.

Сергей Анчутин (Doubletapp): Субъективность все равно есть, и она очень сильная. Вы согласны с этим?

Лев Орехов (Яндекс): Сейчас я соглашусь с тем, что субъективность есть, а теперь добавляй.

Евгений Штерн (Okko): Я буквально коротенький момент хотел добавить: заметьте, на собеседование в Okko никто не жаловался. Вообще никогда. Эмпирически выведено.

Сергей Анчутин (Doubletapp): Ты знаешь, как Неуловимый Джо…

Петр Белкин (Сбер): У тебя точно нет никаких примеров про Okko?

Сергей Анчутин (Doubletapp): Пока нет.

Из зала: Можно?

Сергей Анчутин (Doubletapp): Да-да, давай. Если нечего добавить.

Евгений Штерн (Okko): Я сейчас послушаю и добавлю.

Из зала: В общем вопрос какой — про критерии сеньорности тоже. Тут как-то была затронута тема относительно проектов, сложности проекта, что такое сложный проект и так далее. Про критерии сеньорности проекта больше интересно узнать от вас… Допустим, как вы бы смотрели… Смотрели ли вы и насколько серьезно на то, первое, сколько проектов у человека было, насколько они большие, и третий момент — их предметная область. Потому что, в моем понимании, тут уже затрагивали бизнес, возможно, оно схоже. Человек-сеньор — он, наверное, должен уметь хорошо, достаточно быстро разобраться в предметной области. Соответственно, если наверное у человека были маленькие проекты, у которых была несерьезная например, неглубокая предметная область, или был один, но очень серьезный… То есть это же наверняка по-разному влияет? И сеньору, наверное, по каким-то критериям относительно этих вопросов — то есть предметной области и количеству проектов, с которыми он работал, и какая-то корреляция между этим. 

Вот и соответственно к вопросу про 2 года: насколько можно эти критерии удовлетворить, то есть за 2 года разобраться в сложный предметной области и уметь сделать это еще раз в другой? То есть вот такой можно вопрос поставить. 

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

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

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

Евгений Штерн (Okko):  Я вот здесь вот начну сначала как человек, который собесил индуса, у которого было 16 лет опыта, при том, то что ему было лет 25, вот. Я, периодически бывает, даже не всегда читаю резюме. И на самом деле не только я. И местами что там написано — не является настолько важным, как вопрос: «Расскажи о своих последних двух проектах». И на самом деле очень часто интервьюеры это делают.

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

Лев Орехов (Яндекс): Окей. Я поотвечаю на вопрос предыдущего оратора. Вообще совершенно с тобой согласен. Количество проектов, сложность проектов, сложность бизнес-логики очень сильно влияет в оценке сеньорности. Можно ли это все сделать за 2 года? Возвращаясь к базовому вопросу — да. Я ответил да, потому что у меня живой пример есть, когда человек пришел к нам из стажеров, мы наняли его как младшего разработчика, и он за 2 года вырос в сеньора. Но ему очень сильно повезло, сошлись все необходимые звезды — его личные качества, сложный большой проект, хорошая команда и хороший руководитель, который его хорошо менторил.

Из зала: Когда мы секцию начали после разминки по поводу «кто такой сеньор», значит, и поговорили, каким образом собеседовать сеньора, был вопрос, что есть две категории сеньоров: сеньор — совсем настоящий сеньор, такой начинающий сеньор и… Сеньор- и сеньор+, короче. 

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

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

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

Сергей Анчутин (Doubletapp): Интересно, может ли хоть кто-то в зале разбрасываться сеньорами, даже если это второго типа хотя бы? 

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

Петр Белкин (Сбер): Объявление: продаю синьора, технического эксперта, забирайте. Бартер.

Из зала: А не связана ли эта сеньорность… Ну во-первых, я считаю, что сеньором за 2 года стать невозможно, а второе — это то, что не связано ли это с тем, что просто на рынке инфляция, и все бегут за повышением зарплаты, а единственный способ повысить зарплату — уволиться и пойти типа на грейд повыше, потому что на собесы можно заточиться, все можно выучить. А сейчас еще ChatGPT подъехал. Короче не связана ли сеньорность за 2 года с тем, что рынок пострадал сильно от инфляции, типа всем нужны сеньоры. Ну значит все будут вокруг сеньорами. Типа никому не нужны джуны, потому что джунов надо учить, всем нужны сеньоры, ну все такие — окей, строчка в резюме переписывается, опыт дополняется соответственно. Поэтому сказали, что на резюме можно толком не смотреть и все выясняется в режиме диалога на собесе. Типа, может быть, это повлияло на сеньора за 2 года? 

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

Петр Белкин (Сбер): Я думаю, что не связано на самом деле с инфляцией. Мы опять возвращаемся к тому же вопросу — можно ли стать сеньором за 2 года. Я на самом деле зацепился бы еще и подхватил про то, что вот когда задачу свитчнуть техстек на другой, на принципиально разный, и человек не может ее решить, и что это значит, что он не сеньор. Но блин, может быть, ему просто не довелось до какого-то времени что-то сделать, не знаю, на каком-то другом техстеке, отличном от Java или Kotlin например. Вот, он прекрасно может решить задачу и на Java, и на Kotlin, но при этом там на каком-то другом языке, к примеру, на Scala он это сделать не сможет. Вот вопрос как бы близости этих техстеков — мы вот сейчас будем про эту тему тоже говорить. 

Сергей Анчутин (Doubletapp): Значит, он недостаточно сеньор, чтобы быть интервьюером. 

Лев Орехов (Яндекс): Наверное, да.

Дальше у нас там, опять-таки, возвращаясь к систем-дизайну, он вообще обычно Language-agnostic. Ну в принципе ты там, ну, кэши, базы там, консистентность, репликации, вот это все там — в таких терминах идет обсуждение. Иногда можно кодом написать, но опять же, пусть на чем умеет, на том и пишет. Взяли.

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

Сергей Анчутин (Doubletapp): Вы их берете на грейд сеньора при этом?

Лев Орехов (Яндекс): Конечно, знание языка никак не влияет. 

Сергей Анчутин (Doubletapp): Но при этом они полгода работают не как сеньоры, с недостаточной производительностью на новом языке.

Лев Орехов (Яндекс): Тут у нас в секции бэкенда выступал человек из VK, и он очень правильно заметил, что ты 5% времени пишешь код, а все остальное время делаешь содержательные задачи. Поэтому такие люди — они начинают гораздо быстрее приносить пользу на самом деле.

Евгений Штерн (Okko): Можно я здесь добавлю конкретный пример, как собеседовать человека с другим стеком? Есть системный дизайн, по которому можем посмотреть, как человек в архитектуры, и как правило, вы сможете как бы эту секцию провести. Берите эксперта и смотрите, как он собесит в другом стеке, это будет более информативно, чем попытки самому в Haskell. Но если надо, то надо, конечно, но всецело вот. А про алгоритмы я пока что не буду сейчас холиварить, это другая история. Мы к ней, я думаю, еще подойдем. 

Петр Белкин (Сбер): Я только лишь добавлю. Вот мы только что затрагивали тему про 5%, но мы же все менеджеры и знаем: там 5%... Одни 5% весят немножко по-другому, чем остальные 95. То есть там 80% и правило 80 на 20 — оно тоже как бы на самом деле…

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

Какой вопрос был?  С плюсов на Python. Вот например какой-нибудь питонист, который считает себя сеньором, и утвержденный комьюнити сеньор, который может путем менторства и наставничества развивать человека и сделать из плюсовика крутого питониста. При этом бэкграунд в виде Computer Science, систем-дизайн и работы в проектах — сложных, крутых, как мы их называем, ну, это одно из самых важных.

И те 5%, которые он не будет писать код какое-то время, он может это время аллоцировать на какие-то другие, более важные для команды задачи. То есть это вопрос веры и инвестиции в человека.

Петр Белкин (Сбер): Кстати, если ты там переходишь с плюсов на Python, у тебя же Python сам написан на C, и ты должен там… Просто абстракция большая.

Петр Белкин (Сбер): Ну да, да. Просто, может быть… Я не специалист в Python, там есть куча библиотек, которые на плюсах написаны. 

Сергей Анчутин (Doubletapp): По теме свитчинга с разных стеков кто-то еще хочет что-то прокомментировать, добавить?

Из зала: На самом деле стеки… Мы тут в основном свитчинг относительно сеньора обсуждали. Но вот интересно тоже узнать, а слишком ли меняется все то, что вы сказали, относительно, допустим, вот тех же мидлов, мидл+ и так далее? То есть пришел человек совсем с другим стеком и свитчится на него. Но нередко же, когда ищут, не просто указывают, что вот такие там технологии, такой-то стек. То есть вообще насколько валидно брать себе человека с прямо другим стеком? Неужели на нужном вообще никого нет? Я не знаю. Поэтому в плане сеньоров это норм, а в плане мидлов — нет, потому что мидла проще найти. Вот в этом духе. 

Евгений Штерн (Okko): Значит на самом деле проще всего перейти, не потеряв грейд — это джунам. Это прямо вот мгновенный переход с одного языка в другой язык. Конечно же, я думаю, коллеги согласятся, то что чем выше грейд — тем все-таки этот переход будет более быстрым, в том числе это связано еще с тем, то что все языки ходят по кругу. И когда один язык решил уже какие-то проблемы… На секундочку, если кто-то помнит, был Windows Mobile 53, и он вообще-то писался на C#, если не ошибаюсь, где было куча всего всякого классного разного. И в то же время Android писался на шестой Java. И на секундочку, разрыв между этими операционками — он то есть достаточно… Немало лет. Поэтому опыт, конечно же, здесь будет решать. А если вы переходите в рамках одной компании, то на самом деле никто вам грейд понижать не будет, потому что это прямой путь к тому, что человек пойдет и уволится.

Сергей Анчутин (Doubletapp): Кстати, а вообще нужно ли менять свой стек в процессе своей карьеры, через 5 лет сменить стек? Это повысит ли твою цену на рынке и повысит ли твои скиллы? То есть станешь ли ты более крутым специалистом?

Лев Орехов (Яндекс): Слушай, ну я в своем опыте менял стек раза три. Помогало. Ну, в смысле интересно.

Сергей Анчутин (Doubletapp): Это дало какой-то прогресс тебя как техспециалиста, в твоих хард скиллах. То есть ты посмотрел в одном языке конструкции, в другом, какие-то особенности, как оно работает под капотом, и ты вырос технически.

Лев Орехов (Яндекс): Слушай, мне кажется, что незначительно. Если и было, то незначительно. 

Сергей Анчутин (Doubletapp): То есть язык — это все-таки инструмент. И при этом… А, при этом у тебя был свитч только на бэкенде, ты всегда был бэкендером.

Лев Орехов (Яндекс): Да, все так. 

Сергей Анчутин (Doubletapp): Вот, а если фронтендер становится бэкендером или наоборот? Писал ты бэк, нет, писал ты приложение на Kotlin, и теперь начинаешь писать бэк на Kotlin. Насколько быстро ты перейдешь? Считается ли мобильщик на Kotlin потом сеньором бэкенд на Kotlin?

Лев Орехов (Яндекс): Слушай, давай так. У меня в личном моем опыте не было такого, чтобы люди эффективно переходили там с фронтенда на бэкенд или с бэкенда на фронтенд, или еще как-то. Но у меня были смежники, которые перешли с бэкенда на мобильную разработку, и у них все хорошо получалось. Без потери грейда. С плюсов на Kotlin. 

Сергей Анчутин (Doubletapp): Вот ты, Женя, мобильный разработчик, тебе есть что сказать на эту тему? Ты бэкенд вообще пробовал когда-нибудь?

Евгений Штерн (Okko): Да. Опыт у меня такой был, он был, кстати, достаточно классный, то есть вот… И при том такой опыт — он действительно позволяет… Вот например я бы хотел сейчас в мультиплатформ пойти. Я там увидел Ktor. А Ktor по сути — это такой бэкенд на Kotlin, на котором можно фигачить. У меня был такой опыт, он меня немножко поразил тем, то что я пошел в бэкенд и такой: «Ну, сейчас будет типа новая архитектура — как на мобилке». А там такая Спарта — типа пиши как можешь, и вот это вот все. И архитектуру было найти сложнее.

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

Петр Белкин (Сбер): У меня есть опыт: в одной из команд у нас была девочка, которая свитчнулась с мобилы на разработку бэкенда, и успешно свитчнулась, так, что она с мидла потом выросла в сеньора на бэкенде. Конечно же, это было не слишком прямо сразу. 

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

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

Сергей Анчутин (Doubletapp): А как тогда это с самого опорного эксперта нанять?

Петр Белкин (Сбер): Ну как мы уже недавно проговаривали, если СТО, например, был бэкендером, нанимает его, там, в мобайл, то надо найти эксперта из мобайла. Ну можно, например, найти кого-нибудь из комьюнити, с кем он общается и доверяет, из другой компании. Или привлечь ребят, которые аутсорсингом по найму занимаются, экспертов, и заплатить, и они тебе прособеседуют. А ты будешь участвовать, принимать вторым участником решения, так скажем.

Лев Орехов (Яндекс): Ну я как СТО скажу, что я не умею собеседовать мобильную разработку, и я не умею собеседовать аналитику, и я не умею собеседовать фронтендеров. Ну ладно, фронтендеров я когда-то собеседовал, и у меня получалось. Поэтому да, мы берем экспертов, мы берем руководителей групп разработки мобильной и бэкенда, фронтенда, и они сами все собеседуют. 

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

Сергей Анчутин (Doubletapp): А есть ли у кого-то еще вопросы, комментарии по темам трансперехода между стеками? 

Из зала: Давайте я чуть ясности дам. Когда я говорил, что «менять стек», я не говорил, что люди, которые пишут на Java 20 лет, должны менять Java на что-то еще. Я имел в виду в контексте задачи только.

Про вопрос, который мы сейчас обсуждаем. А что, если ты кардинально меняешь свою профессию, то как меняется твой грейд с этим? Ну условно, ты занимался бэкенд-разработкой, тебе она осточертела, и ты пошел продуктовым аналитиком читать A/B тесты. Что с твоим грейдом происходит? Ну очевидно, что тебе не могут дать сеньора, потому что у тебя вообще никакого опыта нет, кроме того, что это где-то параллельно с тобой существовало. Что в таком случае происходит?

Евгений Штерн (Okko): Я хочу ответить вопросом на вопрос просто потому, что я могу. На самом деле вот у меня был такой опыт. Был такой FuckUp Nights в Питере, и там приходили разные директора компаний и о чем-то рассказывали. И я не буду называть компанию, но в общем там в описании вакансии было: «Нам нужен программист, чтобы код писал, ну и в целом там типа все. И код чтоб был хороший». И я задал вопрос, я говорю: кого вы хотите найти вообще? То есть зачем вы выкладываете такие вакансии, какой результат вы хотите получить? На что мне директор компании сказал, что вы ничего не понимаете, типа вы придете к нам программистом, а уйдете маркетологом. На что я сказал, что я к вам в принципе не приду и, наверное, никто не придет. 

Вот, а грейд может проседать, но вот здесь, наверное, это чуть-чуть история по Яндексу. То есть Яндекс скажет, что грейд никогда не просядет, потому что Яндекс меряет достаточно в таких вот технически базовых вещах. Какой-то стартап, которому нужно «перейти кранчики», скажет, что «Господи, ты не знаешь наш суперкрутой SDK, где мы идеально писали 15 лет с нуля? И он работает, если там нахимичить с грейдлом 15 раз, возможно, с пятого раза». И тогда грейд просядет.

Грейд, как и на самом деле самоопределение «сеньор» — тоже в глазах смотрящего всегда. 

Лев Орехов (Яндекс): Я про Яндекс прокомментирую. На самом деле если в Яндексе ты пойдешь из разработчика бэкенда, например, в продуктовые аналитики, то твой грейд вполне может просесть. Ну потому, что ты же очевидно выполняешь эту работу хуже. Он может не просесть, если ты как-то подмутил со своим начальником и уже начал заниматься продуктовой аналитикой, но никто не знал, и ты уже такой вроде крутой. Тогда все будет хорошо.

А так у нас были кейсы, когда люди переходили на соседнюю ветку какую-то, и был, например, даунгрейд. 

Сергей Анчутин (Doubletapp): И вы прямо зарплату снижали?

Лев Орехов (Яндекс): Нет. У нас принцип не грейд не снижать, а зарплату. Зарплата оставалась.

Сергей Анчутин (Doubletapp): Так получается наоборот выгодно: у тебя зарплата осталась, грейд стал меньше, от тебя стали ожидать меньше, и ты можешь более легко доучиться, а потом прийти сказать: «Ну раз у меня грейд растет, давайте и зарплату тогда поднимем». 

Лев Орехов (Яндекс): Не так, смотри: у тебя грейд понизился. Ну да, конечно, от тебя меньше ожидания, но у тебя зарплата выше по вилке. Соответственно она растет медленнее. А какие-то особые прорывы ты не сможешь объективно делать. Так что по деньгам ты будешь проигрывать достаточно…

Сергей Анчутин (Doubletapp): Но при этом у тебя есть такие теперь преимущества перед другими продукт-аналитиками, потому что ты знаешь код и понимаешь глубже, как работает продукт с точки зрения кода. Ты можешь за счет этого вывозить.

Лев Орехов (Яндекс): Это тебе не поможет. Ну то есть вот такие смежные компетенции, скорее всего, будут помогать тебе гораздо меньше, чем отсутствие твоих ключей — основных компетенций. Это просто по опыту вот таких вот переходов. Обычно это так. Человек проседает какое-то время, его зарплата, доход растет медленнее, но да, мы добрая компания и стараемся сделать так, чтобы он все-таки не отстрелился и постепенно нагнал свое.

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

Еще интересно, что Женя скажет. То есть относительно мобилки сейчас нередко встречаю такую тему, что, например, мобильный разработчик — он на самом деле должен понимать и под Android, и под iOS, уметь какие-то такие моменты. Если мы говорим чисто про Kotlin… Вот интересную вот штука: писал про бэк, на Ktor, потому что я тоже пробовал, то есть я Android-разработчик, я пробовал, думаю, ну, интересно самому сделать. И на самом деле меня так заинтересовала идея того, что, блин, можно же человеку одному в принципе и мобилку писать — тут и бэк, и технология в принципе интересная, классная.

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

Евгений Штерн (Okko): А здесь я скажу: с одной стороны это очень положительная вещь, с другой стороны, для определенных компаний она может быть совершенно не нужной. Для роста специалиста, на мой взгляд, вот если сейчас пойти и послушать доклады про iOS, то всецело большинство вещей там будут понятны, и местами дисциплины перегоняют друг дружку. И как бы это является безумно полезным — хотя бы быть фуллстеком именно в этой вот экосистеме, когда iOS/Android/Backend…

Ну и плюс у нас все-таки (это очень холиварная тема) ChatGPT начинает расти, и в итоге, я вангую, что будут специалисты, которые будут там с промтом фигачить на каком-то KMM и туда, и сюда.

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

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

Сергей Анчутин (Doubletapp): То есть этот грайд в компании — он направлен на решение бизнес-задачи. Если ты сеньор — это грейд в решении этой бизнес-задачи.

Лев Орехов (Яндекс): Да, я дополню. В Яндексе фулстеков мало. Ну во всяком случае в Путешествиях фулстеков нет. У нас есть бэкенд и есть фронтенд, есть мобильная разработка. Очень тяжело быть фулстеком и одинаково эффективно работать и на мобилке, и на бэкенде. Очень разная специфика, очень разные там стеки, очень разное все. При этом, может быть, ты слышал такой термин, как T-shaped-специалист? Вот это, кажется, полезно, когда ты в какой-то области являешься экспертом, но при этом кругозор у тебя есть хороший. Он сильно помогает на стыках. 

Сергей Анчутин (Doubletapp): А T-shaped — он у тебя какого грейда должен быть? То есть ты должен быть джуном во фронтенде или мидлом?

Лев Орехов (Яндекс): Во-первых, T-shaped — это отдельное измерение. У тебя есть грейд, есть T-shaped. T-shaped может быть любого грейда.

Сергей Анчутин (Doubletapp): Но ты бэкендер и сеньор бэкендер. Чтобы быть T-shaped, тебе нужно во фронтенде что понимать, на каком уровне?

Лев Орехов (Яндекс): Ну в принципе достаточно знать, что там JS, Type Script, React под капотом и примерно понимать какие-то возможности, собственно говоря, Runtime JavaScript’ового. 

Сергей Анчутин (Doubletapp): Нужно понимать, как работает браузер, как там фронтенд делает запросы? 

Лев Орехов (Яндекс): Ну да, естественно, такие штуки тоже. Но при этом тебе не нужно знать все их миллион библиотек, которые у тебя собираются, и наверное, тебе не нужно разбираться, как-то сейчас, как ты их, Repack’ом собираешь или там чем-нибудь другим.

Как это влияет на грейд? В принципе такая T-shaped’ность — она может помочь тебе расти, это однозначно плюс, но какие-то есть более эффективные способы расти в компании обычно. Про них Евгений сказал.

Лев Орехов (Яндекс): Вот у нас даже есть отдельные две истории — задачи для фронтенда и задачи для бэкенда. И они немножко отличаются. У них есть немаленькое пересечение на самом деле, но они отличаются.

Сергей Анчутин (Doubletapp): Для бэкендеров сложнее?

Лев Орехов (Яндекс): Для бэкендеров есть особенные задачи. 

Сергей Анчутин (Doubletapp): Почему?

Лев Орехов (Яндекс): Ну потому что бэкендер делает особенные вещи. На самом деле на фронтенде есть тоже особенные задачи в другую сторону. Я могу привести примеры двух задач из прошлого. Мы сейчас их уже больше не задаем, но, наверное, они позволят как-то оценить разницу. Для бэкендера можно было задать задачу: у вас есть два файла, в каждом по много десятков гигабайт. У вас есть машинка, у которой мало оперативной памяти. Напишите код, который переложит все записи А, которых нет в файле B, в файл С. Напишите и объясните, почему этот код достаточно оптимальный. 

А для фронтендеров были отдельные пытки. Можно было попросить написать каррирование на JavaScript или частичное применение функции на JavaScript.

Сергей Анчутин (Doubletapp): Но можно же писать не на JavaScript, на чем хочешь? Задача на алгоритмы.

Лев Орехов (Яндекс): Но это же не задача на алгоритмы, это же задача на код. Мы задаем не только задачи на алгоритмы, мы задаем задачу на код.

Сергей Анчутин (Doubletapp): Но давай разделять задачи на код по платформе и задачи на алгоритмы, которые вы в отдельной секции задаете. 

Лев Орехов (Яндекс): Окей, здесь у нас тоже есть определенная разница. Но она, конечно, гораздо меньше. Для фронтенда есть задачи, где минимум алгоритмов. Ну то есть ты знаешь, что такое «словарь» — и этого уже достаточно. Да, и задача дальше решается. Сейчас я пытаюсь, перебираю все задачи у себя в уме и понимаю, что нет, на самом деле они у нас очень похожи. Вот если убрать платформенную часть, то задачи по именно какой-то алгоритмической части очень похоже.

Сергей Анчутин (Doubletapp): Ну и зачем фронтендерам алгоритмы?

Лев Орехов (Яндекс): Да для того же, для чего и бэкендерам. 

Сергей Анчутин (Doubletapp): Для чего?

Лев Орехов (Яндекс): Смотри, мы задаем задачи уровня LeetCode easy, LeetCode medium. И на секциях с такими задачами мы проверяем какие вещи? Первое: что человек умеет, как он подходит к проблеме, как он ее проанализирует, как он сформулирует вообще, что нужно сделать и какими шагами прийти к решению. Это очень полезно, ведь разработчики должны уметь понимать проблему и искать пути ее решения. Дальше мы понимаем, что он может написать код, который эту проблему решает.

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

Сергей Анчутин (Doubletapp): Но у него не было бизнес-специфики, вот если он не учился ни на каком математическом факультете, сам научился программировать на курсах Skillbox, и у него не было бизнес-специфики в решении алгоритмов. Он никогда их не решал и не готовился к собесу, чтобы специально их решать. Это же какая-то отдельная бизнес-специфика — уметь решать алгоритмы.

Лев Орехов (Яндекс): Сейчас подожди. Вот эти задачи — они интересны тем, что в них нет бизнес-специфики.

Сергей Анчутин (Doubletapp): Нет, я имею в виду, что это сильно отличается от твоей работы. Сильно отличается от перекладывания JSON на фронтенде и даже на бэкенде.

Лев Орехов (Яндекс): Да, но наша задача все-таки — за короткий промежуток времени провалидировать, что человек умеет проблему анализировать и может написать какой-то код. Вот в чем суть.

Сергей Анчутин (Doubletapp): Но без предварительной подготовки или образования многие люди на этом споткнуться.

Лев Орехов (Яндекс): Безусловно. 

Сергей Анчутин (Doubletapp): Многие люди с хорошим уровнем насмотренности, опыта, которые бы классно работали. Но вы их не возьмете.

Лев Орехов (Яндекс): Здесь, кажется, лучше false negative. Ну то есть нам лучше не нанять, да-да-да, не нанять человека, который может не перформить, чем там нанять лишнего человека, который все-таки бы заперформил. Это вот в эту сторону идет компромисс. Мы более строго отбираем, но зато потом меньше увольняем. Сейчас я еще дополню. И кроме алгоритмических задач мы, например, сейчас задаем и бизнесовую задачу.

Евгений Штерн (Okko): Я бы хотел уточнить такую штуку… Ребят, поднимите руку, кто когда-либо ходил на собес, вот, кто собеседовался? Так, хорошо, кому алгоритмы… Кто не собеседовался — прошел сразу? Кому задавали вопросы по алгоритмам? Кому это нравилось — продолжайте держать руку.

А дальше возвращаюсь к вопросу перегретого рынка. Откровенно говоря, когда человек идет на какую-то работу, мы хотим увидеть вот эту вот Love Story именно к нам, потому что у нас самый вкусный смузи. Но по сути-то мы понимаем, что человек просто идет вот как обои покупать в «Леруа Мерлен». То есть в итоге просто пойдет куда-то там, где ему примерно что-то предложили, потому что люди собеседуются не каждый день, и они очень сильно от этого устают, и в итоге они просто иногда прыгают на последнюю компанию, которая такая: «А у нас один раунд собеседования — и вы сеньор+ в мантии, обладающий магией», — вот это вот все. Поэтому здесь есть вопрос.

При этом есть компании, которые могут себе позволить так не делать. 

Петр Белкин (Сбер): А у нас, наверное, немножко такая ситуация, больше про то, что мы On-demand задаем вопрос на алгоритмы, когда непонятно, что за человек сидит перед тобой. И хрен знает, берем, не берем? Вроде такой чувак, давай поймем, как он структурированно/неструктурированно мыслит, зададим задачку на алгоритмы. Мы даже менеджерам задаем задачки на алгоритмы, на то, чтобы они нашли логический ответ на вопрос. Но при этом менеджеры могут не всегда правильно ответить, но мыслить при этом путем своего… Мы стараемся выявлять, что человек мыслит системно, он, построив какую-то вереницу этапов, шагов по поиску ответов, рассказа о том, как он мыслит… Он достигает положительного или отрицательного результата по собеседованию. 

У нас такая позиция, On-demand, мы это используем только как периодическую лакмусовую бумажку, так скажем. Но задаем бизнес-задачи, стараемся лайвкодингом выявлять какие-то важные для нас истории. 

Вот, про грейд мы уже обсуждали, что это отражение бизнеса.

Лев Орехов (Яндекс): Да, я хотел добавить, что как Женя сказал, зависит от компании. И в компании это тоже зависит от подразделения к подразделению. Мы вот сейчас в Путешествиях, так как быстро растем, то экспериментируем с другими вариантами найма. В частности, мы тоже сейчас начинаем делать лайвкодинг — дать какую-то задачу с бизнес-составляющей, не очень сложным алгоритмом, но без него все равно никуда не уйти — там все равно в словарь надо что-то сложить, ведь без словаря ничего не решается, и посмотреть, как человек напишет код, как он выработает архитектуру своего приложения. То есть такие задачи.

Сергей Анчутин (Doubletapp): Ладно, окей, он знает, что такое словарь, может туда сложить. А должен ли он знать, как устроен словарь внутри под капотом?

Лев Орехов (Яндекс): Да.

Сергей Анчутин (Doubletapp): Почему?

Лев Орехов (Яндекс): Потому что у нас есть нагрузки большие местами, и очень легко написать такой код, который будет работать херово. 

Сергей Анчутин (Doubletapp): Кто-нибудь считает, что не нужно знать, как устроен словарь? В зале. (зрители поднимают руки) Кто-нибудь считает, что не нужно знать, как устроен словарь под капотом? Все считают, что нужно.

Евгений Штерн (Okko): Я говорю, можете поднять руку анонимно, чтобы никто не знал... 

Сергей Анчутин (Doubletapp): Ты, Женя, против алгоритмов, но хочешь знать, как устроен словарь? Почему?

Евгений Штерн (Okko): На самом деле я не против алгоритмов. И здесь вот уже коллега упомянул, что по сути собеседует команда. Если команда хочет, чтобы кандидат знал алгоритмы, а кандидат их не знает, то не надо кандидату идти в эту команду, не надо этой команде принимать этого кандидата. Потому что Love Story не случится. А что касается «под капотом», то на мой взгляд, когда ты используешь… Я здесь повторюсь, тузы которые ты не понимаешь, как они работают, то как бы отбить себе пальцы этим орудием труда очень просто. 

Сергей Анчутин (Doubletapp): А до такого уровня нужно понимать? Должен читать исходники Android или должен читать исходники Linux? Понимать, в каком месте памяти у тебя адрес клавиатуры лежит? Ну или как из песка сделать процессор? 

Евгений Штерн (Okko): На самом деле как из песка сделать процессор — с этого и начинать надо. Вот тот, кто будет понимать, как это сделать, и не будет бредить при этом… Но все-таки, если у нас есть словарь, хорошо понимать, как он работает. Не надо там, ну не знаю, если я спрошу, как работает Android-фрагмент, если кто-то залезет внутрь Android-фрагмента, то он увидит, что там есть 18 реализаций, некоторые из которых depricated, и они такие: ну мы это написали фигово, мы пойдем типа на одну итерацию обратно, и пойдем туда, и там такое вот дерево возникает… Вот такие штуки не надо знать... Ну или можно знать... Но как работает фрагмент — надо знать. Это отвечает на твой вопрос? 

Сергей Анчутин (Doubletapp): Ну а почему надо знать? Это имеет какой-то бизнес-смысл? Это ускоряет разработку? Польза бизнесу от этого?

Евгений Штерн (Okko): Это гарантирует, как сказал коллега, что он не напишет херню. 

Лев Орехов (Яндекс): Я могу привести тут два примера. Во-первых, вот те люди, которые фигово написали фрагмент, наверняка не знали, как устроен словарь. Второе: у нас были примеры конкретные. Сервис написан на Python. Нам нужно сделать in-memory кэш, чтобы по ключу быстро получать значения. Если человек не знает, как устроен словарь, он может вполне спокойно туда положить например список, и потом в этом in-memory кэше весело бегать по 100 000 элементов, перебирая их один за другим. Либо он может знать, как устроен словарь. Знать, что у него там сложности от одного и получать за единицу времени. 

Петр Белкин (Сбер): Я бы, наверное, хотел сказать, что знание словаря должно быть… Не всегда прямо нужно иметь глубокое погружение в знание какого-то конкретного словаря. Я наоборот считаю, что если человек понимает, как он устроен, в формате — он может схематично в голове представить себе, как он работает и какие у него базовые принципы просто заложены. То есть: не клади там… Это такая-то структура данных, это такая-то — ну как он работает досконально, до кишков — не нужно знать все словари.

Сергей Анчутин (Doubletapp): То есть разруливание коллизий знать не нужно?

Петр Белкин (Сбер): Ну разруливание коллизий — не знаю, это один из базовых принципов, мне кажется.

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

Сергей Анчутин (Doubletapp): Приходит чувак, заявляет, что он сеньор, ты говоришь: не знаю…

Петр Белкин (Сбер): Я тебе могу предложить джуна!

Сергей Анчутин (Doubletapp): Да. 

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

Петр Белкин (Сбер): Я бы по чесноку ответил. Эта история про то, что если у тебя есть маленькая компания, у тебя есть определенный фиксированный бюджет, куда-то ты хочешь найти человека, и ты понимаешь, что если он может здесь и сейчас тебе решить конкретную задачу, не зная при этом алгоритм, который ты 100500 лет назад спрашивал в Яндексе, и ты думаешь, что эта история — прям серебряная пуля, то нужно научиться задать себе вопрос: «А зачем я этот сейчас алгоритм задаю, если мне сейчас, здесь и сейчас, надо сделать и решить прикладную задачу». Вот например в каких-то стартапах и маленьких компаниях, если у тебя, конечно, нет амбиций за год вырасти в хайлоад огромную структуру, ты делаешь какие-то не очень сложные вещи, то алгоритмы могут сыграть небольшую злую шутку, потому что тебе придется больше заплатить за разработчиков.

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

Из зала: А не будет ли это преждевременная оптимизацией?

Петр Белкин (Сбер): Как всегда — задача про 2 стула.

Евгений Штерн (Okko): У нас 4 стула, если что. 

Евгений Штерн (Okko): Я нахоливарю на холивар. Короче, если у вас есть списки вопросов в компании, то с одной стороны это классно, а с другой стороны, надо выходить на то, чтобы списков у вас не было вообще никогда. Чтобы не было одних типичных вопросов для абсолютно разных команд, которые решают абсолютно разные задачи.

Но это значительно сложнее, потому что когда мы говорим про собесы… Ну вот кто вот из присутствующих собесит? Кто бы хотел собесить? Так А кому это прямо вот нравится, кайфует от этого? Опять же, вот как с алгоритмами — не очень много рук. После 1580-го собеса типа все одно и то же, да? 

И как бы здесь вопрос такой. Ответил ли я на твой вопрос? 

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

Лев Орехов (Яндекс): Хорошо, я скажу, что да, примерно так оно и должно работать. Вот необязательные задачи должны быть внутри команды подобраны. Задачи можно разделить по классам: алгоритмические, бизнесовые и так далее, и потом откалибровать их по сложности. А потом у тебя интервьюеры берут какие-то наборы задач, делают из них пресеты, которые им нравятся, прорешивают эти задачи и начинают их давать. И, отвечая на твой комментарий. Да, конечно, давая задачу, ты должен понимать, что ты проверяешь. 

Сергей Анчутин (Doubletapp): У вас это так работает? Собеседующие понимают, что они проверяют?

Лев Орехов (Яндекс): Да. Для того, чтобы собеседующий точно понимал, что он проверяет, у нас есть специальная методика выставления баллов за решение задач, где прямо понятно, что вот такое качество — вроде нормально, а вот такое — вообще не проявил, но в сумме все равно хорошо.

Лев Орехов (Яндекс): Я не прошу их писать код, мы не просим их в Путешествиях писать код. Но мы спрашиваем какие-то базовые вещи.

Сергей Анчутин (Doubletapp): Нужно знать 7 уровней в OSI?

Лев Орехов (Яндекс): Нет, не обязательно. Но конечно, если знаешь — это плюс однозначно. Вот, но хотя бы чтобы он про HTTP рассказал. Хочется на этой же секции, чтобы он смог спроектировать какой-нибудь простенький сервис, такой лайт, лайтовая очень версия систем-дизайн. 

Сергей Анчутин (Doubletapp): Это у каких видов менеджеров, у всех?

Лев Орехов (Яндекс): У всех. Просто к проджекту тут чуть больше требования, к продакту — чуть меньше. Ну еще я там спрашиваю на технической секции всякие стремные вещи типа: «А что, если тимлид предложит переписать сервис весь за 5 лет?» И вот такое вот.

Сергей Анчутин (Doubletapp): И какой ответ?

Лев Орехов (Яндекс): Ответ там очень сложный. И я его не скажу, вдруг нас смотрят менеджеры. 

Петр Белкин (Сбер): У нас тоже есть техническая секция для менеджеров. Начинается она с простых вопросов на мышление, плюс мы в последнее время сталкиваемся в компании с проблемой менеджеров из типа «чайка-менеджер». У нас так и называют людей, которые пытаются пушить людей, не понимая, что они пушат. И мы стараемся от них постепенно… «Чаек» сплавлять в далекие края. Поэтому эта история про то, что мы приходим к тому, что знание технических скиллов — оно очень важно, но на таком базовом системном уровне, я бы сказал. Не обязательно типа он должен читать код — он может уметь читать код, может понимать. Но если он знает, как проектируются сервисы, какие-то жизненные циклы разработки, как эта история встраивается там с точки зрения архитектуры, умеет общаться на уровне «что такое API, что такое HTTP», ну не обязательно знать семь уровней OSI

Сергей Анчутин (Doubletapp): Смогут ли ваши менеджеры понять, что разработка хочет выбрать технологию в угоду своему развитию, а не в угоду быстроты развития бизнеса? Например SwifiUI, когда ты пишешь новое мобильное приложение под iOS.

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

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

Сергей Анчутин (Doubletapp): Женя, ты расскажешь про техническую секцию менеджеров?

Евгений Штерн (Okko): Да я с удовольствием. Я здесь выступлю немножко… Сначала я скажу: желательно, чтобы менеджер был техничным, потому что по сути этот бэкграунд дает возможность лучше рулить командой. То есть чтобы вам действительно что-то не впарили, потому что разработчики могут преследовать разные цели во благо разработки — это правда. Ну и по сути, даже не преследуя этих целей, может получиться так: если не понимаешь, если ты не обуздал ту бурю, которая там крутится, то у тебя будут проблемы. 

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

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

Вот я скажу так, немножко дипломатично, потому что разрулить 15 проектов на коленке — тоже не хухры-мухры, и не каждый технический менеджер сможет это сделать.

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

Лев Орехов (Яндекс): В контексте 15 проектов я не знаю, что вообще может помочь менеджеру. Но вообще, если менеджер умеет мыслить такими терминами, как API, база данных, кэши, если он примерно может представить архитектуру какого-то сервиса не очень сложного, то он сможет и с разработчиками потом общаться в этих терминах.

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

Лев Орехов (Яндекс): В первую очередь это именно про это, да. 

Из зала: Это техническая секция называется. 

Лев Орехов (Яндекс): Ну для менеджеров — да. У нас есть и особые технические секции для особенных менеджеров. 

Сергей Анчутин (Doubletapp): Это, кстати, опять идет от потребностей бизнеса. Вот мы записывали подкаст с руководителем отдела разработки поиска в Яндекс Маркете, и он нам рассказал о том, что вот те, кто занимается, менеджеры, разработкой поиска и там проектами руководят, для них технические секции сложнее, они должны намного глубже понимать технологии, чтобы таким продуктом руководить.

Лев Орехов (Яндекс): Тут разделение очень простое. Есть у тебя подразделение либо компания, которая занимается продуктовой разработкой — ну типа вот Яндекс Путешествия. Мы продукт, мы для пользователя. А есть подразделение либо компания, кто занимается инфраструктурой. И менеджер в инфраструктурной компании, например, то же Яндекс Облако, у него заказчик — разработчики. И у него продукт — это инфровая штука. Он обязан сечь в технологиях.

Сергей Анчутин (Doubletapp): Там у продуктологи должны глубоко понимать в облачных технологиях. 

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

Сергей Анчутин (Doubletapp): Но Михаил Парахин утверждал, когда он в Яндексе работал, что он программирует для себя.

Лев Орехов (Яндекс): Ну с ним да. 

Из зала: А как вы растите таких менеджеров, где берете? Их же мало.

Петр Белкин (Сбер): Если мы их растим, то откуда мы их берем?

Из зала: Ну как растите? Вот есть менеджер, он классный менеджер, но вот технически плоховато у него там все. Как, сколько будете терпеть, пока будете учить? 

Петр Белкин (Сбер): Если тебе надо, если у человека есть желание пошарить в технике, и он менеджер, который умеет грамотно задавать вопросы, то он может найти себе… И менеджер — это человек, на мой взгляд, должен быть активный, с активной жизненной позицией и уметь находить людей, которые могут ему дать ответы на нужные вопросы с точки зрения техники, он может найти себе человека, который его подтянет. А тому человеку, который согласится его подтянуть с точки зрения техники, мы с ним можем договориться на определенные условия — с какими уровнями выполнения мы должны получить менеджера. И потом, после этого его просто проэкзаменуют, посмотрят, и если человек реально прокачался с точки зрения менеджмента, то он хороший.

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

Сергей Анчутин (Doubletapp): Будешь уважать DevRel, который с тобой не сможет раздуть про Kafka?

Петр Белкин (Сбер): Да в любом случае мы уважаем DevRel, их сейчас очень сложно найти, легко потерять и невозможно забыть.

Раздуть про Kafka — ну если это базово раздуть, то нормально. А если не знает ничего, если говорит про композитора — то это уже вопросики вызывает.

Сергей Анчутин (Doubletapp): Можно я тоже еще более структурирую вопрос, который задали? У вас менеджеры — они докачиваются технически в процессе работы, они приходят уже докаченные и они всегда были менеджерами, или они получаются из разработчиков? Из разработчиков ваших или разработчиков других компаний? И, поработав в другой компании, он вначале был разработчиком, поработал где-то, поработал, потом поработал менеджером где-то, и он потом пришел к вам такой менеджер красивый. Я три варианта предоставил — там какое-то соотношение между ними или какой кейс более частый? В такой структуре ответьте, пожалуйста.

Петр Белкин (Сбер): У нас всегда по-разному на самом деле, но мы стараемся растить людей внутри с точки зрения того, что если мы ищем человека с…

Сергей Анчутин (Doubletapp): А из кого он растет? Личинка кого вначале?

Петр Белкин (Сбер): Личинка аналитика, личинка иногда разработчика бывает и архитекторов. Иногда архитекторы принимают решение, что им надоело быть архитекторами и они хотят научиться управлять и стать менеджерами. Наверное, из этих. Иногда из тестировщиков, но это в меньшей степени, они иногда могут стать тест-лидами или лидами группы тестирования. У нас существует такие ячейки. Но в основном так.

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

Лев Орехов (Яндекс): Так, Сергей предложил три разных варианта. Я отвечу про три разных типа менеджеров (про четыре). Менеджеров продуктовых и проджектовых мы берем с рынка. Мы их у себя практически не растим.

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

Вот, а второй тип — это инжиниринг-менеджеры. Инжиниринг-менеджеры — это в принципе тимлиды. Они у нас всегда растут внутри.

И они вырастают из разработчиков.

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

Евгений Штерн (Okko): Я здесь добавлю такую штуку, такой ощущение, что немножко мы в какой-то альтернативной реальности. То есть можно выбирать разработчиков, брать менеджеров, откуда ты хочешь. Чтобы любовь случилась в мире, где есть любовь. 

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

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

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

Откуда вообще берутся люди в IT — это вещь очень комплексная. И откуда берутся менеджеры — она еще более комплексная. Потому что это вроде бы трек развития, с которого можно типа перепрыгнуть с разработчика, а можно просто с этого начать. И на самом деле местами… Я вот вчера общался с человеком на неформальной тусе, где его опыт привел его в тимлиды, при этом он имел очень смежный опыт, но это позволило ему быть эффективным тимлидом. И он очень быстро нахватал техническую часть.

Вот поэтому я не буду это раскладывать по полочкам, потому что ситуация, как правило, диктует.

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

Евгений Штерн (Okko): Ну по сути кандидат может задавать на собеседовании любые вопросы, для этого действительно есть секция. И собеседующий может на них корректно отвечать. Когда непосредственно есть определенная цель этого мероприятия. И цель этого мероприятия — это понять то, что знает кандидат. Не то, что он не знает, а то, что он знает. Это первая цель. Вторая цель — это кандидат может узнать о том, как будет происходить его будущая работа и какие задачи он будет выполнять в компании, и как он сможет вырасти, и кто его будет руководитель. И там дальше можешь поговорить про плюшки, про команду, про что-то еще. 

Цель выявить компетентность собеседующего — это же не Роспотребнадзор пришел к вам на собес. То есть можно, конечно, если очень сильно кандидат нравится, но мне не кажется это логичным в определенной мере.

Лев Орехов (Яндекс): На самом деле предыдущие ораторы все сказали. Кандидат явно неконструктивен, он не понимает цели происходящего мероприятия, поэтому можно спокойно сказать ему нет. Кстати, тогда мы ему и сказали нет и не наняли.

Сергей Анчутин (Doubletapp): Как сложилась его судьба?

Лев Орехов (Яндекс): А я не знаю, мы же не наняли.

Из зала: Давайте такой контекст немного накину. Смотрите, я провожу систем-дизайны, но не обычные, а ML. И очень часто в конце кандидаты спрашивают: «А как бы ты решил эту задачу?» Типа что тебе не нравится в моем решении? Мог бы ты что-то сделать другое? Я спокойно на них отвечаю, потому что я по сути пытаюсь немного, наверное, продать компанию. Потому что если кандидат... Ну понятно, если вы Яндекс, то про вас знают. А если вы что-нибудь поменьше, то про вас вообще никто ничего не слышал и не понимают уровня вашей команды. Получается, что во время ML-систем-дизайна я показываю, что я тоже не пальцем деланный и спокойно вообще к этому отношусь. И, условно, эта секция на вопросы переходит вообще в какой-то диалог, и мы с кандидатами, например, обсуждаем плюсы и минусы моего и его решения.

Почему такой кейс вообще, вы говорите что «нет, это неконструктивно и такое недопустимо»?

Лев Орехов (Яндекс): А это другой кейс. В описанном тобой кейсе я совершенно так же вхожу в диалог с кандидатом. Это совершенно нормально. Ну мы обсудили какой-то вопрос, теперь ему интересно знать, правильное ли решение. Это можно и в систем-дизайне так сделать, можно и задачу с кодом обсудить. И совсем другое, когда тебе кандидат, ну, мы все сделали, и такой кандидат говорит: «А теперь вот у меня есть задача про 10 гномиков. Реши-ка мне!» Мы, скорее, про второй кейс говорим.

Из зала: Не, если вас кандидат просит решить гномиков, то это кринж, конечно. Все окей.

Сергей Анчутин (Doubletapp): Да-да, мой кейс был про обсуждение совсем новых задач, а не про что-то старое. 

Все, думаю, нам нужно заканчивать. Есть у кого-то еще комментарии? Евгений хочет добавить что-то.