Нулевой километр (Хекслет)

Hexlet (00:00.11)
понял, что менеджеры, не в обиду менеджером будет сказано, мне всегда нужны. Потом к Саше прихожу и прям спорил, давай возьмём. Не знаю, ты помнишь, нет, но достаточно давно уже было. Не бы взяли? Конечно, до сих пор. Просто огонь. Но вся суть собеседования состоит в том, что мне задают вопросы, а я на них отвечаю. Друзья, мне так нравится вами общаться, я даже не спрашиваю вопросов, вы на него уже отвечаете. Плюс мы в Лего играем.

Hexlet (00:39.15)
Друзья, всем привет! На связи Hexlet. С вами Александр Русков. Сегодня у распаковка компании BinduSoft. И в нашей виртуальной студии, собственно, основатель компании Александра Bindu и технический директор Руслан Цафин. Друзья, приветствую. Привет. Привет. У нас на блоге Hexlet не так давно выходила статья про то, как устроена работа этой компании. Сегодня мы все узнаем из первых уст. Два слова. Друзья, расскажите, пожалуйста, чем занимается компания? Я расскажу. Мы создаем приложение по бизнес целям заказчиков.

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

не будем, потому что вот Хекслет, например, есть, где Кирилл прекрасно всё организовал, но мы можем обучать людей через IT достигать бизнес целей. Он такой, ну, это следующий шаг. Я говорю, ну вот если он будет нужен, то мы сможем. В этом, собственно, вся суть нашей компании, этим мы занимаемся уже больше 10 лет. А как много вас людей вообще? Сейчас 62, по-моему, человека. Да, 62. Чуть-чуть.

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

изначально когда я работал в Scrum Tracks посмотрел много как работают эти компании и понял что менеджеры не в обиду менеджером будет сказано не всегда нужны и я подумал что раз они не всегда нужны мы организуемся без них мне могут возразить что это на таком размере компании не нужны и так далее но мне говорили сначала что они не нужны до 10 человек потом до 30 человек но сейчас уже

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

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

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

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

Я правильно понял, что ваши разработчики интеллируются в компанию партнера, клиента, по-разному можно назвать, который непосредственно ставит задачи? По сути, да. Мы в том числе даже собеседуем сотрудников в компанию, заказчика. Мы даже собеседуем CTO в компанию, заказчика. Мы собеседуем продуктов, омеров, разработчиков, если это требуется. Вот Руслан буквально недавно с CTO в очень большой ритейл собеседовал.

Hexlet (05:21.582)
Немножко хочу добавить. Тут интеграция бывает разная. Есть компании, которые работают по модели аутстафа. Когда выделяют заказчику человека или двух-трех человек. все. Эти люди даже переезжают в город заказчика, если они откуда-то. И входят в офис заказчика. У нас все-таки не так. нас все команды работают из офиса Bandysoft. Это Челябинский и Петербург. И все-таки мы не ставим на проект одного-двух людей. То есть это все равно...

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

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

Ты сказал такую очень интересную вещь, ментально сделал разработчик, понятно, что... Я так понял, что есть что-то про самостоятельность, да, некоторую психическую зрелость. А что насчет хард-скилов? Означает ли это, что вы не берете джунов? Мы берем джунов, но для джунов есть целая длинная история, как они погружаются в культуру компании. Сейчас могу про это рассказать.

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

Hexlet (07:31.982)
надо нам выстроить цепочку погружения человека в культуру нашей компании. Хоть она и сложная, но это же возможно. И мы придумали, собственно, интернатуру. Вот сейчас начинается скорая летняя интернатура, человек придет, он узнает, там есть несколько треков, он узнает все про архитектуру, всякие рефакторинги, тесты, микросервисы, CICD, вообще все, что связано с этой глубокой такой хорошей разработкой.

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

И вот чтобы это понимать, нужно понимать плюс и минусы границы применимости, и мы это всё делаем. Плюс мы в LEGO играем, а я погружаю ребят в процесс разработки с помощью LEGO. Ну это часто тема, кто тренинги всякие проходил по Agile, Kanban, Scrum, те в LEGO тоже много играют, я просто раньше это проводил. Вот. И ребята через три месяца вот такого погружения начинают понимать, а как вообще серьёзная разработка PO устроена на самом деле.

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

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

Hexlet (09:54.894)
но уже какие-то задачи, которые могут они в принципе сделать. Мы достаточно долгое время не набирали людей без опыта, джунов, но были естественные исключения, которые только подтверждают правила. Вообще в нашей сфере сложно сказать, что именно без опыта. Ты мог никогда не работать над коммерческой разработкой, но при этом писать в open-source известные проекты. Ты мог написать какую-то игру, её запустить, не монетизировать, ты её писал практически один или с друзьями, но...

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

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

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

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

Hexlet (12:12.366)
Ну, те, кто давно в программировании, знают. Ты смотришь на код, и сразу видно, аккуратный он или нет, какие там учтены моменты или нет. Но это чисто технические, что учтено в алгоритме, проверки на Null, исключения и так далее. Но вот в целом, как оформлено. То есть, как человек вообще видит эстетику этого кода, как он его воспринимает, это сразу прям бросается в глаза. Соответственно, если...

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

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

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

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

Hexlet (14:27.374)
Многие люди приходят по три, по четыре раза на наши собеседования. Мне уже кажется, что они просто как на обучение приходят. Многие приходят в компанию через год, через полтора после того, как собеседование прошли. То есть они приходят на собеседование, мы им даем фидбэк. Они допустим где-то работают, они продолжают наращивать скиллы. Они их до нарастили до нашего уровня. Они возвращаются и уже спокойно проходят. Это вообще обычная история.

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

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

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

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

Hexlet (16:48.078)
не составит труда, тем более в команде с профессионалами быстро что-то взять и изучить. Поэтому я стараюсь действовать на территории, как сказать, ну да, на территории кандидата. То есть он про что-то рассказал, свой какой-то опыт, про свой проект, и за что-то я цепляюсь и начинаю раскручивать. Попробую какой-нибудь пример привести, чтобы никого не спалить. Ну, допустим, кандидат говорит, что он работает в сфере

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

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

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

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

Hexlet (19:11.918)
Если он принципе понимает, как работает база данных, как индексы строятся, как они пересекаются между двумя таблицами, то этого вполне достаточно. есть каких-то теоретических вопросов практически нет. Есть какие-то вот совсем простенькие ситуации, которые можно на пальцах за пару минут объяснить. И дальше просто рассуждение. Так проходит примерно час. Практически всегда часа не хватает. Хочется больше, особенно если кандидат интересный.

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

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

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

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

Hexlet (21:31.15)
Это внешняя сторона собеседования, со мной еще всегда есть HR. Глубокая сторона этого собеседования в том, что у нас компании по анкете 360 выделено 5 компетенций, которые необходимы каждому сотруднику. Они все расписаны по уровням. И за вот это собеседование нам нужно определить человек наш или не наш.

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

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

И мы с этим человеком, мы ему передаем весь этот фидбэк, то есть он его сам читает Потом я вместе с HR, вместе с этим человеком, сотрудником Мы это все перечитываем И составляем ему план развития на год, если есть что-то где-то доработать Ну давай что-то послушаем, что же за компетенции интересны А, на самом деле очень простые Это первое... Можно, конечно Да, можно, это гибкость, это профессионализм Это...

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

Hexlet (23:44.814)
Вот что конкретно, это такая фишка, мы с этим долго работали, нанимали экспертов, профессионалов, психолог работал и так далее. Мы прям специально подбирали под нашу компанию эти уровни, мы их прям расписывали. И есть еще лидерские компетенции, но они естественно только для тех, кто уже дальше там, кто Team Lead, Team Lead и так далее. То есть кандидата мы вот по этим пяти компетенциям только оцениваем, прицениваем.

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

Сдавать правильные вопросы тоже, мне кажется, не самый простой навык. Есть ли у вообще какие-то грейды, были градации, там, junior, senior, middle, это всё или тут всё у универсально для всех? Нет, у нас расписаны грейды, у нас расписаны требования по каждым грейдам, опять же, там, по разным направлениям. У нас расписаны, ну, соответственно, зарплаты по этим грейдам.

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

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

Hexlet (26:04.654)
То есть я сам еще помогаю, такие часто задаваемые вопросы подсказываю, чтобы человек спросил, ему сказал. На самом деле оно проходит очень лоитово. Буквально вот любого человека с улицы можно взять и он сможет его проходить. Ну единственное, мы его не возьмем, конечно, работу, да, любого человека с улицы. Но инженер, инженер, который любит инженерное дело, вот как я, как Руслан, этого человека сразу видно.

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

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

Есть даже... Профессиональные, да. Да-да-да, есть консультанты. такие есть. Да-да-да, они помогают именно подготовиться. То есть всё, я его, честно сказать, готов был брать. Ну, так, для соблюдения формальности, сели по программированию, и всё посыпалось. Я думаю, тут надо дополнить то, что если мы берём, допустим, человека, у которого 10 лет опыта, который уже работал с микросервисами, который уже работал с высокими нагрузками.

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

Hexlet (28:27.15)
Горят у него глаза. Да, горят у него глаза на эту тему или нет. У нас иногда приходят люди, утрированы, сейчас говорю, которые рассказывают. Я вообще люблю на велосипеде кататься, но денег это не приносит, поэтому я пошел в айтишнике. Я не против велосипеда, я говорю про то, что избрал ты эту профессию как профессию для своей жизни или нет.

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

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

Давайте представим, что человек вам все-таки попал. Вы говорите, у вас есть грейды. Как вообще происходит процесс ассессмента? Как часто? Кто его проводит? Я думаю, что надо с онбординга начать. Онбординг длится три месяца, он расписан прямо по неделям. Уже много-много человек прошли по этому онбордингу. Этот процесс онбординга немножко ветвится от стрима к стриму. А стрим – это у нас…

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

Hexlet (30:44.27)
такие мини тренинги и так далее. То есть мы прям знаем то, что нужно человеку узнать за три месяца. Это еще как бы вне даже интернатуры. У кандидата, который новый, который у нас только пришел, у него есть ментор, с которым этот человек работает. У ментора тоже есть свой план. То есть со стороны ментора тоже есть план, который тоже расписан по неделю. Дальшим. Через месяц работы ментор дает фидбэк.

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

Если вдруг тебе чего-то где-то не хватает, ты прямо сейчас приходи к HR или к ментору или вообще там хоть кому, кого в коридоре поймаешь. Говори о том, что вот это нужно подтянуть, потому что обычно подтянуть за два месяца можно ну... до нужного уровня практически все что угодно можно подтянуть. Соответственно, человек смотрит, что он допустим где-то не попадает или он смотрит, что он и так хороший, он молодец. Он ждет вот эти три месяца, ну смысле он работает на проекте, идет он бординг и так далее. Через три месяца...

собирается фидбэк по анкете 360, то есть он сам его дает и все, кто с ним работали дают, ну плюс еще там я может быть или заказчик может быть и так далее, ну там разные вариации есть в зависимости от уровня и человек видит этот фидбэк по анкете 360, он видит те условно, ну оценки скажем так, которые были проставлены и тут уже объективно

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

Hexlet (33:13.998)
правильно подбирать правильных людей в компанию. И поэтому осечек у нас не было уже, сейчас скажу, сколько, два с половиной года. То есть если человек прошел все вот эти уровни, то он практически со 100 % вероятностью остается в компании, работает и так далее. Вот, последний раз, когда была осечка, сотрудник через три месяца посмотрел на анкет 360 сказал, ребят,

Я сам уйду, потому что я чувствую, что я не попадаю. Мы такие, ну окей, извини, что так получилось. Мы сами тоже не досмотрели, где-то там не дотянули и так далее. Ну вот так. А последние два с половиной года такого ни разу не было. Так, спасибо. Ну про анбординг понял. Что происходит дальше? Сотрудник, который уже попал в компанию? Сотрудник, который попал в компанию, работает на проектах. Во-первых, раз в год у нас происходит индексация, в любом случае.

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

я хочу больше зарплату соответственно мы смотрим анкету 360, смотрим его код в стриме который он там работает ну в стриме как я говорил backend, frontend, ux и так далее смотрим как он отработал, берем фидбек техлида берем фидбек заказчика и после этого ну обычно говорим ты молодец, ты крутой, вот тебе денег иногда такое происходит что человек допустим не дотягивает ну тогда он получает такое прям полное обоснование

он получает roadmap развития, мы с ним договариваемся на конкретные какие-то задачи, которые он закрывает, и мы видим, что он до нужных скиллов дотянулся, и он получает свой grade. Ну, это что касается вот именно роста в компании. Вообще, наверное, стоит рассказать, как вообще проекты устроены, да? То есть человек устраивается, во-первых, он сразу попадает к ментору и попадает на какой-то конкретный проект. То есть, возможно, первое время он будет работать в PAI.

Hexlet (35:37.422)
паре, программировать в паре с разными людьми. без компа своего. Да-да-да. Иногда бывает, что по разным проектам, то есть все равно заказчики разные, проекты разные и немножко процессы везде отличаются. Если у тебя вот за процессом бординга удалось пройти несколько разных проектов, разных заказчиков внутри команды BinduSoft, то на мой взгляд это максимально эффективное впитывание культуры компании.

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

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

UI-UX, DevOps и EML. По-моему, ничего не забыл. И есть у каждого стрима техлиты. Техлиты между собой еще отдельно как-то синхронизируются. Это уже, наверное, отдельная тема. То есть человек, приходя в компанию, он попадает в команду, команда работает строго над одним проектом, и он попадает в стрим по своей профессии.

стрим, за прокачку человека, за прокачку скорее более hard-скилов, чем soft-скилов, за распространение практик, за разработку open-source решений. Зачем нам на каждом проекте делать какие-то инфраструктурные вещи. Мы делаем единочды, выкладываем в open-source и потом на всех проектах используем. Плюс предлагаем всему сообществу тоже это использовать. Примерно так мы и работаем.

Hexlet (38:03.246)
Друзья, мне так нравится с вами общаться, я даже диспезовываюсь вопросом вы на него уже отвечаете. Но всё-таки несколько раз упомянули тех лидов, тем лидов, при этом сказали, что у вас нет менеджеров, то есть это, видимо, не менеджеры, это вопрос, что это за люди, какие у них функции, как вообще им становятся, и становятся ли вообще, или нанимаете их уже готовенько? Да, я могу рассказать. Наверное, с тех лидов начнём. Более сложная штука, потому что Team Lead, наверное, ну, примерно все понимают. У нас есть вот эти стримы.

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

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

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

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

Hexlet (40:24.59)
Мы людей не заставляем этим заниматься. у нас на одном... А, у нас сейчас на двух стримах, на девопсе и на КУА, нет тех лидов. И это нормально. В этом нет ничего страшного. При этом стримы продолжают делать свои какие-то стендапы, кубики свои выкладывать в Open Source и так далее, как-то сами живут. В любой момент кто-то из КУА или девопсов может прийти и сказать...

Похоже, я хочу быть техлитом, я вижу, куда мы пойдем. И мы скажем, да, пожалуйста. Как-то так. Это про техлитство. Здесь все понятно. Давай дальше к Teamlead. Teamlead — это еще проще. Это общеизвестная такая штука. Он, по сути, лидирует команду. Он может быть любой профессией. То есть это может быть бэкендер, фронтендер, куа, юиксер. Нам вообще без разницы.

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

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

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

Hexlet (42:47.406)
Так, народ, у нас тут про бизнес цели, а не про вашу архитектуру. Давайте послушаем, что товарищ заказчик нам говорит. То есть, по сути, это может сделать абсолютно любой член команды. У Team Lead'а нет какого-то суперправа только ему это делать. Но, если все в запаре и никто этого не сделал, то Team Lead должен это сделать. А как им становится? как вообще они А все то же самое. то есть... То есть, это один из грейдов у вас?

или тоже самовыдвижение? Самовыдвижение, да. Потому что темлиду выделяется время прям на темлидство, если ему надо. То есть он может, допустим, там полдня или день заниматься чисто своими какими-то темлидскими штуками. Может с заказчиком созвониться поговорить или слетать к нему, съездить, еще что-то сделать. Ну, в общем, какие-то задачи может делать, как ему кажется правильным.

самовыдвигаются, то начинается создание какого-то продукта, мы собираем команду на своей стороне. У команды должен быть Team Lead. Просто либо я предлагаю, либо кто-то говорит, я хочу быть Team Lead. И как-то так собираемся, говорим да, окей. А кстати, нас же недавно, вот тут важно, появился стрим Team Lead'ов. То есть у нас есть техлит Team Lead'ов. Вот так.

Чем же он занимается? Позвольте спросить, в чем тут тех, если тут нет конкретного профиля? Как бы не то чтобы... Мы называем их тех-лидами, кто лидирует стримы. А у нас же есть, допустим, стрим UX, там тоже не сказать, что сильно тех. Да. Но надо обобщать знания, нужно создавать вот эти переиспользуемые кубики со знанием, да, с пониманием того, что происходит. И кто-то должен с высоты полета на это смотреть и говорить.

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

Hexlet (45:07.502)
Да, конечно. есть Александр сказал полдня или день на темлицкой задаче, но это полдня или день в неделю скорее, а не один день в день. Хорошо, давайте немножко про процессы поговорим. Опять же, нет менеджеров, мне не очень понятно, как вообще приоритеты выставляются, как происходит планирование. Я понял, что сразу в командах может быть разная технология, но может какие-то общие вещи есть? Есть базовая вещь, которая называется Product Owner. В смысле вещь, смысле понятие.

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

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

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

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

Hexlet (47:31.63)
каких-то общений, выхода в поле, узнавание того, как все устроено. Мы можем создавать направление того, куда двигаться бизнесу, показываем его владельцам компании, они соответственно говорят «да», и мы… Тут получается некая шизофрения, я как бы работаю в компании, но я продукт-аунер, и мы, получается, идем к этой бизнес-цели. Это получается, на самом деле, очень эффективно, потому что, допустим, если я продукт-аунер…

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

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

Кто как узнает какую задачу брать? Ну тут обычная логика, смотря в какой методологии работаешь Давайте возьмем, не знаю, Scrum, самое простое Происходит планирование недельное в начале спринта Задачи берутся на спринт, приоритизируются Ну и дальше просто кто может, кто свободен берет задачу, утаскает ее по доске Все как обычно То есть если мы берем канбан, ну примерно то же самое

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

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

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

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

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

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

Hexlet (52:13.614)
То есть какого-то такого броновского движения стало меньше, и у нас появились стримы, которые объединяют всех бэкендеров. В рамках стрима бэкендеров, бэкендеров, фронтендеров и других есть встречи, есть сендапы, плюс обычно пару раз в неделю, как минимум раз в неделю, кто-то вызывается сделать некий доклад, то есть он допустим победил какую-то сложную ситуацию, он хочет рассказать про постворты.

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

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

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

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

Hexlet (54:38.638)
Другой человек смотрит, блин, так это супер крутая штука. Слушай, Вов, можно я про это расскажу, раз ты по каким-то причинам не рассказываешь? И вот он становится таким, как сказать, амбассадором, Это open-source решение. Руслан, Руслан, мне кажется, тут надо еще тактически рассказать. Ну, то, что Александр спрашивает, как прокачка происходит. Мы же все делаем в GitHub, и соответственно у нас все через pull-request идет. И человек, когда пишет код...

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

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

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

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

Hexlet (57:01.902)
еще бывают вот такие методы, вот такие подходы, ничего себе. Но и кроме того, естественно, ты можешь какую-то проблему найти, какое-то не совсем точное решение и что-то посоветовать. есть pull requests, в две стороны работают. То есть прокачивается как тот, кто код написал, так и тот, кто код review. Это то, что ты смотришь, решение другого человека. Это, на мой взгляд, очень полезно. Вот в код review я правильно понял, что проходит в рамках конкретного стрима?

или в рамках команды? В рамках команды все-таки. То есть, для pull-request нужно знать специфику проекта, знать устройство проекта, и pull-request они внутри команды. Есть pull-request, даже не pull-request, есть review-кода, который проводит тех-лит, но он уже смотрит на немножко другие моменты, потому что он не погружен в конкретный проект, в конкретную задачу. Он смотрит... У нас там есть...

Чеклист, ревью кода он немножко по другому чеклисту идет Руслан, тут надо сказать, наверное, у нас же есть кубики, которые в Open Source, которые мы переиспользуем Ну, кстати, у нас не все прям в Open Source выложено, но все, что мы внутри называем кубиками, то есть переиспользуем постоянно и обновляем, оно все на GitHub лежит Соответственно, если ты сделал pull request в этот кубик, то любой человек из стрима может дать по нему фидбэк и запрувить его

То есть в этом плане получается межпроект. Да, то есть естественно, pull requests внутри проекта в команде. Понял. Гая про open source, интересная самом деле тема. В ваших open source проектах участвуют люди, которые не являются вашими сотрудниками? Ну, какие-то из GitHub просто товарищи, есть такие? Ну, у нас есть комиты, как это называется, forks, комиты в основную ветку pull requests от не сотрудников компании. Вы в принципе приедете это? Ну, конечно, естественно.

Мы сами много работаем с Open Source, в Open Source есть баги, какие-то проблемы и активно контрибутим. Далеко не всегда ревью таких контрибуций происходит оперативно, иногда, не знаю, каким-то причинам нас, ну, просто исправление бага, явный баг у всех воспроизводится.

Hexlet (59:23.022)
весь Stack Overflow в этом засыпан, но мы исправляем баг, шлем pull request, его не принимают. Просто если создатель репозитория на него забил, то конечно приходится делать fork. Либо его могут принять через два месяца, через три месяца. То есть мы постоянно на этом утыкаемся, и поэтому когда к нам приходит с этим, к нам приходит новый контрибьютер, мы стараемся максимально его заанбордить в наш Open Source проект.

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

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

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

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

Hexlet (01:01:39.694)
правила у тебя с точки зрения стихии паттернов, архитектуры, получается более правильный вариант. В отличие от того, когда ты просто написал кучу функционала, выкатил и не подумал, а как другой разработчик или другая команда, потребитель твоего пакета это будет использовать. Поэтому TDD прям немножко поворачивает мозг по-другому, и ты начинаешь программировать и думать по-другому. Все, Руслан начал про TDD.

Это про меня так шутят. Саша когда начинает говорить сразу про Agile. С кем бы не столкнулся, где бы не столкнулся. Agile это круто. Руслан тут зацепился за TDD, понеслось. Все, извиняюсь, продолжай. Если вопрос в целом про тестирование, код попадает в репозиторий. Неважно это frontend, backend, даже есть тесты на CI-CD сейчас у девопсов.

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

потом две команды одновременно уходят и разрабатывают. И БКНТ и ФронтЭнт уходят и разрабатывают, параллельно не ждя, собственно, реализации этого API. Куана это все смотрит. Мне сказать, что нету ручного тестирования, то есть, на мой личный взгляд, нельзя полностью автоматизировать все, особенно в плане каких-то сложных систем, когда у тебя 10, 20, 50 микросервисов. То есть, есть этап ручной проверки и есть этап автоматизации.

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

Hexlet (01:04:02.766)
Причем нагрузочное тестирование все обычно помнят про рпс, нагрузку по пользователям, по запросам, но забывают по нагрузку по данным. Наверное типовая ситуация, что на стейджинге нас база маленькая, все работает, все летает, мы заливаем это на прод, там база не 10 гигабайт, а 1 терабайт и все встает. Что бы такого не было, даже если у нашей системы 5 пользователей.

высокой нагрузки как будто бы нет, но на самом деле, скорее всего, есть, но она есть по данным, не по пользователю. Если совсем вкратце, то вот так у нас в стране. В самом начале вы упомянули, что у вас два офиса, да, Челябинск и Петербург, то есть вас полностью все работают в офисе или у вас есть какая-то подавленная культура? Да, в основном люди стараются ходить в офис. Я бы так сказал. Мы особо никого не заставляем ходить в офис.

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

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

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

Hexlet (01:06:25.39)
Вот в Питере, прямо сейчас, если говорить, туичим офис побольше, где-то, наверное, между Невским проспектом и Зимним дворцом. Ну, как бы очень абстрактно, да, но где-то в центре с хорошей транспортной доступностью. Ну да, то есть вот где-то... Зимний на Невском стоит.

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

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

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

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

Hexlet (01:08:44.174)
организовываете ли что-то для команды, как вы собираетесь, развлекаетесь? Развлекаемся? Ну вот прямо с последнего зимой соответственно всякий сноуборд, лыжи и так далее буквально недавно ребята ходили на кёрлинг через две недели у нас будет сплав большой по реке на несколько дней в сентябре у нас будет регата корпоративная, мы все в Сочи поедем будем на яхтах гонять кто быстрее

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

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

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

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

Hexlet (01:11:08.942)
взяли, есть нам прислали резюме, они проходят собеседование, мы их берем. А прям даже без интернатуры просто берем на работу. Ну, на джунов, то есть это начальная позиция, понятно, но это уже сразу берем. А вот сейчас на интернатуру, я не помню, несколько человек, есть хекслита, которые к нам пришли и пойдут на интернатуру.

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

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

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

подходят к этому всему. Руслан правильно сказал, что у нас с первого дня самый стандартный трудовой договор для любого другого сотрудника. Все вот эти плюшки трудового договора плюс ДМС тоже с первого дня. Так что здесь все по-честному. Это звучит великолепно. А куда приставить резюме? Ну как обычно, chop-собака-бадюсофт.com или на сайте откликнуться или на ххр откликнуться. Все ссылки в описании.

Hexlet (01:13:26.702)
Все звуки под видео, да, лайк, шер и пост. Как обычно. Да, спасибо, что делаете за меня мою работу. Спасибо вам за этот диалог, очень было интересно узнать. Мне очень понравилось, в самом деле, то, что вы рассказываете. Приятно знать о российских компаниих. Друзья, кто учится на Хекс-Вете, вы знаете, куда обращаться. Все ссылочки в описании, лайк, шер и пост и так далее.

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